From ralf.schmelter at sap.com  Tue Oct  1 08:11:16 2019
From: ralf.schmelter at sap.com (Schmelter, Ralf)
Date: Tue, 1 Oct 2019 08:11:16 +0000
Subject: RFR (L, final): 8218626: Add detailed message to
 NullPointerException describing what is null.
In-Reply-To: <AM6PR02MB5347F83D20D8BAB57494E46CEC820@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <AM6PR02MB53475B0ECD6B83130AAF445BECB60@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB4501C40736C074D8532BF59B9F880@AM6PR02MB4501.eurprd02.prod.outlook.com>
 <AM6PR02MB5347D101348C3A02ED482337EC880@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM0PR02MB45001BC1292FD78EDA457BB29F840@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <AM6PR02MB5347F83D20D8BAB57494E46CEC820@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB4500BE4E1950352DB0C86E0E9F9D0@AM0PR02MB4500.eurprd02.prod.outlook.com>

Hi Goetz,

thanks for the additional test. Looks good.

Best regards,
Ralf

-----Original Message-----
From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com> 
Sent: Montag, 30. September 2019 18:31
To: Schmelter, Ralf <ralf.schmelter at sap.com>; Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>; Java Core Libs <core-libs-dev at openjdk.java.net>
Subject: RE: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

Hi Ralf,

> The test should not omit these two bytecodes because the current
> implementation is the same. This can change and it is not much additional code
> to add the two cases.
I implemented test cases for the missing invokes:

http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/20-incremental/
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/20/

Best regards,
  Goetz.




From goetz.lindenmaier at sap.com  Tue Oct  1 10:45:42 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 1 Oct 2019 10:45:42 +0000
Subject: RFR (L, final): 8218626: Add detailed message to
 NullPointerException describing what is null.
In-Reply-To: <AM0PR02MB4500BE4E1950352DB0C86E0E9F9D0@AM0PR02MB4500.eurprd02.prod.outlook.com>
References: <AM6PR02MB53475B0ECD6B83130AAF445BECB60@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB4501C40736C074D8532BF59B9F880@AM6PR02MB4501.eurprd02.prod.outlook.com>
 <AM6PR02MB5347D101348C3A02ED482337EC880@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM0PR02MB45001BC1292FD78EDA457BB29F840@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <AM6PR02MB5347F83D20D8BAB57494E46CEC820@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM0PR02MB4500BE4E1950352DB0C86E0E9F9D0@AM0PR02MB4500.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB534757C9EEEA19E103AE306BEC9D0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Thanks, Ralf!

Best regards,
  Goetz.

> -----Original Message-----
> From: Schmelter, Ralf <ralf.schmelter at sap.com>
> Sent: Dienstag, 1. Oktober 2019 10:11
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Hotspot dev runtime
> <hotspot-runtime-dev at openjdk.java.net>; Java Core Libs <core-libs-
> dev at openjdk.java.net>
> Subject: RE: RFR (L, final): 8218626: Add detailed message to
> NullPointerException describing what is null.
> 
> Hi Goetz,
> 
> thanks for the additional test. Looks good.
> 
> Best regards,
> Ralf
> 
> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 30. September 2019 18:31
> To: Schmelter, Ralf <ralf.schmelter at sap.com>; Hotspot dev runtime <hotspot-
> runtime-dev at openjdk.java.net>; Java Core Libs <core-libs-
> dev at openjdk.java.net>
> Subject: RE: RFR (L, final): 8218626: Add detailed message to
> NullPointerException describing what is null.
> 
> Hi Ralf,
> 
> > The test should not omit these two bytecodes because the current
> > implementation is the same. This can change and it is not much additional
> code
> > to add the two cases.
> I implemented test cases for the missing invokes:
> 
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/20-incremental/
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/20/
> 
> Best regards,
>   Goetz.
> 
> 


From ivan.gerasimov at oracle.com  Tue Oct  1 20:26:05 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 1 Oct 2019 13:26:05 -0700
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
Message-ID: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>

Hello!

The constructors of SocketPermission and FilePermission expect a String 
argument with comma-separated list of actions.

If the list is malformed, then the constructors throw 
IllegalArgumentException.

It turns out that the current implementation fails to throw IAE if the 
list starts with a leading comma.

Would you please help review a simple fix, which will make the behavior 
more consistent?

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

-- 
With kind regards,
Ivan Gerasimov


From alexey.semenyuk at oracle.com  Tue Oct  1 22:00:41 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 1 Oct 2019 18:00:41 -0400
Subject: RFR: JDK-8231721: jpackage --install-dir should reject system dirs on
 Linux
In-Reply-To: <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@oracle.com>
References: <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@oracle.com>
Message-ID: <ae33201c-338a-0e70-7f67-8717b9b9c758@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

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

[2] http://cr.openjdk.java.net/~asemenyuk/8231721/webrev.00/


From akozlov at azul.com  Tue Oct  1 22:08:37 2019
From: akozlov at azul.com (Anton Kozlov)
Date: Wed, 2 Oct 2019 01:08:37 +0300
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
Message-ID: <01ddb598-ee57-29f7-707a-059370843505@azul.com>



On 30.09.2019 21:18, Mandy Chung wrote:
> Skimming through the implementation, it seems to me that the Runtime::loadLibrary0 does not need to be synchronized. 
> ClassLoader::loadLibrary0 should ensure that a native library of a given name is loaded and registered only once.  

Interesting. I get confused at first by a comment nearby [1]. At first sight, it assumes that Runtime.loadLibrary0 is synchronized. But it's guarded by a monitor of loadedLibraryNames.

May be this will be simpler approach.

[1]: http://hg.openjdk.java.net/jdk/jdk/file/a7c95e2f8814/src/java.base/share/classes/java/lang/ClassLoader.java#l2471

> Can you explain why you think ClassLoader::findLibrary needs to be called with a lock?

I wanted to save findLibrary behavior. The code seems to be there for a long time. I think there are chances some user classLoader could unintentionally depend on findLibrary being called synchronously. For example, a cache for a file system would need a synchronization in custom findLibrary if the outer lock would be removed.

But the lock introduces same deadlock, when class being initialized is loaded from the loader with findLibrary overridden. See the test in updated webrev. Removing synchronization solves the issue. Syncing on loader object fixes the test but only because a classLoader lock is taken when resolve is started. I was unable to find an evidence syncing on the loader would be generally applicable.

New intermediate webrev: (while investigating)

http://cr.openjdk.java.net/~akozlov/8231584/webrev.01/

I removed the sync around findLibrary to resolve the another deadlock; test is improved.

Thanks,
Anton


From alexander.matveev at oracle.com  Tue Oct  1 22:16:46 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 1 Oct 2019 15:16:46 -0700
Subject: RFR: JDK-8231721: jpackage --install-dir should reject system
 dirs on Linux
In-Reply-To: <ae33201c-338a-0e70-7f67-8717b9b9c758@oracle.com>
References: <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@oracle.com>
 <ae33201c-338a-0e70-7f67-8717b9b9c758@oracle.com>
Message-ID: <1723fcd5-8841-1e77-66ce-045daae85845@oracle.com>

Looks good.

On 10/1/19 3:00 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231721
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8231721/webrev.00/
>


From mark.reinhold at oracle.com  Tue Oct  1 22:28:33 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 01 Oct 2019 15:28:33 -0700
Subject: RFR (L,
 final): 8218626: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <AM6PR02MB5347DB97B73443C3CF13438CEC8F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <AM6PR02MB53475B0ECD6B83130AAF445BECB60@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB5347DB97B73443C3CF13438CEC8F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <20191001152833.988974338@eggemoggin.niobe.net>

2019/9/24 1:13:14 -0700, goetz.lindenmaier at sap.com:
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/19/

This is very nice work!  I especially appreciate the thorough tests.

Looking at the tests, and the details of the JEP, I noticed that the
generated messages all end in a period (e.g., ?... is null.?).  This
is pretty unusual in the JDK and jarring to the eye, except in the
rare cases in which an exception message is composed of multiple
distinct sentences.  I?m surprised that no one noticed this before.

As a data point, of the 17,999 messages that I was able to find in
invocations of exception constructors in the JDK 14 library code just
now, only 998 of them end in periods.  (I didn?t look at HotSpot, which
is trickier to grep for such things.)

So, I suggest you drop the trailing periods.

I also noticed that the generated messages use single quotes (?'?) to
quote the names of fields, etc., rather than double quotes (?"?).

On this choice, our corpus is less instructive: Of the 17,999 messages
I gathered, 446 of them use quotes of some sort, 227 of those use double
quotes, and 219 use single quotes.

Even so, I?ll propose here that double quotes are preferable: They?re
consistent with the Java language itself, they?re consistent with common
usage in both American and British English, and they?re less apt to be
confused with single quotes used as apostrophes (e.g., "MemoryHandler
can't load handler target \"" + targetName + "\"").

So, I also suggest that you change the single quotes to double quotes.

Fortunately, and because you have such good tests, this is pretty easy
to do.  Attached is a patch against your patch that makes these changes,
and after which all the tests still pass.

- Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: npe-periods-quotes.patch
Type: text/x-diff
Size: 58848 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20191001/73382aae/npe-periods-quotes-0001.patch>

From brian.burkhalter at oracle.com  Wed Oct  2 00:13:15 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 1 Oct 2019 17:13:15 -0700
Subject: 8229022: BufferedReader performance can be improved by using
 StringBuilder
Message-ID: <7B07B2C3-D10B-4D18-A3EA-2FAFD8972B5C@oracle.com>

While the performance improvement that I measured for this proposed change [1] using JMH was only in the 2% to 8% range as opposed to the 13% claimed in the issue description, given the simplicity of the change [2] it is probably worth doing. All use of the StringBuilder is within a synchronized block within a single package-scope method, so there should be no problem with access by multiple threads.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8229022
[2] diff

--- a/src/java.base/share/classes/java/io/BufferedReader.java
+++ b/src/java.base/share/classes/java/io/BufferedReader.java
@@ -314,7 +314,7 @@
      * @throws     IOException  If an I/O error occurs
      */
     String readLine(boolean ignoreLF, boolean[] term) throws IOException {
-        StringBuffer s = null;
+        StringBuilder s = null;
         int startChar;
 
         synchronized (lock) {
@@ -372,7 +372,7 @@
                 }
 
                 if (s == null)
-                    s = new StringBuffer(defaultExpectedLineLength);
+                    s = new StringBuilder(defaultExpectedLineLength);
                 s.append(cb, startChar, i - startChar);
             }
         }


From ivan.gerasimov at oracle.com  Wed Oct  2 01:02:07 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 1 Oct 2019 18:02:07 -0700
Subject: 8229022: BufferedReader performance can be improved by using
 StringBuilder
In-Reply-To: <7B07B2C3-D10B-4D18-A3EA-2FAFD8972B5C@oracle.com>
References: <7B07B2C3-D10B-4D18-A3EA-2FAFD8972B5C@oracle.com>
Message-ID: <c7057abe-9fd0-b4d5-8c00-721cd6dab011@oracle.com>

Hi Brian!

This looks good to me!

With kind regards,

Ivan


On 10/1/19 5:13 PM, Brian Burkhalter wrote:
> While the performance improvement that I measured for this proposed change [1] using JMH was only in the 2% to 8% range as opposed to the 13% claimed in the issue description, given the simplicity of the change [2] it is probably worth doing. All use of the StringBuilder is within a synchronized block within a single package-scope method, so there should be no problem with access by multiple threads.
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8229022
> [2] diff
>
> --- a/src/java.base/share/classes/java/io/BufferedReader.java
> +++ b/src/java.base/share/classes/java/io/BufferedReader.java
> @@ -314,7 +314,7 @@
>        * @throws     IOException  If an I/O error occurs
>        */
>       String readLine(boolean ignoreLF, boolean[] term) throws IOException {
> -        StringBuffer s = null;
> +        StringBuilder s = null;
>           int startChar;
>   
>           synchronized (lock) {
> @@ -372,7 +372,7 @@
>                   }
>   
>                   if (s == null)
> -                    s = new StringBuffer(defaultExpectedLineLength);
> +                    s = new StringBuilder(defaultExpectedLineLength);
>                   s.append(cb, startChar, i - startChar);
>               }
>           }
>
>

From vyommani at gmail.com  Wed Oct  2 03:49:37 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 2 Oct 2019 09:19:37 +0530
Subject: 8229022: BufferedReader performance can be improved by using
 StringBuilder
In-Reply-To: <7B07B2C3-D10B-4D18-A3EA-2FAFD8972B5C@oracle.com>
References: <7B07B2C3-D10B-4D18-A3EA-2FAFD8972B5C@oracle.com>
Message-ID: <CAKysZ8ySKMiu+KazQHaF5f8jn0gdEBVjkRFRSoSO+payb3Jp5Q@mail.gmail.com>

Hi Brian,
Looks good to me.
thanks,
Vyom

On Wed, Oct 2, 2019 at 5:44 AM Brian Burkhalter <brian.burkhalter at oracle.com>
wrote:

> While the performance improvement that I measured for this proposed change
> [1] using JMH was only in the 2% to 8% range as opposed to the 13% claimed
> in the issue description, given the simplicity of the change [2] it is
> probably worth doing. All use of the StringBuilder is within a synchronized
> block within a single package-scope method, so there should be no problem
> with access by multiple threads.
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8229022
> [2] diff
>
> --- a/src/java.base/share/classes/java/io/BufferedReader.java
> +++ b/src/java.base/share/classes/java/io/BufferedReader.java
> @@ -314,7 +314,7 @@
>       * @throws     IOException  If an I/O error occurs
>       */
>      String readLine(boolean ignoreLF, boolean[] term) throws IOException {
> -        StringBuffer s = null;
> +        StringBuilder s = null;
>          int startChar;
>
>          synchronized (lock) {
> @@ -372,7 +372,7 @@
>                  }
>
>                  if (s == null)
> -                    s = new StringBuffer(defaultExpectedLineLength);
> +                    s = new StringBuilder(defaultExpectedLineLength);
>                  s.append(cb, startChar, i - startChar);
>              }
>          }
>
>

-- 
Thanks,
Vyom

From andrew_m_leonard at uk.ibm.com  Wed Oct  2 08:10:54 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Wed, 2 Oct 2019 09:10:54 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
Message-ID: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>

Hi,
Please can I request a review of this performance enhancement for EBCDIC 
(and any SingleByte, always compactable) charsets? I've explained the 
theory in the bug (https://bugs.openjdk.java.net/browse/JDK-8231717), but 
essentially it optimizes any SingleByte charset that is always compactable 
due to all mappings being to <=0xff and avoids unnecessary char[] to 
internal Latin1 byte[] arraycopy as a result. This leads to up to a 100% 
performance gain for decoding these charsets.
I have run the complete tier1 and also the complete sun/nio/cs testcases 
successfully.

Webrev: http://cr.openjdk.java.net/~aleonard/8231717/webrev.00/

Thoughts and comments welcome please?
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From julia.boes at oracle.com  Wed Oct  2 09:36:41 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Wed, 2 Oct 2019 10:36:41 +0100
Subject: RFR (XS): 8231161: Wrong return type in code sample in Collector API
 documentation
Message-ID: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>

Hi,

This is a minor fix of the Collector class-level documentation, where 
the wrong type declaration was used in a code sample.

While at it, I added a compilation test for all code samples of this 
class-level javadoc.


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

Webrev: 
http://cr.openjdk.java.net/~jboes/webrevs/8231161/webrev.00/index.html


Regards,

Julia


From daniel.fuchs at oracle.com  Wed Oct  2 10:01:18 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 2 Oct 2019 11:01:18 +0100
Subject: 8229022: BufferedReader performance can be improved by using
 StringBuilder
In-Reply-To: <7B07B2C3-D10B-4D18-A3EA-2FAFD8972B5C@oracle.com>
References: <7B07B2C3-D10B-4D18-A3EA-2FAFD8972B5C@oracle.com>
Message-ID: <d757d70d-5224-4b5b-33d2-977c25b4fc6d@oracle.com>

Hi Brian,

Looks good to me.

On 02/10/2019 01:13, Brian Burkhalter wrote:
> While the performance improvement that I measured for this proposed change [1] using JMH was only in the 2% to 8% range as opposed to the 13% claimed in the issue description, given the simplicity of the change [2] it is probably worth doing. All use of the StringBuilder is within a synchronized block within a single package-scope method, so there should be no problem with access by multiple threads.

The StringBuffer is a local in the readLine method and
doesn't escape - so whether or not it's accessed within a synchronized
block should not matter. It's safe to replace it with StringBuilder
indeed!

best regards,

-- daniel

> 
> Thanks,
> 
> Brian
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8229022
> [2] diff
> 
> --- a/src/java.base/share/classes/java/io/BufferedReader.java
> +++ b/src/java.base/share/classes/java/io/BufferedReader.java
> @@ -314,7 +314,7 @@
>        * @throws     IOException  If an I/O error occurs
>        */
>       String readLine(boolean ignoreLF, boolean[] term) throws IOException {
> -        StringBuffer s = null;
> +        StringBuilder s = null;
>           int startChar;
>   
>           synchronized (lock) {
> @@ -372,7 +372,7 @@
>                   }
>   
>                   if (s == null)
> -                    s = new StringBuffer(defaultExpectedLineLength);
> +                    s = new StringBuilder(defaultExpectedLineLength);
>                   s.append(cb, startChar, i - startChar);
>               }
>           }
> 


From lance.andersen at oracle.com  Wed Oct  2 10:49:49 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 2 Oct 2019 06:49:49 -0400
Subject: RFR (XS): 8231161: Wrong return type in code sample in Collector
 API documentation
In-Reply-To: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>
References: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>
Message-ID: <1BF7684D-5DD6-4F75-9A6F-FA4E9A4595D8@oracle.com>

Hi Julia,

This looks good.   

Best
Lance

> On Oct 2, 2019, at 5:36 AM, Julia Boes <julia.boes at oracle.com> wrote:
> 
> Hi,
> 
> This is a minor fix of the Collector class-level documentation, where the wrong type declaration was used in a code sample.
> 
> While at it, I added a compilation test for all code samples of this class-level javadoc.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231161
> 
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231161/webrev.00/index.html
> 
> 
> Regards,
> 
> Julia
> 

 <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 goetz.lindenmaier at sap.com  Wed Oct  2 12:45:10 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 2 Oct 2019 12:45:10 +0000
Subject: RFR (L, final): 8218626: Add detailed message to
 NullPointerException describing what is null.
In-Reply-To: <20191001152833.988974338@eggemoggin.niobe.net>
References: <AM6PR02MB53475B0ECD6B83130AAF445BECB60@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB5347DB97B73443C3CF13438CEC8F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <20191001152833.988974338@eggemoggin.niobe.net>
Message-ID: <AM6PR02MB53472419205F89652DCB11D0EC9C0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi Mark, 

thanks for looking at my change! Can I add you as reviewer?

This webrev incorporates your patch as well as two fixes of 
issues that sneaked in implementing some recent reviews:
bytecodeUtils.cpp:449  1 --> 1ULL 
bytecodeUtils.cpp:460  move assertion to where len is known.
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/21-incremental/
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/21/

> This is very nice work!  I especially appreciate the thorough tests.
Thanks!  But adapting the many tests to changed messages is 
quite cumbersome :) Thanks for supplying the patch right away!

> Looking at the tests, and the details of the JEP, I noticed that the
> generated messages all end in a period (e.g., ?... is null.?).  This
> is pretty unusual in the JDK and jarring to the eye
Actually, for me as a foreign speaker, proper punctuation makes
it easier to understand. Reading a statement without '.' makes
me feel it's incomplete. Intuitively, I try to complete it somehow if the
grammar does not make it obvious that it is a complete sentence.
But I will follow your advice here if no one else objects the other
way.

> I also noticed that the generated messages use single quotes (?'?) to
> quote the names of fields, etc., rather than double quotes (?"?).
I'm fine with this, but I think hotspot uses "'" for citing code
quite consistently. E.g., have a look at 
http://hg.openjdk.java.net/jdk/jdk/file/b25362cec8ce/src/hotspot/share/interpreter/linkResolver.cpp
This can easily be changed.  I could do a separate change 
for hotspot and change all uses of ' in exceptions to ". What 
do you think?

Best regards,
  Goetz.





From sverre.moe at gmail.com  Wed Oct  2 13:41:38 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Wed, 2 Oct 2019 15:41:38 +0200
Subject: Comments on jpackage (JEP 343)
In-Reply-To: <CALAJ+5CVoBhbTG85is8bi0BfSNdA2omxOGZ8SoKyuid9EiwyqA@mail.gmail.com>
References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net>
 <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com>
 <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com>
 <20190919102519.205163004@eggemoggin.niobe.net>
 <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com>
 <CALAJ+5CVoBhbTG85is8bi0BfSNdA2omxOGZ8SoKyuid9EiwyqA@mail.gmail.com>
Message-ID: <CALAJ+5CZs85b-Rf73CGwRi6FgVvS4OZivUUwB3xxuBGkEjb31Q@mail.gmail.com>

ons. 25. sep. 2019 kl. 15:45 skrev Sverre Moe <sverre.moe at gmail.com>:

> I have some new comments regarding the Windows build of jpackage.
>
> 1)
> Is there any way to build an trusted application installer using WiX?
> I want to avoid "Unknown Publisher" when installing the application.
> Also having problems with Windows Defender SmartScreen, depending on what
> settings the user has (Block, Warn, Off).
> If Block, the user cannot install the application. If Warn, the user can
> click "More info", then "Run anyway".
>
>>
>>
I have looked into this. It can be done with using tools like insignia [1]
and signtool [2].

It can be done after the MSI has been built by jpackage using the tool
SignTool from the Microsoft SDK.
I successfully managed to sign the MSI and EXE built by jpackage:
> $ /cygdrive/c/Program\ Files\ \(x86\)/Windows\
Kits/10/bin/10.0.18362.0/x64/signtool.exe sign /v /a /d "Application
Installer" /f "cert.pfx" /p certpass /fd SHA256 /t
http://timestamp.digicert.com build/native/application-1.1.0.msi

It could also be beneficial to sign the application executable in the
application image prior to creating the application installer package.
Since the native application executable does not have write access after
being constructed by jpackage, then in order to use signtool on it I had to
modify the file permissions.

I have yet to find out how to do it with WiX.

[1] https://wixtoolset.org/documentation/manual/v3/overview/insignia.html
[2] https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool

/Sverre

From chris.hegarty at oracle.com  Wed Oct  2 13:44:41 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 2 Oct 2019 14:44:41 +0100
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
Message-ID: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>

Ivan,

On 01/10/2019 21:26, Ivan Gerasimov wrote:
> Hello!
> 
> The constructors of SocketPermission and FilePermission expect a String 
> argument with comma-separated list of actions.
> 
> If the list is malformed, then the constructors throw 
> IllegalArgumentException.
> 
> It turns out that the current implementation fails to throw IAE if the 
> list starts with a leading comma.
> 
> Would you please help review a simple fix, which will make the behavior 
> more consistent?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/

The implementation changes look ok.

The SocketPermission constructor should be updated to specify IAE too, 
right?

-Chris.


From Roger.Riggs at oracle.com  Wed Oct  2 13:48:31 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 2 Oct 2019 09:48:31 -0400
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
Message-ID: <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>

Hi Andrew,

This would seem to have an impact on the performance of every Decoder 
constructor
because it determines dynamically the isAlwaysCompactable attribute.
Are there regressions in the non-EBCDIC cases?

Did your performance tests include the constructor overhead?

The isASCIICompatible case is handled by checking for negatives only 
when needed.

Unless the information is used more than once it looks like you've moved 
the computation
from StringCoding hasNegatives to the Decoder constructor.

Is there a change that would benefit both the isASCIICompatible case and 
EBCDIC?

Is there a reason you didn't add the isAlwaysCompactable method to the 
existing ArrayDecoder interface.
I don't think there there is a need for a new interface.

Thanks, Roger

On 10/2/19 4:10 AM, Andrew Leonard wrote:
> Hi,
> Please can I request a review of this performance enhancement for EBCDIC
> (and any SingleByte, always compactable) charsets? I've explained the
> theory in the bug (https://bugs.openjdk.java.net/browse/JDK-8231717), but
> essentially it optimizes any SingleByte charset that is always compactable
> due to all mappings being to <=0xff and avoids unnecessary char[] to
> internal Latin1 byte[] arraycopy as a result. This leads to up to a 100%
> performance gain for decoding these charsets.
> I have run the complete tier1 and also the complete sun/nio/cs testcases
> successfully.
>
> Webrev: http://cr.openjdk.java.net/~aleonard/8231717/webrev.00/
>
> Thoughts and comments welcome please?
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>


From alexey.semenyuk at oracle.com  Wed Oct  2 14:04:56 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 2 Oct 2019 10:04:56 -0400
Subject: Comments on jpackage (JEP 343)
In-Reply-To: <CALAJ+5CZs85b-Rf73CGwRi6FgVvS4OZivUUwB3xxuBGkEjb31Q@mail.gmail.com>
References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net>
 <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com>
 <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com>
 <20190919102519.205163004@eggemoggin.niobe.net>
 <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com>
 <CALAJ+5CVoBhbTG85is8bi0BfSNdA2omxOGZ8SoKyuid9EiwyqA@mail.gmail.com>
 <CALAJ+5CZs85b-Rf73CGwRi6FgVvS4OZivUUwB3xxuBGkEjb31Q@mail.gmail.com>
Message-ID: <16d6a435-128c-099d-ac80-a551ebb44b51@oracle.com>

Hi Sverre,

Thank you for doing this research. I don't think we should complicate 
jpackage by adding signing steps in it.
However we can add a call to custom script after msi is constructed but 
before it get embedded in exe installer.
This script can sign msi.
We already support call of custom script from resource dir before 
building msi. Just need to add another call.

- Alexey

On 10/2/2019 9:41 AM, Sverre Moe wrote:
> ons. 25. sep. 2019 kl. 15:45 skrev Sverre Moe <sverre.moe at gmail.com>:
>
>> I have some new comments regarding the Windows build of jpackage.
>>
>> 1)
>> Is there any way to build an trusted application installer using WiX?
>> I want to avoid "Unknown Publisher" when installing the application.
>> Also having problems with Windows Defender SmartScreen, depending on what
>> settings the user has (Block, Warn, Off).
>> If Block, the user cannot install the application. If Warn, the user can
>> click "More info", then "Run anyway".
>>
>>>
> I have looked into this. It can be done with using tools like insignia [1]
> and signtool [2].
>
> It can be done after the MSI has been built by jpackage using the tool
> SignTool from the Microsoft SDK.
> I successfully managed to sign the MSI and EXE built by jpackage:
>> $ /cygdrive/c/Program\ Files\ \(x86\)/Windows\
> Kits/10/bin/10.0.18362.0/x64/signtool.exe sign /v /a /d "Application
> Installer" /f "cert.pfx" /p certpass /fd SHA256 /t
> http://timestamp.digicert.com build/native/application-1.1.0.msi
>
> It could also be beneficial to sign the application executable in the
> application image prior to creating the application installer package.
> Since the native application executable does not have write access after
> being constructed by jpackage, then in order to use signtool on it I had to
> modify the file permissions.
>
> I have yet to find out how to do it with WiX.
>
> [1] https://wixtoolset.org/documentation/manual/v3/overview/insignia.html
> [2] https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool
>
> /Sverre


From Roger.Riggs at oracle.com  Wed Oct  2 14:53:36 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 2 Oct 2019 10:53:36 -0400
Subject: 8231663: Incorrect GPL header in some RMI/SQL package-info.java files
Message-ID: <c6fb5b17-a7fe-3d14-68c5-e3d57568acb5@oracle.com>

Please review a few trivial changes in rmi and sql to remove extraneous 
<p> tags.

Webrev:
 ? http://cr.openjdk.java.net/~rriggs/webrev-header-cleanup-8231663/

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

Thanks, Roger


From brian.burkhalter at oracle.com  Wed Oct  2 14:56:56 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Oct 2019 07:56:56 -0700
Subject: 8231663: Incorrect GPL header in some RMI/SQL package-info.java
 files
In-Reply-To: <c6fb5b17-a7fe-3d14-68c5-e3d57568acb5@oracle.com>
References: <c6fb5b17-a7fe-3d14-68c5-e3d57568acb5@oracle.com>
Message-ID: <16DF543B-43B0-497A-BA54-579F4A0FD31C@oracle.com>

Hi Roger,

+1

Brian

> On Oct 2, 2019, at 7:53 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review a few trivial changes in rmi and sql to remove extraneous <p> tags.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-header-cleanup-8231663/
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8231663
> 
> Thanks, Roger
> 


From andy.herrick at oracle.com  Wed Oct  2 15:08:38 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 2 Oct 2019 11:08:38 -0400
Subject: Jpackage EA build available
Message-ID: <f9ec129f-a729-e9f6-9551-7cb0a5786bd6@oracle.com>


The next EA build of JPackage is available at https://jdk.java.net/jpackage/

Build 14-jpackage+1-49 (2019/10/2) contains the following changes (since 
Build Build 14-jpackage+1-33 on 2019/08/19)

JDK-8230649 Make jpackage tool an experimental feature
JDK-8230519 jpackage "--package-type" values and default
JDK-8230521 rename --output/-o option and add default value (".")
JDK-8230507 Findings in Debian packaging
JDK-8231280 Linux packages produced by jpackage should have correct 
dependencies
JDK-8231277 Adjust Linux application image layout
JDK-8231279 Change install location for copyright file for Debian package
JDK-8225447 Revise Debian packaging
JDK-8228660 .deb files generated by jpackage don't follow naming convention
JDK-8230191 Replace javacup logo with duke everywhere in jpackage
JDK-8229788 Error dialog displays with DLL issue when installing 
WinChooserTest application
JDK-8230920 jpackage problems when -input dir contains any files with 
"cfg" extension.
JDK-8231281 Eliminate the --identifier option
JDK-8231605 Improve test helpers
JDK-8230974 creating rpm, get error for relative path to the license.txt
JDK-8230927 Wrong arguments set for additional launchers
JDK-8230899 NoSuchFileException when using jpackage on Linux to create a 
deb installer
JDK-8231282 JDK-8230507 Revisit --linux-deb-copyright option
JDK-8230654 jpackage package-type dmg on macOS
JDK-8225249 LinuxDebBundler and LinuxRpmBundler should share more code
JDK-8215381 Investigate if current implementation of --license-file is 
correct for Debian packages
JDK-8229779 Shortcut creation policy
JDK-8230629 jpackage signing on macOS does not work as expected
JDK-8230522 rename "--linux-bundle-name", and "--temp-root" options.
JDK-8230653 jpackage error on macOS system without xcode
JDK-8230726 Improve jpackage jtreg tests
JDK-8229840 Add jtreg test for --linux-app-category option
JDK-8229841 Add jtreg test for --linux-app-release option
JDK-8229979 jpackage cleanup src files, help text, and javadoc
JDK-8231382 Use main class from main module if available
JDK-8230651 Use version string from main module
JDK-8223211 Remove old code from service support
JDK-8230152 No appropriate error message when wix tools missing.
JDK-8224833 jpackages differences between platforms

please send feedback to core-libs-dev at openjdk.java.net

/Andy Herrick


From lance.andersen at oracle.com  Wed Oct  2 15:57:29 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 2 Oct 2019 11:57:29 -0400
Subject: 8231663: Incorrect GPL header in some RMI/SQL package-info.java
 files
In-Reply-To: <c6fb5b17-a7fe-3d14-68c5-e3d57568acb5@oracle.com>
References: <c6fb5b17-a7fe-3d14-68c5-e3d57568acb5@oracle.com>
Message-ID: <699516C7-960D-4900-87AB-5B807205C2E1@oracle.com>

+1
> On Oct 2, 2019, at 10:53 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review a few trivial changes in rmi and sql to remove extraneous <p> tags.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-header-cleanup-8231663/
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8231663
> 
> Thanks, Roger
> 

 <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 sverre.moe at gmail.com  Wed Oct  2 16:33:10 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Wed, 2 Oct 2019 18:33:10 +0200
Subject: Comments on jpackage (JEP 343)
In-Reply-To: <16d6a435-128c-099d-ac80-a551ebb44b51@oracle.com>
References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net>
 <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com>
 <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com>
 <20190919102519.205163004@eggemoggin.niobe.net>
 <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com>
 <CALAJ+5CVoBhbTG85is8bi0BfSNdA2omxOGZ8SoKyuid9EiwyqA@mail.gmail.com>
 <CALAJ+5CZs85b-Rf73CGwRi6FgVvS4OZivUUwB3xxuBGkEjb31Q@mail.gmail.com>
 <16d6a435-128c-099d-ac80-a551ebb44b51@oracle.com>
Message-ID: <CALAJ+5D-BKAz5-b9vv3JiZ+U-uQMoomDyv7g-bxpMqyrYedEFg@mail.gmail.com>

ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk <
alexey.semenyuk at oracle.com>:

> Hi Sverre,
>
> Thank you for doing this research. I don't think we should complicate
> jpackage by adding signing steps in it.
> However we can add a call to custom script after msi is constructed but
> before it get embedded in exe installer.
> This script can sign msi.

We already support call of custom script from resource dir before
> building msi. Just need to add another call.
>
> - Alexey
>

I can certainly use the custom application-post-image.wsf to sign the
application image executable. However I don't think it would be easy
considering that this executable is left read-only by jpackage.

When it comes to signing the MSI and EXE installers, that can be done after
running jpackage with a Gradle Exec task.

/Sverre

From andrew_m_leonard at uk.ibm.com  Wed Oct  2 16:54:58 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Wed, 2 Oct 2019 17:54:58 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
Message-ID: <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>

Hi Roger,
Thank you for the feedback.
So your point about constructor performance is a good one, in my 
performance tests in which I have run both the StrCodingBenchmark.java 
test and also some simple standalone tests, I did not see any noticeable 
degradation for charsets that are not alwaysCompactable(), but I will look 
closer at that one. It has made me think though that I can do the 
isAlwaysCompactable determination at static init time, since the table is 
obviously static...I will investigate that optimization.

The change is actually not just EBCDIC, as I point out in the bug it's any 
SingleByte charset that is determined as "alwaysCompactable", I specified 
EBCDIC in the bug title as it is actually just about only the EBCDIC 
charsets that fall into this category. I can rename the "title" maybe?

The "negatives" check for isASCIICompatible is done only on the input 
bytes when the given charset "isASCIICompatible" as you said. This change 
is not related to hasNegatives() so not sure I quite understand the point 
about moving it? hasNegatives() is relavent to the input byte[] being 
decoded as if it contains negatives it will need complete mapping even for 
an isASCIICompatible charset. isAlwaysCompactable is about the charset in 
general, and can (and I think should) be computed at static init time, as 
it's simply determined by the fact that the static b2c[] table maps only 
to values 0->0xff.

EBCDIC codepages are not ASCIICompatible as they don't map directly, so 
you cannot combine the two, they are independent scenario fastpaths.

If I add a default impl for decodeToLatin1() I could add the methods to 
ArrayDecoder, I will look at that. I think I did it that way as I didn't 
want to affect anyone that may have implemented ArrayDecoder separately...

Thanks for the review, I will look at the static init of 
alwaysCompactable, and move the methods to ArrayDecoder, and do a closer 
check on constructor performance at the end of that.
Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Roger Riggs <Roger.Riggs at oracle.com>
To:     core-libs-dev at openjdk.java.net
Date:   02/10/2019 14:52
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS
Sent by:        "core-libs-dev" <core-libs-dev-bounces at openjdk.java.net>



Hi Andrew,

This would seem to have an impact on the performance of every Decoder 
constructor
because it determines dynamically the isAlwaysCompactable attribute.
Are there regressions in the non-EBCDIC cases?

Did your performance tests include the constructor overhead?

The isASCIICompatible case is handled by checking for negatives only 
when needed.

Unless the information is used more than once it looks like you've moved 
the computation
from StringCoding hasNegatives to the Decoder constructor.

Is there a change that would benefit both the isASCIICompatible case and 
EBCDIC?

Is there a reason you didn't add the isAlwaysCompactable method to the 
existing ArrayDecoder interface.
I don't think there there is a need for a new interface.

Thanks, Roger

On 10/2/19 4:10 AM, Andrew Leonard wrote:
> Hi,
> Please can I request a review of this performance enhancement for EBCDIC
> (and any SingleByte, always compactable) charsets? I've explained the
> theory in the bug (
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8231717&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=-rKUlQuiG0c80g_6taHF1xicVgTGLhZC0DQZzIrZC54&s=rZFusfU4b1q1rCMGEv_Ex05kXpMHHWdHsZdEbue6Oz0&e= 
), but
> essentially it optimizes any SingleByte charset that is always 
compactable
> due to all mappings being to <=0xff and avoids unnecessary char[] to
> internal Latin1 byte[] arraycopy as a result. This leads to up to a 100%
> performance gain for decoding these charsets.
> I have run the complete tier1 and also the complete sun/nio/cs testcases
> successfully.
>
> Webrev: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8231717_webrev.00_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=-rKUlQuiG0c80g_6taHF1xicVgTGLhZC0DQZzIrZC54&s=LvQIS6ORN5ZsNhwROkLLLEy_LXKv_v3FLrSCuxhPeDc&e= 

>
> Thoughts and comments welcome please?
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From iris.clark at oracle.com  Wed Oct  2 16:54:33 2019
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 2 Oct 2019 09:54:33 -0700 (PDT)
Subject: 8231663: Incorrect GPL header in some RMI/SQL package-info.java
 files
In-Reply-To: <c6fb5b17-a7fe-3d14-68c5-e3d57568acb5@oracle.com>
References: <c6fb5b17-a7fe-3d14-68c5-e3d57568acb5@oracle.com>
Message-ID: <11e710a8-9971-4803-926c-992cc39038d4@default>

Hi, Roger.

   http://cr.openjdk.java.net/~rriggs/webrev-header-cleanup-8231663/

+1

Thanks,
Iris

From alexey.semenyuk at oracle.com  Wed Oct  2 17:14:12 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 2 Oct 2019 13:14:12 -0400
Subject: Comments on jpackage (JEP 343)
In-Reply-To: <CALAJ+5D-BKAz5-b9vv3JiZ+U-uQMoomDyv7g-bxpMqyrYedEFg@mail.gmail.com>
References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net>
 <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com>
 <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com>
 <20190919102519.205163004@eggemoggin.niobe.net>
 <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com>
 <CALAJ+5CVoBhbTG85is8bi0BfSNdA2omxOGZ8SoKyuid9EiwyqA@mail.gmail.com>
 <CALAJ+5CZs85b-Rf73CGwRi6FgVvS4OZivUUwB3xxuBGkEjb31Q@mail.gmail.com>
 <16d6a435-128c-099d-ac80-a551ebb44b51@oracle.com>
 <CALAJ+5D-BKAz5-b9vv3JiZ+U-uQMoomDyv7g-bxpMqyrYedEFg@mail.gmail.com>
Message-ID: <908aa486-c06e-dd21-5c1b-64cce99dbf79@oracle.com>



On 10/2/2019 12:33 PM, Sverre Moe wrote:
> ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk 
> <alexey.semenyuk at oracle.com <mailto:alexey.semenyuk at oracle.com>>:
>
>     Hi Sverre,
>
>     Thank you for doing this research. I don't think we should complicate
>     jpackage by adding signing steps in it.
>     However we can add a call to custom script after msi is
>     constructed but
>     before it get embedded in exe installer.
>     This script can sign msi.
>
>     We already support call of custom script from resource dir before
>     building msi. Just need to add another call.
>
>     - Alexey
>
> I can certainly use the custom application-post-image.wsf to sign the 
> application image executable. However I don't think it would be easy 
> considering that this executable is left read-only by jpackage.
I didn't mean to sign application image executable. This opportunity is 
already available.
I meant we can add to jpackage functionality to call custom script after 
msi is created but before it get embedded in exe installer.
Exe installer produced by jpackage is just a container for msi 
installer. Before msi will be put in the container there will be an 
opportunity to modify (sign) the msi.
Currently the steps to create exe installer are:
1.1 Create app image
1.2 Call application-post-image.wsf if available
2. Create msi from app image
3. Create exe from msi

It will be changed to:
1.1 Create app image
1.2 Call application-post-image.wsf if available
2.1 Create msi from app image
2.2 Call application-post-msi.wsf if available
3. Create exe from msi

- Alexey

>
> When it comes to signing the MSI and EXE installers, that can be done 
> after running jpackage with a Gradle Exec task.
>
> /Sverre


From sverre.moe at gmail.com  Wed Oct  2 17:23:12 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Wed, 2 Oct 2019 19:23:12 +0200
Subject: Comments on jpackage (JEP 343)
In-Reply-To: <908aa486-c06e-dd21-5c1b-64cce99dbf79@oracle.com>
References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net>
 <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com>
 <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com>
 <20190919102519.205163004@eggemoggin.niobe.net>
 <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com>
 <CALAJ+5CVoBhbTG85is8bi0BfSNdA2omxOGZ8SoKyuid9EiwyqA@mail.gmail.com>
 <CALAJ+5CZs85b-Rf73CGwRi6FgVvS4OZivUUwB3xxuBGkEjb31Q@mail.gmail.com>
 <16d6a435-128c-099d-ac80-a551ebb44b51@oracle.com>
 <CALAJ+5D-BKAz5-b9vv3JiZ+U-uQMoomDyv7g-bxpMqyrYedEFg@mail.gmail.com>
 <908aa486-c06e-dd21-5c1b-64cce99dbf79@oracle.com>
Message-ID: <CALAJ+5D9RmrxC0hi4K8Fa5dsukHa3=ysZ8+tb9dDhYmtWUkrWA@mail.gmail.com>

ons. 2. okt. 2019 kl. 19:14 skrev Alexey Semenyuk <
alexey.semenyuk at oracle.com>:

>
>
> On 10/2/2019 12:33 PM, Sverre Moe wrote:
>
> ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk <
> alexey.semenyuk at oracle.com>:
>
>> Hi Sverre,
>>
>> Thank you for doing this research. I don't think we should complicate
>> jpackage by adding signing steps in it.
>> However we can add a call to custom script after msi is constructed but
>> before it get embedded in exe installer.
>> This script can sign msi.
>
> We already support call of custom script from resource dir before
>> building msi. Just need to add another call.
>>
>> - Alexey
>>
>
> I can certainly use the custom application-post-image.wsf to sign the
> application image executable. However I don't think it would be easy
> considering that this executable is left read-only by jpackage.
>
> I didn't mean to sign application image executable. This opportunity is
> already available.
>

Maybe I have missed something, but I cannot see this is available for
jpackage to sign the application image executable.


> I meant we can add to jpackage functionality to call custom script after
> msi is created but before it get embedded in exe installer.
> Exe installer produced by jpackage is just a container for msi installer.
> Before msi will be put in the container there will be an opportunity to
> modify (sign) the msi.
> Currently the steps to create exe installer are:
> 1.1 Create app image
> 1.2 Call application-post-image.wsf if available
> 2. Create msi from app image
> 3. Create exe from msi
>
> It will be changed to:
> 1.1 Create app image
> 1.2 Call application-post-image.wsf if available
> 2.1 Create msi from app image
> 2.2 Call application-post-msi.wsf if available
> 3. Create exe from msi
>
> - Alexey
>
> Thanks for making it much clearer.

/Sverre

From Roger.Riggs at oracle.com  Wed Oct  2 18:26:55 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 2 Oct 2019 14:26:55 -0400
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
Message-ID: <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>

Hi Andrew,


On 10/2/19 12:54 PM, Andrew Leonard wrote:
> Hi Roger,
> Thank you for the feedback.
> So your point about constructor performance is a good one, in my 
> performance tests in which I have run both the StrCodingBenchmark.java 
> test and also some simple standalone tests, I did not see any 
> noticeable degradation for charsets that are not alwaysCompactable(), 
> but I will look closer at that one. It has made me think though that I 
> can do the isAlwaysCompactable determination at static init time, 
> since the table is obviously static...I will investigate that 
> optimization.
>
> The change is actually not just EBCDIC, as I point out in the bug it's 
> any SingleByte charset that is determined as "alwaysCompactable", I 
> specified EBCDIC in the bug title as it is actually just about only 
> the EBCDIC charsets that fall into this category. I can rename the 
> "title" maybe?

So I think the name should be closer to everything that can be 
decoded/mapped to Latin1 or 8-bit clean.
>
>
> The "negatives" check for isASCIICompatible is done only on the input 
> bytes when the given charset "isASCIICompatible" as you said. This 
> change is not related to hasNegatives() so not sure I quite understand 
> the point about moving it? hasNegatives() is relavent to the input 
> byte[] being decoded as if it contains negatives it will need complete 
> mapping even for an isASCIICompatible charset.
ok
> isAlwaysCompactable is about the charset in general, and can (and I 
> think should) be computed at static init time, as it's simply 
> determined by the fact that the static b2c[] table maps only to values 
> 0->0xff.
>
> EBCDIC codepages are not ASCIICompatible as they don't map directly, 
> so you cannot combine the two, they are independent scenario fastpaths.
rigth, there is a mapping needed.
>
>
> If I add a default impl for decodeToLatin1() I could add the methods 
> to ArrayDecoder, I will look at that. I think I did it that way as I 
> didn't want to affect anyone that may have implemented ArrayDecoder 
> separately...
I was also thinking of ISO_8859_1, that doesn't need a mapping,
and trying to avoid a multiple separate decisions and data paths.
(while keeping the code simple)

Thanks, Roger

>
>
> Thanks for the review, I will look at the static init of 
> alwaysCompactable, and move the methods to ArrayDecoder, and do a 
> closer check on constructor performance at the end of that.
> Cheers
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From: Roger Riggs <Roger.Riggs at oracle.com>
> To: core-libs-dev at openjdk.java.net
> Date: 02/10/2019 14:52
> Subject: Re: RFR: 8231717: Improve performance of EBCDIC charset 
> decoding for COMPACT_STRINGS
> Sent by: "core-libs-dev" <core-libs-dev-bounces at openjdk.java.net>
> ------------------------------------------------------------------------
>
>
>
> Hi Andrew,
>
> This would seem to have an impact on the performance of every Decoder
> constructor
> because it determines dynamically the isAlwaysCompactable attribute.
> Are there regressions in the non-EBCDIC cases?
>
> Did your performance tests include the constructor overhead?
>
> The isASCIICompatible case is handled by checking for negatives only
> when needed.
>
> Unless the information is used more than once it looks like you've moved
> the computation
> from StringCoding hasNegatives to the Decoder constructor.
>
> Is there a change that would benefit both the isASCIICompatible case and
> EBCDIC?
>
> Is there a reason you didn't add the isAlwaysCompactable method to the
> existing ArrayDecoder interface.
> I don't think there there is a need for a new interface.
>
> Thanks, Roger
>
> On 10/2/19 4:10 AM, Andrew Leonard wrote:
> > Hi,
> > Please can I request a review of this performance enhancement for EBCDIC
> > (and any SingleByte, always compactable) charsets? I've explained the
> > theory in the bug 
> (https://bugs.openjdk.java.net/browse/JDK-8231717), but
> > essentially it optimizes any SingleByte charset that is always 
> compactable
> > due to all mappings being to <=0xff and avoids unnecessary char[] to
> > internal Latin1 byte[] arraycopy as a result. This leads to up to a 100%
> > performance gain for decoding these charsets.
> > I have run the complete tier1 and also the complete sun/nio/cs testcases
> > successfully.
> >
> > Webrev: http://cr.openjdk.java.net/~aleonard/8231717/webrev.00/
> >
> > Thoughts and comments welcome please?
> > Thanks
> > Andrew
> >
> > Andrew Leonard
> > Java Runtimes Development
> > IBM Hursley
> > IBM United Kingdom Ltd
> > internet email: andrew_m_leonard at uk.ibm.com
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
> >
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From alexander.matveev at oracle.com  Wed Oct  2 21:34:53 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 2 Oct 2019 14:34:53 -0700
Subject: RFR: JDK-8215895: Verify and create tests for Mac installer specific
 signing options
Message-ID: <59b2f5e5-fa43-c52c-dac8-7f0c13ac9f92@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Added two signing tests for macOS. One test checks signing app image 
and second checks pkg and dmg.
- These test will not be run if machine is not configured with required 
signing certificates and will throw jtreg.SkippedException.
- Increase timeouts for two tests which where failing due to timeout 
intermittently.

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

[2] http://cr.openjdk.java.net/~almatvee/8215895/webrev.00/

Thanks,
Alexander

From mark.reinhold at oracle.com  Wed Oct  2 22:40:45 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 02 Oct 2019 15:40:45 -0700
Subject: RFR (L,
 final): 8218626: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <AM6PR02MB53472419205F89652DCB11D0EC9C0@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <AM6PR02MB53475B0ECD6B83130AAF445BECB60@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB5347DB97B73443C3CF13438CEC8F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <20191001152833.988974338@eggemoggin.niobe.net>
 <AM6PR02MB53472419205F89652DCB11D0EC9C0@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <20191002154045.380207158@eggemoggin.niobe.net>

2019/10/2 5:45:10 -0700, goetz.lindenmaier at sap.com:
> thanks for looking at my change! Can I add you as reviewer?

Sure.

>> This is very nice work!  I especially appreciate the thorough tests.
> 
> Thanks!  But adapting the many tests to changed messages is 
> quite cumbersome :) Thanks for supplying the patch right away!

Nothing that a little Emacs-fu can?t handle.

>> ...
>> 
>> I also noticed that the generated messages use single quotes (?'?) to
>> quote the names of fields, etc., rather than double quotes (?"?).
> 
> I'm fine with this, but I think hotspot uses "'" for citing code
> quite consistently. E.g., have a look at 
> http://hg.openjdk.java.net/jdk/jdk/file/b25362cec8ce/src/hotspot/share/interpreter/linkResolver.cpp
> This can easily be changed.  I could do a separate change 
> for hotspot and change all uses of ' in exceptions to ". What 
> do you think?

I think that?d be a fine clean-up task, for later.

- Mark

From mandy.chung at oracle.com  Wed Oct  2 22:59:07 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 2 Oct 2019 15:59:07 -0700
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <01ddb598-ee57-29f7-707a-059370843505@azul.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
Message-ID: <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>

On 10/1/19 3:08 PM, Anton Kozlov wrote:
> New intermediate webrev: (while investigating)
>
> http://cr.openjdk.java.net/~akozlov/8231584/webrev.01/

Just on the test, instead of storing Target and Target2 classfile bytes 
in the source, the test can use jdk.test.lib.compiler.CompilerUtils to 
compile these two test classes in a separate destination read by the 
TestClassLoader.

Mandy

From paul.sellards at gmail.com  Wed Oct  2 20:50:40 2019
From: paul.sellards at gmail.com (Paul Sellards)
Date: Wed, 2 Oct 2019 14:50:40 -0600
Subject: jpackage: Build 14-jpackage+1-49 (2019/10/2)
Message-ID: <CAKOXi89vzss=eSmZU48pb674-ByzSquacnp0LG2TgQ0uynQF4g@mail.gmail.com>

First off, I want to say "Thanks!" to everyone for their efforts on
jpackage, it's desperately needed by those of us building thick client
JavaFX applications.

Possible Bug (or maybe the JEP-343 web page / docs need more clarity):

The --win-menu-group <menu-group-name> option isn't working on Windows 10
unless --win-menu is also present:


*eg:  Fails*

jpackage ....   --win-menu-group Shoozaloo

Nothing appears in the Windows start menu for the group Shoozaloo.
However, the program does install, execute and uninstall correctly.

----------------------

*eg: Succeeds*

jpackage ....   --win-menu --win-menu-group Shoozaloo

This appears to work properly, it shows up in the Shoozaloo group and
everything else works fine. But it was not clear in the docs, and I would
recommend that specifying --win-menu-group should imply --win-menu.  If
nothing else, spitting out a warning message would be helpful.

But thanks again for the early access builds.  And keep up the good work!
I think it's crucial to get this into the Java 14 release.

Cheers,

Paul




-- 

Paul Sellards

paul.sellards at gmail.com

From ivan.gerasimov at oracle.com  Wed Oct  2 23:26:05 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 2 Oct 2019 16:26:05 -0700
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
 <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>
Message-ID: <d847bf13-83bc-c1a8-0a22-baa3b9a93dc3@oracle.com>

Hi Chris!

Thank you very much for review!

I agree that it makes sense to update the javadoc for consistency.

I don't think CSR is required in this case, is it? (IAE is unchecked 
anyway, and the fix doesn't really change the behavior.)

Here's the updated webrev:

http://cr.openjdk.java.net/~igerasim/8230407/01/webrev/

With kind regards,

Ivan


On 10/2/19 6:44 AM, Chris Hegarty wrote:
> Ivan,
>
> On 01/10/2019 21:26, Ivan Gerasimov wrote:
>> Hello!
>>
>> The constructors of SocketPermission and FilePermission expect a 
>> String argument with comma-separated list of actions.
>>
>> If the list is malformed, then the constructors throw 
>> IllegalArgumentException.
>>
>> It turns out that the current implementation fails to throw IAE if 
>> the list starts with a leading comma.
>>
>> Would you please help review a simple fix, which will make the 
>> behavior more consistent?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/
>
> The implementation changes look ok.
>
> The SocketPermission constructor should be updated to specify IAE too, 
> right?
>
> -Chris.
>
>
-- 
With kind regards,
Ivan Gerasimov


From joe.darcy at oracle.com  Wed Oct  2 23:38:34 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 2 Oct 2019 16:38:34 -0700
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <d847bf13-83bc-c1a8-0a22-baa3b9a93dc3@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
 <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>
 <d847bf13-83bc-c1a8-0a22-baa3b9a93dc3@oracle.com>
Message-ID: <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com>

Hello,

At least from a quick reading, either the spec change or the behavior 
change would seem to merit a CSR.

Cheers,

-Joe

On 10/2/2019 4:26 PM, Ivan Gerasimov wrote:
> Hi Chris!
>
> Thank you very much for review!
>
> I agree that it makes sense to update the javadoc for consistency.
>
> I don't think CSR is required in this case, is it? (IAE is unchecked 
> anyway, and the fix doesn't really change the behavior.)
>
> Here's the updated webrev:
>
> http://cr.openjdk.java.net/~igerasim/8230407/01/webrev/
>
> With kind regards,
>
> Ivan
>
>
> On 10/2/19 6:44 AM, Chris Hegarty wrote:
>> Ivan,
>>
>> On 01/10/2019 21:26, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> The constructors of SocketPermission and FilePermission expect a 
>>> String argument with comma-separated list of actions.
>>>
>>> If the list is malformed, then the constructors throw 
>>> IllegalArgumentException.
>>>
>>> It turns out that the current implementation fails to throw IAE if 
>>> the list starts with a leading comma.
>>>
>>> Would you please help review a simple fix, which will make the 
>>> behavior more consistent?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/
>>
>> The implementation changes look ok.
>>
>> The SocketPermission constructor should be updated to specify IAE 
>> too, right?
>>
>> -Chris.
>>
>>

From joe.darcy at oracle.com  Thu Oct  3 00:09:41 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 2 Oct 2019 17:09:41 -0700
Subject: JDK 14 RFR of JDK-8231777: Remove extraneous @serial javadoc tag in
 NodeChangeEvent.java
Message-ID: <d687b465-b0d9-b555-a2ac-08998e564127@oracle.com>

Hello,

In response to the review of JDK-8231546:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062612.html

it was noticed a field in NodeChangeEvent.java has an @serial javadoc 
tag, but the class itself is @serial excluded so the @serial tag on the 
field is extraneous.

Please review the removal of the extraneous tag:

diff -r 91d236715160 
src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java
--- a/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java 
Tue Oct 01 20:07:30 2019 -0700
+++ b/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java 
Wed Oct 02 17:05:48 2019 -0700
@@ -46,8 +46,6 @@
 ?public class NodeChangeEvent extends java.util.EventObject {
 ???? /**
 ????? * The node that was added or removed.
-???? *
-???? * @serial
 ????? */
 ???? private transient Preferences child;

Thanks,

-Joe


From alexander.matveev at oracle.com  Thu Oct  3 01:54:39 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 2 Oct 2019 18:54:39 -0700
Subject: RFR: JDK-8231706: Investigate if we can change "Java" dir to "app"
 dir in jpackage app image
Message-ID: <4afadb0e-fca6-e64f-f381-e545482a4c76@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Changed "Java" dir to "app" dir in jpackage app image on macOS.

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

[2] http://cr.openjdk.java.net/~almatvee/8231706/webrev.00/

Thanks,
Alexander

From alexey.semenyuk at oracle.com  Thu Oct  3 02:48:18 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 2 Oct 2019 22:48:18 -0400
Subject: RFR: JDK-8231706: Investigate if we can change "Java" dir to
 "app" dir in jpackage app image
In-Reply-To: <4afadb0e-fca6-e64f-f381-e545482a4c76@oracle.com>
References: <4afadb0e-fca6-e64f-f381-e545482a4c76@oracle.com>
Message-ID: <801bd2b1-ad2e-2f81-dd77-3fff93af81c0@oracle.com>

Looks good.

- Alexey

On 10/2/2019 9:54 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Changed "Java" dir to "app" dir in jpackage app image on macOS.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231706
>
> [2] http://cr.openjdk.java.net/~almatvee/8231706/webrev.00/
>
> Thanks,
> Alexander


From philip.race at oracle.com  Thu Oct  3 02:52:28 2019
From: philip.race at oracle.com (Phil Race)
Date: Wed, 2 Oct 2019 19:52:28 -0700
Subject: RFR: JDK-8231706: Investigate if we can change "Java" dir to
 "app" dir in jpackage app image
In-Reply-To: <801bd2b1-ad2e-2f81-dd77-3fff93af81c0@oracle.com>
References: <4afadb0e-fca6-e64f-f381-e545482a4c76@oracle.com>
 <801bd2b1-ad2e-2f81-dd77-3fff93af81c0@oracle.com>
Message-ID: <8B892D50-5C1B-4397-9B64-6BF276E38C81@oracle.com>

Please remove ?investigate? from the synopsis. Everywhere.

-Phil.

> On Oct 2, 2019, at 7:48 PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
> 
> Looks good.
> 
> - Alexey
> 
>> On 10/2/2019 9:54 PM, Alexander Matveev wrote:
>> Please review the jpackage fix for bug [1] at [2].
>> 
>> This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage).
>> 
>> - Changed "Java" dir to "app" dir in jpackage app image on macOS.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231706
>> 
>> [2] http://cr.openjdk.java.net/~almatvee/8231706/webrev.00/
>> 
>> Thanks,
>> Alexander
> 


From ivan.gerasimov at oracle.com  Thu Oct  3 03:41:20 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 2 Oct 2019 20:41:20 -0700
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
 <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>
 <d847bf13-83bc-c1a8-0a22-baa3b9a93dc3@oracle.com>
 <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com>
Message-ID: <ec843455-fe57-4826-a546-54bb4ab0b8ef@oracle.com>

Thank you Joe for checking it!

On 10/2/19 4:38 PM, Joe Darcy wrote:
> Hello,
>
> At least from a quick reading, either the spec change or the behavior 
> change would seem to merit a CSR.
>
Sigh.? I was hopping it'll be a quick fix :-)

So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to 
cover the addition of @throws paragraph in the javadoc of SocketPermission.

I would really appreciate it, if someone helped to review it.

W.r.t the behavior change, I don't think the fix has to be counted as 
such. ? Current implementation already would throw 
IllegalArgumentException if the action list were malformed (for example 
if it were " , accept", or "connect,,accept", or "connect,", etc.)? The 
only case when it would *not* throw IAE is when the argument 
*immediately* starts with a comma, and that's what the fix is about.

It's not like if we used to allow commas in arbitrary places and stopped 
doing that.? Instead, it just turned out that the code fails to catch 
one specific pattern of malformed action list.

With kind regards,

Ivan


> Cheers,
>
> -Joe
>
> On 10/2/2019 4:26 PM, Ivan Gerasimov wrote:
>> Hi Chris!
>>
>> Thank you very much for review!
>>
>> I agree that it makes sense to update the javadoc for consistency.
>>
>> I don't think CSR is required in this case, is it? (IAE is unchecked 
>> anyway, and the fix doesn't really change the behavior.)
>>
>> Here's the updated webrev:
>>
>> http://cr.openjdk.java.net/~igerasim/8230407/01/webrev/
>>
>> With kind regards,
>>
>> Ivan
>>
>>
>> On 10/2/19 6:44 AM, Chris Hegarty wrote:
>>> Ivan,
>>>
>>> On 01/10/2019 21:26, Ivan Gerasimov wrote:
>>>> Hello!
>>>>
>>>> The constructors of SocketPermission and FilePermission expect a 
>>>> String argument with comma-separated list of actions.
>>>>
>>>> If the list is malformed, then the constructors throw 
>>>> IllegalArgumentException.
>>>>
>>>> It turns out that the current implementation fails to throw IAE if 
>>>> the list starts with a leading comma.
>>>>
>>>> Would you please help review a simple fix, which will make the 
>>>> behavior more consistent?
>>>>
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/
>>>
>>> The implementation changes look ok.
>>>
>>> The SocketPermission constructor should be updated to specify IAE 
>>> too, right?
>>>
>>> -Chris.
>>>
>>>
>
-- 
With kind regards,
Ivan Gerasimov


From peter.levart at gmail.com  Thu Oct  3 06:40:52 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 3 Oct 2019 08:40:52 +0200
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
Message-ID: <5e3525d3-bced-f65d-8fb3-b4cf3bae6ca2@gmail.com>

Hi Ivan,

On 10/1/19 10:26 PM, Ivan Gerasimov wrote:
> Hello!
>
> The constructors of SocketPermission and FilePermission expect a 
> String argument with comma-separated list of actions.
>
> If the list is malformed, then the constructors throw 
> IllegalArgumentException.
>
> It turns out that the current implementation fails to throw IAE if the 
> list starts with a leading comma.
>
> Would you please help review a simple fix, which will make the 
> behavior more consistent?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/
>

With new switch expressions the logic could be a little clearer. For 
example:

 ??????????? for (boolean seencomma = false; i >= matchlen && 
!seencomma; i--) {
 ??????????????? seencomma = switch (a[i - matchlen]) {
 ??????????????????? case ' ', '\r', '\n', '\f', '\t': yield false;
 ??????????????????? case ',': if (i > matchlen) yield true;
 ??????????????????? default: throw new IllegalArgumentException(
 ??????????????????????????????? "invalid permission: " + actions);
 ??????????????? };
 ??????????? }


This is still experimental, but I think it will be proposed to be 
standard soon.

If you want to backport it later, then maybe you don't want to do that now.

Regards, Peter


From Alan.Bateman at oracle.com  Thu Oct  3 07:44:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 3 Oct 2019 08:44:21 +0100
Subject: JDK 14 RFR of JDK-8231777: Remove extraneous @serial javadoc tag
 in NodeChangeEvent.java
In-Reply-To: <d687b465-b0d9-b555-a2ac-08998e564127@oracle.com>
References: <d687b465-b0d9-b555-a2ac-08998e564127@oracle.com>
Message-ID: <10ecd83a-2dba-b955-725c-d615416b1d8c@oracle.com>

On 03/10/2019 01:09, Joe Darcy wrote:
> Hello,
>
> In response to the review of JDK-8231546:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062612.html 
>
>
> it was noticed a field in NodeChangeEvent.java has an @serial javadoc 
> tag, but the class itself is @serial excluded so the @serial tag on 
> the field is extraneous.
>
Looks fine.

From jan.lahoda at oracle.com  Thu Oct  3 09:57:34 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 3 Oct 2019 11:57:34 +0200
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
Message-ID: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>

Hi,

This is a continuation of Joe's patch from here:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html

APIs associated with preview features are split into two groups: 
essential and non-essential. These are marked with an JDK-internal 
annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
javac follows the PreviewFeature annotation, and produces either 
warnings or errors for the usages of such APIs. For the @preview tag, 
there is a taglet in the JDK build that adds the content of the tag into 
the documentation. The first part of the @preview's text goes into the 
summary, the second part goes into the detailed description.

For build, a tricky problem is that the jdk.compiler module uses the 
PreviewFeature annotation as well, but that is not in the bootstrap JDK. 
So, for the intermediate langtools build, the PreviewFeature annotation 
is copied from java.base.

Proposed webrev:
http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/

Javadoc with the change:
http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html

See for example:
http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html
http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html

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

CSR:
https://bugs.openjdk.java.net/browse/JDK-8231411

Feedback is welcome!

Thanks,
     Jan

From andy.herrick at oracle.com  Thu Oct  3 11:43:26 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 3 Oct 2019 07:43:26 -0400
Subject: RFR: JDK-8231706: Investigate if we can change "Java" dir to
 "app" dir in jpackage app image
In-Reply-To: <8B892D50-5C1B-4397-9B64-6BF276E38C81@oracle.com>
References: <4afadb0e-fca6-e64f-f381-e545482a4c76@oracle.com>
 <801bd2b1-ad2e-2f81-dd77-3fff93af81c0@oracle.com>
 <8B892D50-5C1B-4397-9B64-6BF276E38C81@oracle.com>
Message-ID: <02652e2e-3ffe-2d9c-743b-ebd9ba222c51@oracle.com>

"investigate" is appropriate verb for a task, but not a bug or enhancement.

When proposing a fix please (along with changing the synopsis) change 
the Issue from a task to a bug or an enhancement.

/Andy

On 10/2/2019 10:52 PM, Phil Race wrote:
> Please remove ?investigate? from the synopsis. Everywhere.
>
> -Phil.
>
>> On Oct 2, 2019, at 7:48 PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>
>> Looks good.
>>
>> - Alexey
>>
>>> On 10/2/2019 9:54 PM, Alexander Matveev wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage).
>>>
>>> - Changed "Java" dir to "app" dir in jpackage app image on macOS.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231706
>>>
>>> [2] http://cr.openjdk.java.net/~almatvee/8231706/webrev.00/
>>>
>>> Thanks,
>>> Alexander

From andy.herrick at oracle.com  Thu Oct  3 11:51:53 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 3 Oct 2019 07:51:53 -0400
Subject: RFR: JDK-8231706: Investigate if we can change "Java" dir to
 "app" dir in jpackage app image
In-Reply-To: <4afadb0e-fca6-e64f-f381-e545482a4c76@oracle.com>
References: <4afadb0e-fca6-e64f-f381-e545482a4c76@oracle.com>
Message-ID: <a592dd80-636f-a45a-f1c7-055bfc7593e5@oracle.com>

change looks good.

/Andy

On 10/2/2019 9:54 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Changed "Java" dir to "app" dir in jpackage app image on macOS.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231706
>
> [2] http://cr.openjdk.java.net/~almatvee/8231706/webrev.00/
>
> Thanks,
> Alexander

From chris.hegarty at oracle.com  Thu Oct  3 13:25:59 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 3 Oct 2019 14:25:59 +0100
Subject: JDK 14 RFR of JDK-8231777: Remove extraneous @serial javadoc tag
 in NodeChangeEvent.java
In-Reply-To: <d687b465-b0d9-b555-a2ac-08998e564127@oracle.com>
References: <d687b465-b0d9-b555-a2ac-08998e564127@oracle.com>
Message-ID: <F44AEC38-D184-4E5C-9E72-94907B7B4825@oracle.com>


> On 3 Oct 2019, at 01:09, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> In response to the review of JDK-8231546:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062612.html
> 
> it was noticed a field in NodeChangeEvent.java has an @serial javadoc tag, but the class itself is @serial excluded so the @serial tag on the field is extraneous.
> 
> Please review the removal of the extraneous tag:
> 
> diff -r 91d236715160 src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java
> --- a/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Tue Oct 01 20:07:30 2019 -0700
> +++ b/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Wed Oct 02 17:05:48 2019 -0700
> @@ -46,8 +46,6 @@
>  public class NodeChangeEvent extends java.util.EventObject {
>      /**
>       * The node that was added or removed.
> -     *
> -     * @serial
>       */
>      private transient Preferences child;
> 

Looks good to me.

-Chris

From adam.farley at uk.ibm.com  Thu Oct  3 14:53:22 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Thu, 3 Oct 2019 15:53:22 +0100
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
Message-ID: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>

Hey all,

Four GPLv2 files in 8u seem to be missing the classpath exception from the 
copyright section.

Requesting reviews and a sponsor.

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

Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/

Best Regards

Adam Farley 
IBM Runtimes

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From sgehwolf at redhat.com  Thu Oct  3 15:02:28 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 03 Oct 2019 17:02:28 +0200
Subject: [8u] RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
Message-ID: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com>

Hi Adam,

This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing
list (jdk8u-dev not jdk-updates-dev; bcc'ed the latter) and fixing the
subject line.

Thanks,
Severin

On Thu, 2019-10-03 at 15:53 +0100, Adam Farley8 wrote:
> Hey all,
> 
> Four GPLv2 files in 8u seem to be missing the classpath exception from the 
> copyright section.
> 
> Requesting reviews and a sponsor.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
> 
> Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
> 
> Best Regards
> 
> Adam Farley 
> IBM Runtimes
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 


From chris.hegarty at oracle.com  Thu Oct  3 15:05:27 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 3 Oct 2019 16:05:27 +0100
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <ec843455-fe57-4826-a546-54bb4ab0b8ef@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
 <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>
 <d847bf13-83bc-c1a8-0a22-baa3b9a93dc3@oracle.com>
 <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com>
 <ec843455-fe57-4826-a546-54bb4ab0b8ef@oracle.com>
Message-ID: <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com>

Ivan,

> On 3 Oct 2019, at 04:41, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> ...
> 
> So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover the addition of @throws paragraph in the javadoc of SocketPermission.
> 
> I would really appreciate it, if someone helped to review it.
> 
Since we?re here ... ;-)
It would be good to specify the NPE behavior of the constructor. Here are the changes for SocketPermission. If you agree, fold them into your patch and CSR. ( I?ve included test changes to verify the new tighter spec )

https://cr.openjdk.java.net/~chegar/8230407.extra/

-Chris.



From joe.darcy at oracle.com  Thu Oct  3 15:32:47 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 3 Oct 2019 08:32:47 -0700
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
Message-ID: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>

Hello,

In response to the recent and on-going review of serializable types in 
the base module and elsewhere, I thought it would be helpful if the 
collections specs discussed how collections were serialiazable. In 
particular, the proposed terminology is that a collection is 
"conditionally serializable" if the collection type implements 
java.io.Serializable and all the elements of the collections are 
serializable.

Candidate wording changes to java.util.Collection below. If this notion 
is deemed useful, I can also go through and add "This collection is 
conditionally serializable."notes to ArrayList, HashMap, and other such 
collections.

Thoughts?

Thanks,

-Joe


--- a/src/java.base/share/classes/java/util/Collection.java Tue Oct 01 
20:07:30 2019 -0700
+++ b/src/java.base/share/classes/java/util/Collection.java??? Wed Oct 
02 22:58:04 2019 -0700
@@ -188,6 +188,17 @@
 ? * or if the only reference to the backing collection is through an
 ? * unmodifiable view, the view can be considered effectively immutable.
 ? *
+ * <h2><a id="condserial">Serializable Collections</a></h2>
+ *
+ * Many collection types implement {@link
+ * java.io.Serializable}. Typically such collections are
+ * <i>conditionally serializable</i>, if all the objects in the
+ * collection are serializable, the collection as a whole can be
+ * serialized. Otherwise, is one or more objects in a collection are
+ * <em>not<em> serializable, the collection cannot be serialized and a
+ * {@link java.io.NotSerializableException} may be thrown on attempts
+ * to serialize such a collection.
+ *
 ? * <p>This interface is a member of the
 ? * <a 
href="{@docRoot}/java.base/java/util/package-summary.html#CollectionsFramework">
 ? * Java Collections Framework</a>.


From erik.joelsson at oracle.com  Thu Oct  3 16:06:00 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 3 Oct 2019 09:06:00 -0700
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
Message-ID: <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>

Hello Jan,

The build change looks ok, but I would recommend this construct for 
copying the file instead:

$(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
 ??? FILES := 
$(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \
 ??? DEST := 
$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, 
\
))

TARGETS += $(COPY_PREVIEW_FEATURES)

Then you automatically get all the corner case handling we have 
implemented over the years for logging, making directories and copying 
files. Your version is still correct for this case though.

/Erik

On 2019-10-03 02:57, Jan Lahoda wrote:
> Hi,
>
> This is a continuation of Joe's patch from here:
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>
>
> APIs associated with preview features are split into two groups: 
> essential and non-essential. These are marked with an JDK-internal 
> annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
> javac follows the PreviewFeature annotation, and produces either 
> warnings or errors for the usages of such APIs. For the @preview tag, 
> there is a taglet in the JDK build that adds the content of the tag 
> into the documentation. The first part of the @preview's text goes 
> into the summary, the second part goes into the detailed description.
>
> For build, a tricky problem is that the jdk.compiler module uses the 
> PreviewFeature annotation as well, but that is not in the bootstrap 
> JDK. So, for the intermediate langtools build, the PreviewFeature 
> annotation is copied from java.base.
>
> Proposed webrev:
> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>
> Javadoc with the change:
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>
> See for example:
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8226585
>
> CSR:
> https://bugs.openjdk.java.net/browse/JDK-8231411
>
> Feedback is welcome!
>
> Thanks,
> ??? Jan

From stuart.marks at oracle.com  Thu Oct  3 17:44:04 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 3 Oct 2019 10:44:04 -0700
Subject: RFR (XS): 8231161: Wrong return type in code sample in Collector
 API documentation
In-Reply-To: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>
References: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>
Message-ID: <f95aa4b8-4e5b-ec23-bd38-df4d6aaa2fca@oracle.com>



On 10/2/19 2:36 AM, Julia Boes wrote:
> This is a minor fix of the Collector class-level documentation, where the wrong 
> type declaration was used in a code sample.
> 
> While at it, I added a compilation test for all code samples of this class-level 
> javadoc.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231161
> 
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231161/webrev.00/index.html

Hi Julia,

Thanks for this small fix and for writing the test.

A couple very tiny comments on the test:
  - sort the import lines
  - remove extra blank lines at end

Otherwise it looks great.

Did you need a sponsor for this change?

s'marks

From julia.boes at oracle.com  Thu Oct  3 18:05:59 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Thu, 3 Oct 2019 19:05:59 +0100
Subject: RFR (XS): 8231161: Wrong return type in code sample in Collector
 API documentation
In-Reply-To: <f95aa4b8-4e5b-ec23-bd38-df4d6aaa2fca@oracle.com>
References: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>
 <f95aa4b8-4e5b-ec23-bd38-df4d6aaa2fca@oracle.com>
Message-ID: <5881af65-da17-386c-b186-7088aa6b0320@oracle.com>

Hi Stuart,

Thanks for the review. I made the changes you mentioned.

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231161/webrev.01/

If you would like to sponsor for this change, that would be great!

Regards,

Julia

On 03/10/2019 18:44, Stuart Marks wrote:
>
>
> On 10/2/19 2:36 AM, Julia Boes wrote:
>> This is a minor fix of the Collector class-level documentation, where 
>> the wrong type declaration was used in a code sample.
>>
>> While at it, I added a compilation test for all code samples of this 
>> class-level javadoc.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231161
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~jboes/webrevs/8231161/webrev.00/index.html
>
> Hi Julia,
>
> Thanks for this small fix and for writing the test.
>
> A couple very tiny comments on the test:
> ?- sort the import lines
> ?- remove extra blank lines at end
>
> Otherwise it looks great.
>
> Did you need a sponsor for this change?
>
> s'marks

From fw at deneb.enyo.de  Thu Oct  3 20:42:52 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 03 Oct 2019 22:42:52 +0200
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 (Adam Farley8's message of "Thu, 3 Oct 2019 15:53:22 +0100")
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
Message-ID: <87mueh5zn7.fsf@mid.deneb.enyo.de>

* Adam Farley8:

> Four GPLv2 files in 8u seem to be missing the classpath exception from the 
> copyright section.
>
> Requesting reviews and a sponsor.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
>
> Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/

All these files are not used at run time, so this could be deliberate.

From alexander.matveev at oracle.com  Thu Oct  3 22:10:22 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 3 Oct 2019 15:10:22 -0700
Subject: RFR: JDK-8215895: Verify and create tests for Mac installer
 specific signing options
In-Reply-To: <59b2f5e5-fa43-c52c-dac8-7f0c13ac9f92@oracle.com>
References: <59b2f5e5-fa43-c52c-dac8-7f0c13ac9f92@oracle.com>
Message-ID: <e61a1e11-7623-d37e-bc63-bfcf7a991bb9@oracle.com>

http://cr.openjdk.java.net/~almatvee/8215895/webrev.01/

Changes since webrev.00 as per Alexey suggestions:
- Reverted "@library /test/lib" jtreg directive when it is not needed.
- jtreg.SkippedException exceptions will be used through reflection.
- Other minor tweaks.

Thanks,
Alexander

On 10/2/2019 2:34 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Added two signing tests for macOS. One test checks signing app image 
> and second checks pkg and dmg.
> - These test will not be run if machine is not configured with 
> required signing certificates and will throw jtreg.SkippedException.
> - Increase timeouts for two tests which where failing due to timeout 
> intermittently.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8215895
>
> [2] http://cr.openjdk.java.net/~almatvee/8215895/webrev.00/
>
> Thanks,
> Alexander


From joe.darcy at oracle.com  Thu Oct  3 22:30:14 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 3 Oct 2019 15:30:14 -0700
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <87mueh5zn7.fsf@mid.deneb.enyo.de>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 <87mueh5zn7.fsf@mid.deneb.enyo.de>
Message-ID: <a651b203-0348-c077-4b8c-b73a6a2d784c@oracle.com>

It is customary to have the license of a file be updated from someone 
affiliated with the copyright holder of the file.

-Joe

On 10/3/2019 1:42 PM, Florian Weimer wrote:
> * Adam Farley8:
>
>> Four GPLv2 files in 8u seem to be missing the classpath exception from the
>> copyright section.
>>
>> Requesting reviews and a sponsor.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
>>
>> Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
> All these files are not used at run time, so this could be deliberate.

From alexey.semenyuk at oracle.com  Thu Oct  3 22:32:36 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 3 Oct 2019 18:32:36 -0400
Subject: RFR: JDK-8215895: Verify and create tests for Mac installer
 specific signing options
In-Reply-To: <e61a1e11-7623-d37e-bc63-bfcf7a991bb9@oracle.com>
References: <59b2f5e5-fa43-c52c-dac8-7f0c13ac9f92@oracle.com>
 <e61a1e11-7623-d37e-bc63-bfcf7a991bb9@oracle.com>
Message-ID: <98f1d7a0-0bc1-eb2c-95ed-15cd4855e180@oracle.com>

Looks good.

- Alexey

On 10/3/2019 6:10 PM, Alexander Matveev wrote:
> http://cr.openjdk.java.net/~almatvee/8215895/webrev.01/
>
> Changes since webrev.00 as per Alexey suggestions:
> - Reverted "@library /test/lib" jtreg directive when it is not needed.
> - jtreg.SkippedException exceptions will be used through reflection.
> - Other minor tweaks.
>
> Thanks,
> Alexander
>
> On 10/2/2019 2:34 PM, Alexander Matveev wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> - Added two signing tests for macOS. One test checks signing app 
>> image and second checks pkg and dmg.
>> - These test will not be run if machine is not configured with 
>> required signing certificates and will throw jtreg.SkippedException.
>> - Increase timeouts for two tests which where failing due to timeout 
>> intermittently.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8215895
>>
>> [2] http://cr.openjdk.java.net/~almatvee/8215895/webrev.00/
>>
>> Thanks,
>> Alexander
>


From alexey.semenyuk at oracle.com  Fri Oct  4 00:17:00 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 3 Oct 2019 20:17:00 -0400
Subject: RFR: JDK-8231850: BasicTest test fails in jcov build
In-Reply-To: <ae33201c-338a-0e70-7f67-8717b9b9c758@oracle.com>
References: <ae33201c-338a-0e70-7f67-8717b9b9c758@oracle.com>
Message-ID: <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

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

[2] http://cr.openjdk.java.net/~asemenyuk/8231850/webrev.00/


From alexander.matveev at oracle.com  Fri Oct  4 01:18:43 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 3 Oct 2019 18:18:43 -0700
Subject: RFR: JDK-8231850: BasicTest test fails in jcov build
In-Reply-To: <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
References: <ae33201c-338a-0e70-7f67-8717b9b9c758@oracle.com>
 <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
Message-ID: <a2461328-7a15-d0c2-080a-1afe0efb0e10@oracle.com>

Looks good.

On 10/3/2019 5:17 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231850
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8231850/webrev.00/
>


From ivan.gerasimov at oracle.com  Fri Oct  4 01:36:42 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 3 Oct 2019 18:36:42 -0700
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <5e3525d3-bced-f65d-8fb3-b4cf3bae6ca2@gmail.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
 <5e3525d3-bced-f65d-8fb3-b4cf3bae6ca2@gmail.com>
Message-ID: <26e0fa0e-bc5d-32a1-05d9-e7fdf511d14b@oracle.com>

Thanks Peter, your variant looks cute!

Let's keep this code in mind as a candidate for refactoring once the 
switch expression will make its way to the standard.

I would hesitate to allow using experimental features in building the 
JDK just for that code :)

With kind regards,

Ivan


On 10/2/19 11:40 PM, Peter Levart wrote:
> Hi Ivan,
>
> On 10/1/19 10:26 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> The constructors of SocketPermission and FilePermission expect a 
>> String argument with comma-separated list of actions.
>>
>> If the list is malformed, then the constructors throw 
>> IllegalArgumentException.
>>
>> It turns out that the current implementation fails to throw IAE if 
>> the list starts with a leading comma.
>>
>> Would you please help review a simple fix, which will make the 
>> behavior more consistent?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/
>>
>
> With new switch expressions the logic could be a little clearer. For 
> example:
>
> ??????????? for (boolean seencomma = false; i >= matchlen && 
> !seencomma; i--) {
> ??????????????? seencomma = switch (a[i - matchlen]) {
> ??????????????????? case ' ', '\r', '\n', '\f', '\t': yield false;
> ??????????????????? case ',': if (i > matchlen) yield true;
> ??????????????????? default: throw new IllegalArgumentException(
> ??????????????????????????????? "invalid permission: " + actions);
> ??????????????? };
> ??????????? }
>
>
> This is still experimental, but I think it will be proposed to be 
> standard soon.
>
> If you want to backport it later, then maybe you don't want to do that 
> now.
>
> Regards, Peter
>
-- 
With kind regards,
Ivan Gerasimov


From ivan.gerasimov at oracle.com  Fri Oct  4 02:00:45 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 3 Oct 2019 19:00:45 -0700
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
 <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>
 <d847bf13-83bc-c1a8-0a22-baa3b9a93dc3@oracle.com>
 <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com>
 <ec843455-fe57-4826-a546-54bb4ab0b8ef@oracle.com>
 <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com>
Message-ID: <d95ebd77-fc6d-798c-94ee-cefe85762342@oracle.com>

Hi Chris!

On 10/3/19 8:05 AM, Chris Hegarty wrote:
> Ivan,
>
>> On 3 Oct 2019, at 04:41, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> ...
>>
>> So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover the addition of @throws paragraph in the javadoc of SocketPermission.
>>
>> I would really appreciate it, if someone helped to review it.
>>
> Since we?re here ... ;-)
> It would be good to specify the NPE behavior of the constructor. Here are the changes for SocketPermission. If you agree, fold them into your patch and CSR. ( I?ve included test changes to verify the new tighter spec )
>
> https://cr.openjdk.java.net/~chegar/8230407.extra/

Yes, it's a good point, thanks!

I've adopted your suggested changes and the test:
http://cr.openjdk.java.net/~igerasim/8230407/02/webrev/

CSR was also updated accordingly:
https://bugs.openjdk.java.net/browse/JDK-8231805

With kind regards,

Ivan


> -Chris.
>
>
>
-- 
With kind regards,
Ivan Gerasimov


From joe.darcy at oracle.com  Fri Oct  4 05:08:20 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 3 Oct 2019 22:08:20 -0700
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
Message-ID: <d6ce5be2-2cc0-afdc-6e2f-54851c9239fb@oracle.com>

Hi Jan,

For future work, consider having a "Preview Methods" tag alongside 
static, instance, deprecated, etc.

Cheers,

-Joe

On 10/3/2019 2:57 AM, Jan Lahoda wrote:
> Hi,
>
> This is a continuation of Joe's patch from here:
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>
>
> APIs associated with preview features are split into two groups: 
> essential and non-essential. These are marked with an JDK-internal 
> annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
> javac follows the PreviewFeature annotation, and produces either 
> warnings or errors for the usages of such APIs. For the @preview tag, 
> there is a taglet in the JDK build that adds the content of the tag 
> into the documentation. The first part of the @preview's text goes 
> into the summary, the second part goes into the detailed description.
>
> For build, a tricky problem is that the jdk.compiler module uses the 
> PreviewFeature annotation as well, but that is not in the bootstrap 
> JDK. So, for the intermediate langtools build, the PreviewFeature 
> annotation is copied from java.base.
>
> Proposed webrev:
> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>
> Javadoc with the change:
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>
> See for example:
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8226585
>
> CSR:
> https://bugs.openjdk.java.net/browse/JDK-8231411
>
> Feedback is welcome!
>
> Thanks,
> ??? Jan

From chris.hegarty at oracle.com  Fri Oct  4 08:32:22 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 4 Oct 2019 09:32:22 +0100
Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list
 allows leading comma
In-Reply-To: <d95ebd77-fc6d-798c-94ee-cefe85762342@oracle.com>
References: <f3466cc6-94e7-3ef2-536f-ee2a8b6e9ab7@oracle.com>
 <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com>
 <d847bf13-83bc-c1a8-0a22-baa3b9a93dc3@oracle.com>
 <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com>
 <ec843455-fe57-4826-a546-54bb4ab0b8ef@oracle.com>
 <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com>
 <d95ebd77-fc6d-798c-94ee-cefe85762342@oracle.com>
Message-ID: <6EE5B925-A874-46E7-981F-91B18D3E48AA@oracle.com>

Ivan,

> On 4 Oct 2019, at 03:00, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> ...
> 
> I've adopted your suggested changes and the test:
> http://cr.openjdk.java.net/~igerasim/8230407/02/webrev/ <http://cr.openjdk.java.net/~igerasim/8230407/02/webrev/>

LGTM.

> CSR was also updated accordingly:
> https://bugs.openjdk.java.net/browse/JDK-8231805 <https://bugs.openjdk.java.net/browse/JDK-8231805>

I added myself as reviewer.

-Chris.

From adam.farley at uk.ibm.com  Fri Oct  4 09:11:08 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 4 Oct 2019 10:11:08 +0100
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <87mueh5zn7.fsf@mid.deneb.enyo.de>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 <87mueh5zn7.fsf@mid.deneb.enyo.de>
Message-ID: <OF99840D1B.53AF32F5-ON00258489.00308BD8-80258489.00327630@notes.na.collabserv.com>

Heya Florian

Thanks for your thoughts.

My understanding of the nuances of GPLv2 is limited, but a layman's 
summary 
could describe GPLv2 as "contagious", so it seems best to have all the 
GPLv2-licensed code tagged as having Classpath Exception just in case they 

end up "infecting" code that does wind up going into the build, now or 
in the future.

Also, I noticed EquivMapsGenerator.java had the ClasspathException added
in JDK10 (in JDK-8193758), so I took that as confirmation of my "best to
have it just in case" theory.

Best Regards

Adam Farley 
IBM Runtimes


Florian Weimer <fw at deneb.enyo.de> wrote on 03/10/2019 21:42:52:

> From: Florian Weimer <fw at deneb.enyo.de>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: "Java Core Libs" <core-libs-dev at openjdk.java.net>, jdk-updates-
> dev at openjdk.java.net
> Date: 03/10/2019 21:43
> Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
> 
> * Adam Farley8:
> 
> > Four GPLv2 files in 8u seem to be missing the classpath exception from 
the 
> > copyright section.
> >
> > Requesting reviews and a sponsor.
> >
> > Bug: https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwIBAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=Y8tDGK7rXbdaljgwaK8pn-
> poy8EHnM_ejjnBOmRkAhg&s=AnbS5uD9ZZ2e2vebZ9xoQJN_mL5ADEPBVQed5001LsM&e= 
> >
> > Webrev: https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwIBAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=Y8tDGK7rXbdaljgwaK8pn-
> poy8EHnM_ejjnBOmRkAhg&s=5CCzOuLThZf0dIwnNaR8-FkIAM_6di17eHkNT57vbbA&e= 
> 
> All these files are not used at run time, so this could be deliberate.
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From adam.farley at uk.ibm.com  Fri Oct  4 09:12:42 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 4 Oct 2019 10:12:42 +0100
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <a651b203-0348-c077-4b8c-b73a6a2d784c@oracle.com>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 <87mueh5zn7.fsf@mid.deneb.enyo.de>
 <a651b203-0348-c077-4b8c-b73a6a2d784c@oracle.com>
Message-ID: <OF1EA80740.CBE2F323-ON00258489.00327BAC-80258489.00329ADF@notes.na.collabserv.com>

Hi Joe,

That sounds reasonable. 

Would you, or another Oracle employee, mind sponsoring the change?

Best Regards

Adam Farley 
IBM Runtimes


Joe Darcy <joe.darcy at oracle.com> wrote on 03/10/2019 23:30:14:

> From: Joe Darcy <joe.darcy at oracle.com>
> To: Florian Weimer <fw at deneb.enyo.de>, Adam Farley8 
<adam.farley at uk.ibm.com>
> Cc: jdk-updates-dev at openjdk.java.net, Java Core Libs <core-libs-
> dev at openjdk.java.net>
> Date: 03/10/2019 23:32
> Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
> 
> It is customary to have the license of a file be updated from someone 
> affiliated with the copyright holder of the file.
> 
> -Joe
> 
> On 10/3/2019 1:42 PM, Florian Weimer wrote:
> > * Adam Farley8:
> >
> >> Four GPLv2 files in 8u seem to be missing the classpath exception 
from the
> >> copyright section.
> >>
> >> Requesting reviews and a sponsor.
> >>
> >> Bug: https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwICaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=wcAkx_ZeKWB613imZ6cEieXyslKznP3D1_RhlLl9uyc&e=
> >>
> >> Webrev: https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=kS-
> rJ0RYE_QlLRThKVPu5A3mooj1xWNheeAy1HLxTVs&e= 
> > All these files are not used at run time, so this could be deliberate.
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From andy.herrick at oracle.com  Fri Oct  4 11:28:11 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 4 Oct 2019 07:28:11 -0400
Subject: RFR: JDK-8215895: Verify and create tests for Mac installer
 specific signing options
In-Reply-To: <e61a1e11-7623-d37e-bc63-bfcf7a991bb9@oracle.com>
References: <59b2f5e5-fa43-c52c-dac8-7f0c13ac9f92@oracle.com>
 <e61a1e11-7623-d37e-bc63-bfcf7a991bb9@oracle.com>
Message-ID: <b4a0b997-dc3c-a2f6-5bf5-5e2ef2681a84@oracle.com>

looks good.

/Andy

On 10/3/2019 6:10 PM, Alexander Matveev wrote:
> http://cr.openjdk.java.net/~almatvee/8215895/webrev.01/
>
> Changes since webrev.00 as per Alexey suggestions:
> - Reverted "@library /test/lib" jtreg directive when it is not needed.
> - jtreg.SkippedException exceptions will be used through reflection.
> - Other minor tweaks.
>
> Thanks,
> Alexander
>
> On 10/2/2019 2:34 PM, Alexander Matveev wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> - Added two signing tests for macOS. One test checks signing app 
>> image and second checks pkg and dmg.
>> - These test will not be run if machine is not configured with 
>> required signing certificates and will throw jtreg.SkippedException.
>> - Increase timeouts for two tests which where failing due to timeout 
>> intermittently.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8215895
>>
>> [2] http://cr.openjdk.java.net/~almatvee/8215895/webrev.00/
>>
>> Thanks,
>> Alexander
>

From andy.herrick at oracle.com  Fri Oct  4 11:33:19 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 4 Oct 2019 07:33:19 -0400
Subject: RFR: JDK-8231850: BasicTest test fails in jcov build
In-Reply-To: <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
References: <ae33201c-338a-0e70-7f67-8717b9b9c758@oracle.com>
 <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
Message-ID: <a16024cd-424b-ad05-93eb-4008b2e28ad4@oracle.com>

looks find.

/Andy

On 10/3/2019 8:17 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231850
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8231850/webrev.00/
>

From andrew_m_leonard at uk.ibm.com  Fri Oct  4 13:05:50 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Fri, 4 Oct 2019 14:05:50 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
Message-ID: <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>

Hi Roger,
So based on your suggestion i've removed the logic from the constructor 
and it's now pre-determined by the charset generator tooling, just like 
isASCIICompatible is... It works really nicely, so there is now no impact 
on the constructor. I have verified this using the StrCodingBenchmark 
test. I have also integrated the new method into ArrayDecoder as you said, 
which makes it neater.

Please review the new webrev here: 
http://cr.openjdk.java.net/~aleonard/8231717/webrev.01/

Many thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Roger Riggs <Roger.Riggs at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
Cc:     core-libs-dev at openjdk.java.net
Date:   02/10/2019 19:27
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS



Hi Andrew,


On 10/2/19 12:54 PM, Andrew Leonard wrote:
Hi Roger, 
Thank you for the feedback. 
So your point about constructor performance is a good one, in my 
performance tests in which I have run both the StrCodingBenchmark.java 
test and also some simple standalone tests, I did not see any noticeable 
degradation for charsets that are not alwaysCompactable(), but I will look 
closer at that one. It has made me think though that I can do the 
isAlwaysCompactable determination at static init time, since the table is 
obviously static...I will investigate that optimization. 

The change is actually not just EBCDIC, as I point out in the bug it's any 
SingleByte charset that is determined as "alwaysCompactable", I specified 
EBCDIC in the bug title as it is actually just about only the EBCDIC 
charsets that fall into this category. I can rename the "title" maybe?

So I think the name should be closer to everything that can be 
decoded/mapped to Latin1 or 8-bit clean.


The "negatives" check for isASCIICompatible is done only on the input 
bytes when the given charset "isASCIICompatible" as you said. This change 
is not related to hasNegatives() so not sure I quite understand the point 
about moving it? hasNegatives() is relavent to the input byte[] being 
decoded as if it contains negatives it will need complete mapping even for 
an isASCIICompatible charset. 
ok
isAlwaysCompactable is about the charset in general, and can (and I think 
should) be computed at static init time, as it's simply determined by the 
fact that the static b2c[] table maps only to values 0->0xff. 

EBCDIC codepages are not ASCIICompatible as they don't map directly, so 
you cannot combine the two, they are independent scenario fastpaths.
rigth, there is a mapping needed.


If I add a default impl for decodeToLatin1() I could add the methods to 
ArrayDecoder, I will look at that. I think I did it that way as I didn't 
want to affect anyone that may have implemented ArrayDecoder separately...
I was also thinking of ISO_8859_1, that doesn't need a mapping, 
and trying to avoid a multiple separate decisions and data paths.
(while keeping the code simple)

Thanks, Roger



Thanks for the review, I will look at the static init of 
alwaysCompactable, and move the methods to ArrayDecoder, and do a closer 
check on constructor performance at the end of that. 
Cheers 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:        Roger Riggs <Roger.Riggs at oracle.com> 
To:        core-libs-dev at openjdk.java.net 
Date:        02/10/2019 14:52 
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS 
Sent by:        "core-libs-dev" <core-libs-dev-bounces at openjdk.java.net> 



Hi Andrew,

This would seem to have an impact on the performance of every Decoder 
constructor
because it determines dynamically the isAlwaysCompactable attribute.
Are there regressions in the non-EBCDIC cases?

Did your performance tests include the constructor overhead?

The isASCIICompatible case is handled by checking for negatives only 
when needed.

Unless the information is used more than once it looks like you've moved 
the computation
from StringCoding hasNegatives to the Decoder constructor.

Is there a change that would benefit both the isASCIICompatible case and 
EBCDIC?

Is there a reason you didn't add the isAlwaysCompactable method to the 
existing ArrayDecoder interface.
I don't think there there is a need for a new interface.

Thanks, Roger

On 10/2/19 4:10 AM, Andrew Leonard wrote:
> Hi,
> Please can I request a review of this performance enhancement for EBCDIC
> (and any SingleByte, always compactable) charsets? I've explained the
> theory in the bug (https://bugs.openjdk.java.net/browse/JDK-8231717 ), 
but
> essentially it optimizes any SingleByte charset that is always 
compactable
> due to all mappings being to <=0xff and avoids unnecessary char[] to
> internal Latin1 byte[] arraycopy as a result. This leads to up to a 100%
> performance gain for decoding these charsets.
> I have run the complete tier1 and also the complete sun/nio/cs testcases
> successfully.
>
> Webrev: http://cr.openjdk.java.net/~aleonard/8231717/webrev.00/ 
>
> Thoughts and comments welcome please?
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From daniel.fuchs at oracle.com  Fri Oct  4 13:38:14 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 4 Oct 2019 14:38:14 +0100
Subject: RFR (XS): 8231161: Wrong return type in code sample in Collector
 API documentation
In-Reply-To: <5881af65-da17-386c-b186-7088aa6b0320@oracle.com>
References: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>
 <f95aa4b8-4e5b-ec23-bd38-df4d6aaa2fca@oracle.com>
 <5881af65-da17-386c-b186-7088aa6b0320@oracle.com>
Message-ID: <b1352e4b-5b30-2269-a08c-3408ce45bfe6@oracle.com>

Hi Julia,

On 03/10/2019 19:05, Julia Boes wrote:
> Hi Stuart,
> 
> Thanks for the review. I made the changes you mentioned.
> 
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231161/webrev.01/

Changes look good to me as well. I can sponsor this for you next week
if Stuart doesn't have the bandwidth.

best regards,

-- daniel

From joe.darcy at oracle.com  Fri Oct  4 16:28:59 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 4 Oct 2019 09:28:59 -0700
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <OF1EA80740.CBE2F323-ON00258489.00327BAC-80258489.00329ADF@notes.na.collabserv.com>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 <87mueh5zn7.fsf@mid.deneb.enyo.de>
 <a651b203-0348-c077-4b8c-b73a6a2d784c@oracle.com>
 <OF1EA80740.CBE2F323-ON00258489.00327BAC-80258489.00329ADF@notes.na.collabserv.com>
Message-ID: <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com>

Hi Adam,

Someone familiar with the history and usage of these files needs to be 
involved with changing the license? and that doesn't include me.

Cheers,

-Joe

On 10/4/2019 2:12 AM, Adam Farley8 wrote:
> Hi Joe,
>
> That sounds reasonable.
>
> Would you, or another Oracle employee, mind sponsoring the change?
>
> Best Regards
>
> Adam Farley
> IBM Runtimes
>
>
> Joe Darcy <joe.darcy at oracle.com> wrote on 03/10/2019 23:30:14:
>
> > From: Joe Darcy <joe.darcy at oracle.com>
> > To: Florian Weimer <fw at deneb.enyo.de>, Adam Farley8 <adam.farley at uk.ibm.com>
> > Cc: jdk-updates-dev at openjdk.java.net, Java Core Libs <core-libs-
> > dev at openjdk.java.net>
> > Date: 03/10/2019 23:32
> > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
> > 
> > It is customary to have the license of a file be updated from someone
> > affiliated with the copyright holder of the file.
> >
> > -Joe
> >
> > On 10/3/2019 1:42 PM, Florian Weimer wrote:
> > > * Adam Farley8:
> > >
> > >> Four GPLv2 files in 8u seem to be missing the classpath exception 
> from the
> > >> copyright section.
> > >>
> > >> Requesting reviews and a sponsor.
> > >>
> > >> Bug: https://urldefense.proofpoint.com/v2/url?
> > 
> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwICaQ&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=P5m8KWUXJf-
> > 
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=wcAkx_ZeKWB613imZ6cEieXyslKznP3D1_RhlLl9uyc&e=
> > >>
> > >> Webrev: https://urldefense.proofpoint.com/v2/url?
> > 
> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=P5m8KWUXJf-
> > 
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=kS-
> > rJ0RYE_QlLRThKVPu5A3mooj1xWNheeAy1HLxTVs&e=
> > > All these files are not used at run time, so this could be deliberate.
> >
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From andy.herrick at oracle.com  Fri Oct  4 18:15:50 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 4 Oct 2019 14:15:50 -0400
Subject: RFR: JDK-8231882: --add-modules ALL-MODULE-PATH is not handled
 properly
Message-ID: <7eeb4dc5-b2be-05d3-9ced-9fd1dfc41c34@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

This change eliminates the ModuleManager class and uses ModuleFinder 
class to locate modules.

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

[2] http://cr.openjdk.java.net/~herrick/8231882/

/Andy


From alexey.semenyuk at oracle.com  Fri Oct  4 19:05:52 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 4 Oct 2019 15:05:52 -0400
Subject: RFR: JDK-8231882: --add-modules ALL-MODULE-PATH is not handled
 properly
In-Reply-To: <7eeb4dc5-b2be-05d3-9ced-9fd1dfc41c34@oracle.com>
References: <7eeb4dc5-b2be-05d3-9ced-9fd1dfc41c34@oracle.com>
Message-ID: <5a1dcbcf-7402-8260-e241-df24453a0026@oracle.com>

Please enable `ALL-MODULE-PATH` parameter of BasicTest.testAddModules() 
test. It should pass with this fix.

- Alexey

On 10/4/2019 2:15 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This change eliminates the ModuleManager class and uses ModuleFinder 
> class to locate modules.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231882
>
> [2] http://cr.openjdk.java.net/~herrick/8231882/
>
> /Andy
>


From andy.herrick at oracle.com  Fri Oct  4 19:11:40 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 4 Oct 2019 15:11:40 -0400
Subject: RFR: JDK-8231882: --add-modules ALL-MODULE-PATH is not handled
 properly
In-Reply-To: <5a1dcbcf-7402-8260-e241-df24453a0026@oracle.com>
References: <7eeb4dc5-b2be-05d3-9ced-9fd1dfc41c34@oracle.com>
 <5a1dcbcf-7402-8260-e241-df24453a0026@oracle.com>
Message-ID: <66fc488a-c6df-802b-1d6d-0b932c57cd89@oracle.com>

isn't what this change in BasicTest in this webrev does ?

It passes on all platforms with Mach 5 builds.

/Andy

On 10/4/2019 3:05 PM, Alexey Semenyuk wrote:
> Please enable `ALL-MODULE-PATH` parameter of 
> BasicTest.testAddModules() test. It should pass with this fix.
>
> - Alexey
>
> On 10/4/2019 2:15 PM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> This change eliminates the ModuleManager class and uses ModuleFinder 
>> class to locate modules.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231882
>>
>> [2] http://cr.openjdk.java.net/~herrick/8231882/
>>
>> /Andy
>>
>

From alexey.semenyuk at oracle.com  Fri Oct  4 19:14:55 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 4 Oct 2019 15:14:55 -0400
Subject: RFR: JDK-8231882: --add-modules ALL-MODULE-PATH is not handled
 properly
In-Reply-To: <66fc488a-c6df-802b-1d6d-0b932c57cd89@oracle.com>
References: <7eeb4dc5-b2be-05d3-9ced-9fd1dfc41c34@oracle.com>
 <5a1dcbcf-7402-8260-e241-df24453a0026@oracle.com>
 <66fc488a-c6df-802b-1d6d-0b932c57cd89@oracle.com>
Message-ID: <c29a8433-42d7-00b4-4d02-4292f527ade0@oracle.com>

Yes, it is. Sorry, my bad, I didn't notice it. Looks good then!

- Alexey

On 10/4/2019 3:11 PM, Andy Herrick wrote:
> isn't what this change in BasicTest in this webrev does ?
>
> It passes on all platforms with Mach 5 builds.
>
> /Andy
>
> On 10/4/2019 3:05 PM, Alexey Semenyuk wrote:
>> Please enable `ALL-MODULE-PATH` parameter of 
>> BasicTest.testAddModules() test. It should pass with this fix.
>>
>> - Alexey
>>
>> On 10/4/2019 2:15 PM, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> This change eliminates the ModuleManager class and uses ModuleFinder 
>>> class to locate modules.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231882
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8231882/
>>>
>>> /Andy
>>>
>>


From Roger.Riggs at oracle.com  Fri Oct  4 19:55:26 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 4 Oct 2019 15:55:26 -0400
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
Message-ID: <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>

Hi Andrew,

That does seem more straightforward.

The name ALWAYSCOMPACTABLE doesn't really match the rest of the
nomenclature used in the compact string code.

Can you change the name to LATIN1COMPATIBLE?
Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 coding 
for used
in StringCoding.

I hope another Reviewer will take a look also.

Thanks, Roger



On 10/4/19 9:05 AM, Andrew Leonard wrote:
> Hi Roger,
> So based on your suggestion i've removed the logic from the 
> constructor and it's now pre-determined by the charset generator 
> tooling, just like isASCIICompatible is... It works really nicely, so 
> there is now no impact on the constructor. I have verified this using 
> the StrCodingBenchmark test. I have also integrated the new method 
> into ArrayDecoder as you said, which makes it neater.
>
> Please review the new webrev here: 
> http://cr.openjdk.java.net/~aleonard/8231717/webrev.01/
>
> Many thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From: Roger Riggs <Roger.Riggs at oracle.com>
> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 02/10/2019 19:27
> Subject: Re: RFR: 8231717: Improve performance of EBCDIC charset 
> decoding for COMPACT_STRINGS
> ------------------------------------------------------------------------
>
>
>
> Hi Andrew,
>
>
> On 10/2/19 12:54 PM, Andrew Leonard wrote:
> Hi Roger,
> Thank you for the feedback.
> So your point about constructor performance is a good one, in my 
> performance tests in which I have run both the StrCodingBenchmark.java 
> test and also some simple standalone tests, I did not see any 
> noticeable degradation for charsets that are not alwaysCompactable(), 
> but I will look closer at that one. It has made me think though that I 
> can do the isAlwaysCompactable determination at static init time, 
> since the table is obviously static...I will investigate that 
> optimization.
>
> The change is actually not just EBCDIC, as I point out in the bug it's 
> any SingleByte charset that is determined as "alwaysCompactable", I 
> specified EBCDIC in the bug title as it is actually just about only 
> the EBCDIC charsets that fall into this category. I can rename the 
> "title" maybe?
>
> So I think the name should be closer to everything that can be 
> decoded/mapped to Latin1 or 8-bit clean.
>
>
> The "negatives" check for isASCIICompatible is done only on the input 
> bytes when the given charset "isASCIICompatible" as you said. This 
> change is not related to hasNegatives() so not sure I quite understand 
> the point about moving it? hasNegatives() is relavent to the input 
> byte[] being decoded as if it contains negatives it will need complete 
> mapping even for an isASCIICompatible charset.
> ok
> isAlwaysCompactable is about the charset in general, and can (and I 
> think should) be computed at static init time, as it's simply 
> determined by the fact that the static b2c[] table maps only to values 
> 0->0xff.
>
> EBCDIC codepages are not ASCIICompatible as they don't map directly, 
> so you cannot combine the two, they are independent scenario fastpaths.
> rigth, there is a mapping needed.
>
>
> If I add a default impl for decodeToLatin1() I could add the methods 
> to ArrayDecoder, I will look at that. I think I did it that way as I 
> didn't want to affect anyone that may have implemented ArrayDecoder 
> separately...
> I was also thinking of ISO_8859_1, that doesn't need a mapping,
> and trying to avoid a multiple separate decisions and data paths.
> (while keeping the code simple)
>
> Thanks, Roger
>
>
>
> Thanks for the review, I will look at the static init of 
> alwaysCompactable, and move the methods to ArrayDecoder, and do a 
> closer check on constructor performance at the end of that.
> Cheers
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: _andrew_m_leonard at uk.ibm.com_ 
> <mailto:andrew_m_leonard at uk.ibm.com>
>
>
>
>
> From: Roger Riggs _<Roger.Riggs at oracle.com>_ 
> <mailto:Roger.Riggs at oracle.com>
> To: _core-libs-dev at openjdk.java.net_ 
> <mailto:core-libs-dev at openjdk.java.net>
> Date: 02/10/2019 14:52
> Subject: Re: RFR: 8231717: Improve performance of EBCDIC charset 
> decoding for COMPACT_STRINGS
> Sent by: "core-libs-dev" _<core-libs-dev-bounces at openjdk.java.net>_ 
> <mailto:core-libs-dev-bounces at openjdk.java.net>
> ------------------------------------------------------------------------
>
>
>
> Hi Andrew,
>
> This would seem to have an impact on the performance of every Decoder
> constructor
> because it determines dynamically the isAlwaysCompactable attribute.
> Are there regressions in the non-EBCDIC cases?
>
> Did your performance tests include the constructor overhead?
>
> The isASCIICompatible case is handled by checking for negatives only
> when needed.
>
> Unless the information is used more than once it looks like you've moved
> the computation
> from StringCoding hasNegatives to the Decoder constructor.
>
> Is there a change that would benefit both the isASCIICompatible case and
> EBCDIC?
>
> Is there a reason you didn't add the isAlwaysCompactable method to the
> existing ArrayDecoder interface.
> I don't think there there is a need for a new interface.
>
> Thanks, Roger
>
> On 10/2/19 4:10 AM, Andrew Leonard wrote:
> > Hi,
> > Please can I request a review of this performance enhancement for EBCDIC
> > (and any SingleByte, always compactable) charsets? I've explained the
> > theory in the bug 
> (_https://bugs.openjdk.java.net/browse/JDK-8231717_), but
> > essentially it optimizes any SingleByte charset that is always 
> compactable
> > due to all mappings being to <=0xff and avoids unnecessary char[] to
> > internal Latin1 byte[] arraycopy as a result. This leads to up to a 100%
> > performance gain for decoding these charsets.
> > I have run the complete tier1 and also the complete sun/nio/cs testcases
> > successfully.
> >
> > Webrev: _http://cr.openjdk.java.net/~aleonard/8231717/webrev.00/_
> >
> > Thoughts and comments welcome please?
> > Thanks
> > Andrew
> >
> > Andrew Leonard
> > Java Runtimes Development
> > IBM Hursley
> > IBM United Kingdom Ltd
> > internet email: _andrew_m_leonard at uk.ibm.com_ 
> <mailto:andrew_m_leonard at uk.ibm.com>
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
> >
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From peter.levart at gmail.com  Fri Oct  4 21:14:16 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 4 Oct 2019 23:14:16 +0200
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
Message-ID: <5989b724-a933-5c9b-41a4-f6d69dac0252@gmail.com>

Hi Joe,

On 10/3/19 5:32 PM, Joe Darcy wrote:
> Hello,
>
> In response to the recent and on-going review of serializable types in 
> the base module and elsewhere, I thought it would be helpful if the 
> collections specs discussed how collections were serialiazable. In 
> particular, the proposed terminology is that a collection is 
> "conditionally serializable" if the collection type implements 
> java.io.Serializable and all the elements of the collections are 
> serializable.
>
> Candidate wording changes to java.util.Collection below. If this 
> notion is deemed useful, I can also go through and add "This 
> collection is conditionally serializable."notes to ArrayList, HashMap, 
> and other such collections.
>
> Thoughts?
>

I think this addition is usefull. There's just one typo...

> Thanks,
>
> -Joe
>
>
> --- a/src/java.base/share/classes/java/util/Collection.java Tue Oct 01 
> 20:07:30 2019 -0700
> +++ b/src/java.base/share/classes/java/util/Collection.java??? Wed Oct 
> 02 22:58:04 2019 -0700
> @@ -188,6 +188,17 @@
> ? * or if the only reference to the backing collection is through an
> ? * unmodifiable view, the view can be considered effectively immutable.
> ? *
> + * <h2><a id="condserial">Serializable Collections</a></h2>
> + *
> + * Many collection types implement {@link
> + * java.io.Serializable}. Typically such collections are
> + * <i>conditionally serializable</i>, if all the objects in the
> + * collection are serializable, the collection as a whole can be
> + * serialized. Otherwise, is one or more objects in a collection are
s/is/in/

> + * <em>not<em> serializable, the collection cannot be serialized and a
> + * {@link java.io.NotSerializableException} may be thrown on attempts
> + * to serialize such a collection.
> + *
> ? * <p>This interface is a member of the
> ? * <a 
> href="{@docRoot}/java.base/java/util/package-summary.html#CollectionsFramework">
> ? * Java Collections Framework</a>.
>

Regards, Peter


From peter.levart at gmail.com  Fri Oct  4 21:16:18 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 4 Oct 2019 23:16:18 +0200
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <5989b724-a933-5c9b-41a4-f6d69dac0252@gmail.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
 <5989b724-a933-5c9b-41a4-f6d69dac0252@gmail.com>
Message-ID: <4086c5b4-c41a-5773-4c87-fa45390b9838@gmail.com>

Oh god, a typo in a typo comment... I better go to sleep now ;-)

On 10/4/19 11:14 PM, Peter Levart wrote:
>> + * serialized. Otherwise, is one or more objects in a collection are
> s/is/in/ 

s/is/if/

Peter


From alexander.matveev at oracle.com  Fri Oct  4 21:20:29 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 4 Oct 2019 14:20:29 -0700
Subject: RFR: JDK-8231882: --add-modules ALL-MODULE-PATH is not handled
 properly
In-Reply-To: <c29a8433-42d7-00b4-4d02-4292f527ade0@oracle.com>
References: <7eeb4dc5-b2be-05d3-9ced-9fd1dfc41c34@oracle.com>
 <5a1dcbcf-7402-8260-e241-df24453a0026@oracle.com>
 <66fc488a-c6df-802b-1d6d-0b932c57cd89@oracle.com>
 <c29a8433-42d7-00b4-4d02-4292f527ade0@oracle.com>
Message-ID: <afcd1b4a-53da-b7ed-60c5-fdaa5f240872@oracle.com>

Looks good.

On 10/4/2019 12:14 PM, Alexey Semenyuk wrote:
> Yes, it is. Sorry, my bad, I didn't notice it. Looks good then!
>
> - Alexey
>
> On 10/4/2019 3:11 PM, Andy Herrick wrote:
>> isn't what this change in BasicTest in this webrev does ?
>>
>> It passes on all platforms with Mach 5 builds.
>>
>> /Andy
>>
>> On 10/4/2019 3:05 PM, Alexey Semenyuk wrote:
>>> Please enable `ALL-MODULE-PATH` parameter of 
>>> BasicTest.testAddModules() test. It should pass with this fix.
>>>
>>> - Alexey
>>>
>>> On 10/4/2019 2:15 PM, Andy Herrick wrote:
>>>> Please review the jpackage fix for bug [1] at [2].
>>>>
>>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>>> repository (jpackage).
>>>>
>>>> This change eliminates the ModuleManager class and uses 
>>>> ModuleFinder class to locate modules.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231882
>>>>
>>>> [2] http://cr.openjdk.java.net/~herrick/8231882/
>>>>
>>>> /Andy
>>>>
>>>
>


From stuart.marks at oracle.com  Fri Oct  4 22:50:58 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 4 Oct 2019 15:50:58 -0700
Subject: RFR (XS): 8231161: Wrong return type in code sample in Collector
 API documentation
In-Reply-To: <b1352e4b-5b30-2269-a08c-3408ce45bfe6@oracle.com>
References: <8c86029c-2464-21bd-644e-af01315b1d9e@oracle.com>
 <f95aa4b8-4e5b-ec23-bd38-df4d6aaa2fca@oracle.com>
 <5881af65-da17-386c-b186-7088aa6b0320@oracle.com>
 <b1352e4b-5b30-2269-a08c-3408ce45bfe6@oracle.com>
Message-ID: <add3f60c-219d-37b2-d982-fdfb3ba5943b@oracle.com>



On 10/4/19 6:38 AM, Daniel Fuchs wrote:
> Hi Julia,
> 
> On 03/10/2019 19:05, Julia Boes wrote:
>> Hi Stuart,
>>
>> Thanks for the review. I made the changes you mentioned.
>>
>> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231161/webrev.01/
> 
> Changes look good to me as well. I can sponsor this for you next week
> if Stuart doesn't have the bandwidth.

Against all odds, I've managed to push this one already. :-) But thanks for the 
backup.

s'marks


From stuart.marks at oracle.com  Fri Oct  4 22:53:44 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 4 Oct 2019 15:53:44 -0700
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <4086c5b4-c41a-5773-4c87-fa45390b9838@gmail.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
 <5989b724-a933-5c9b-41a4-f6d69dac0252@gmail.com>
 <4086c5b4-c41a-5773-4c87-fa45390b9838@gmail.com>
Message-ID: <4a240182-2c56-abdd-987b-c60462dc5aed@oracle.com>



On 10/4/19 2:16 PM, Peter Levart wrote:
> Oh god, a typo in a typo comment... I better go to sleep now ;-)

It looks like Muphry's Law is still in force.

s'marks


From naoto.sato at oracle.com  Fri Oct  4 22:54:57 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 4 Oct 2019 15:54:57 -0700
Subject: [14] RFR: DecimalFormat.setGroupingSize(int) allows setting negative
 grouping size
Message-ID: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed CSR and changeset are located at:

https://bugs.openjdk.java.net/browse/JDK-8231851
https://cr.openjdk.java.net/~naoto/8212749/webrev.00/

Naoto

From stuart.marks at oracle.com  Fri Oct  4 23:46:43 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 4 Oct 2019 16:46:43 -0700
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
Message-ID: <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>



On 10/3/19 8:32 AM, Joe Darcy wrote:
> In response to the recent and on-going review of serializable types in the base 
> module and elsewhere, I thought it would be helpful if the collections specs 
> discussed how collections were serialiazable. In particular, the proposed 
> terminology is that a collection is "conditionally serializable" if the 
> collection type implements java.io.Serializable and all the elements of the 
> collections are serializable.
> 
> Candidate wording changes to java.util.Collection below. If this notion is 
> deemed useful, I can also go through and add "This collection is conditionally 
> serializable."notes to ArrayList, HashMap, and other such collections.

Hi Joe,

Thanks for doing this. In general I agree that there should be some discussion 
about the serializability of collections. I think it's reasonable to put that 
here (in the Collection interface) which seems to represent the top-level 
documentation for the entire Collections framework, not just that interface. I 
don't think it's necessary to mention conditional serializability in every 
location. However, I think a broader discussion of serializability in the 
collections framework is warranted. Here's some alternative wording:


diff -r 4a98c87dfd89 -r 6aea42e7cb15 
src/java.base/share/classes/java/util/Collection.java
--- a/src/java.base/share/classes/java/util/Collection.java	Thu Oct 03 23:13:28 
2019 -0700
+++ b/src/java.base/share/classes/java/util/Collection.java	Fri Oct 04 16:45:19 
2019 -0700
@@ -188,6 +188,38 @@
   * or if the only reference to the backing collection is through an
   * unmodifiable view, the view can be considered effectively immutable.
   *
+ * <h2><a id="serializable">Serializability of Collections</a></h2>
+ *
+ * <p>Serializability of collections is optional. As such, none of the collections
+ * interfaces are declared to implement the {@link java.io.Serializable} interface.
+ * However, serializability is regarded as being generally useful, so most 
collection
+ * implementations are serializable.
+
+ * <p>The collection implementations that are public classes (such as {@code 
ArrayList}
+ * or {@code HashMap}) are declared to implement the {@code Serializable} 
interface if they
+ * are in fact serializable. Some collections implementations are not public 
classes,
+ * such as the <a href="unmodifiable">unmodifiable collections.</a> In such 
cases, the
+ * serializability of such collections is described in the specification of the 
method
+ * that creates them, or in some other suitable place. In cases where the 
serializability
+ * of a collection is not specified, there is no guarantee about the 
serializability of such
+ * collections. In particular, many <a href="view">view collections</a> are not 
serializable.
+ *
+ * <p>A collection implementation that implements the {@code Serializable} 
interface cannot
+ * be guaranteed to be serializable. The reason is that in general, collections
+ * contain elements of other types, and it is not possible to determine statically
+ * whether instances the element type are actually serializable. For example, 
consider
+ * a serializable {@code Collection<E>}, where {@code E} does not implement the
+ * {@code Serializable} interface. The collection may be serializable, if it 
contains only
+ * elements of some serializable subtype of {@code E}, or if it is empty. 
Collections are
+ * thus said to be <i>conditionally serializable,</i> as the serializability of 
the collection
+ * as a whole depends on whether the collection itself is serializable and on 
whether all
+ * contained elements are also serializable.
+ *
+ * <p>An additional case occurs with instances of {@link SortedSet} and {@link 
SortedMap}.
+ * These collections can be created with a {@link Comparator} that imposes an 
ordering on
+ * the set elements or map keys. Such a collection is serializable only if the 
provided
+ * {@code Comparator} is also serializable.
+ *
   * <p>This interface is a member of the
   * <a 
href="{@docRoot}/java.base/java/util/package-summary.html#CollectionsFramework">
   * Java Collections Framework</a>.



s'marks


From joe.darcy at oracle.com  Sat Oct  5 00:02:16 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 4 Oct 2019 17:02:16 -0700
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
 <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
Message-ID: <da6065a5-8b1d-9e4f-2f76-9a26bedb6462@oracle.com>

Hi Stuart,

I prefer your more extensive write-up and thus I review it to go back :-)

I've filed JDK-8231913: "Discuss serializability of collections" with 
you as the assignee.

Thanks,

-Joe

On 10/4/2019 4:46 PM, Stuart Marks wrote:
>
>
> On 10/3/19 8:32 AM, Joe Darcy wrote:
>> In response to the recent and on-going review of serializable types 
>> in the base module and elsewhere, I thought it would be helpful if 
>> the collections specs discussed how collections were serialiazable. 
>> In particular, the proposed terminology is that a collection is 
>> "conditionally serializable" if the collection type implements 
>> java.io.Serializable and all the elements of the collections are 
>> serializable.
>>
>> Candidate wording changes to java.util.Collection below. If this 
>> notion is deemed useful, I can also go through and add "This 
>> collection is conditionally serializable."notes to ArrayList, 
>> HashMap, and other such collections.
>
> Hi Joe,
>
> Thanks for doing this. In general I agree that there should be some 
> discussion about the serializability of collections. I think it's 
> reasonable to put that here (in the Collection interface) which seems 
> to represent the top-level documentation for the entire Collections 
> framework, not just that interface. I don't think it's necessary to 
> mention conditional serializability in every location. However, I 
> think a broader discussion of serializability in the collections 
> framework is warranted. Here's some alternative wording:
>
>
> diff -r 4a98c87dfd89 -r 6aea42e7cb15 
> src/java.base/share/classes/java/util/Collection.java
> --- a/src/java.base/share/classes/java/util/Collection.java??? Thu Oct 
> 03 23:13:28 2019 -0700
> +++ b/src/java.base/share/classes/java/util/Collection.java??? Fri Oct 
> 04 16:45:19 2019 -0700
> @@ -188,6 +188,38 @@
> ? * or if the only reference to the backing collection is through an
> ? * unmodifiable view, the view can be considered effectively immutable.
> ? *
> + * <h2><a id="serializable">Serializability of Collections</a></h2>
> + *
> + * <p>Serializability of collections is optional. As such, none of 
> the collections
> + * interfaces are declared to implement the {@link 
> java.io.Serializable} interface.
> + * However, serializability is regarded as being generally useful, so 
> most collection
> + * implementations are serializable.
> +
> + * <p>The collection implementations that are public classes (such as 
> {@code ArrayList}
> + * or {@code HashMap}) are declared to implement the {@code 
> Serializable} interface if they
> + * are in fact serializable. Some collections implementations are not 
> public classes,
> + * such as the <a href="unmodifiable">unmodifiable collections.</a> 
> In such cases, the
> + * serializability of such collections is described in the 
> specification of the method
> + * that creates them, or in some other suitable place. In cases where 
> the serializability
> + * of a collection is not specified, there is no guarantee about the 
> serializability of such
> + * collections. In particular, many <a href="view">view 
> collections</a> are not serializable.
> + *
> + * <p>A collection implementation that implements the {@code 
> Serializable} interface cannot
> + * be guaranteed to be serializable. The reason is that in general, 
> collections
> + * contain elements of other types, and it is not possible to 
> determine statically
> + * whether instances the element type are actually serializable. For 
> example, consider
> + * a serializable {@code Collection<E>}, where {@code E} does not 
> implement the
> + * {@code Serializable} interface. The collection may be 
> serializable, if it contains only
> + * elements of some serializable subtype of {@code E}, or if it is 
> empty. Collections are
> + * thus said to be <i>conditionally serializable,</i> as the 
> serializability of the collection
> + * as a whole depends on whether the collection itself is 
> serializable and on whether all
> + * contained elements are also serializable.
> + *
> + * <p>An additional case occurs with instances of {@link SortedSet} 
> and {@link SortedMap}.
> + * These collections can be created with a {@link Comparator} that 
> imposes an ordering on
> + * the set elements or map keys. Such a collection is serializable 
> only if the provided
> + * {@code Comparator} is also serializable.
> + *
> ? * <p>This interface is a member of the
> ? * <a 
> href="{@docRoot}/java.base/java/util/package-summary.html#CollectionsFramework">
> ? * Java Collections Framework</a>.
>
>
>
> s'marks
>

From joe.darcy at oracle.com  Sat Oct  5 03:04:11 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 4 Oct 2019 20:04:11 -0700
Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable
 non-transient instance fields in serializable classes
In-Reply-To: <ac630074-c805-a9f3-9cb6-f2cfa8816154@oracle.com>
References: <ac630074-c805-a9f3-9cb6-f2cfa8816154@oracle.com>
Message-ID: <a92456c2-1a13-b29f-5ee7-83610f07feb3@oracle.com>

Hello,

Please review the revised fix:

 ??? http://cr.openjdk.java.net/~darcy/8231202.1/

The revised fix omits changes in java.time thanks to the changes already 
made for JDK-8231314: "java.time serialization warning cleanup"; also, 
the collection types are updated to use the "conditionally serializable" 
terminology in anticipate of the fix for JDK-8231913: "Discuss 
serializability of collections".

Thanks,

-Joe

On 9/18/2019 2:38 PM, Joe Darcy wrote:
> Hello,
>
> As background, I'm working on a number of serialization-related 
> compile-time checks with the goal of enabling stricter javac lint 
> checking in the JDK build (and elsewhere).
>
> One check is tracked by
>
> ??? JDK-8160675: Issue lint warning for non-serializable non-transient 
> instance fields in serializable type
>
> As summarized in the bug description, it may be concerning if a 
> serializable class has non-transient instance fields whose types are 
> not Serializable. This can cause a serialization failure at runtime. 
> (Classes using the serialPersistentFields mechanism are excluded from 
> this check.)
>
> A common example is an exception type -- all Throwable's are 
> Serializable -- which has a non-serializable field. If the fields 
> cannot be marked as transient, one approach to handle this robustly is 
> to have a writeObject method which null outs the field in question 
> when serializing and make the other methods in the exception 
> null-tolerant.
>
> In other cases, the object pointed to by the non-serializable field 
> are conditionally serializable at runtime. This is the case for many 
> collection types. For example, a class may have a field of type 
> List<Foo> with the field set to an ArrayList<Foo> at runtime. While 
> the List interface does not extent Serializable, the ArrayList class 
> does implement Serializable and the class would serialize fine in 
> practice, assuming the Foo's were serialazable.
>
> As a precursor to the adding a compile-time check to the build, please 
> review adding @SuppressWarnings("serial") to document the 
> non-serializable fields in the core libraries:
>
> ??? JDK-8231202: Suppress warnings on non-serializable non-transient 
> instance fields in serializable classes
> ??? http://cr.openjdk.java.net/~darcy/8231202.0/
>
> Bugs for similar changes to client libs and security libs will be 
> filed and reviewed separately.
>
> A more complete fix would add readObject/writeObject null handling to 
> AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to 
> be an issue since the type was introduced back in JDK 5.0, I just 
> added the annotation, as done elsewhere.
>
> Thanks,
>
> -Joe
>

From peter.levart at gmail.com  Sat Oct  5 07:09:32 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 5 Oct 2019 09:09:32 +0200
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
 <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
Message-ID: <2ef6f7d8-b0b8-e14b-b296-7376af378b2f@gmail.com>

Hi Stuart,

I also prefer your wording. There's just a nit...

On 10/5/19 1:46 AM, Stuart Marks wrote:
>
>
> On 10/3/19 8:32 AM, Joe Darcy wrote:
>> In response to the recent and on-going review of serializable types 
>> in the base module and elsewhere, I thought it would be helpful if 
>> the collections specs discussed how collections were serialiazable. 
>> In particular, the proposed terminology is that a collection is 
>> "conditionally serializable" if the collection type implements 
>> java.io.Serializable and all the elements of the collections are 
>> serializable.
>>
>> Candidate wording changes to java.util.Collection below. If this 
>> notion is deemed useful, I can also go through and add "This 
>> collection is conditionally serializable."notes to ArrayList, 
>> HashMap, and other such collections.
>
> Hi Joe,
>
> Thanks for doing this. In general I agree that there should be some 
> discussion about the serializability of collections. I think it's 
> reasonable to put that here (in the Collection interface) which seems 
> to represent the top-level documentation for the entire Collections 
> framework, not just that interface. I don't think it's necessary to 
> mention conditional serializability in every location. However, I 
> think a broader discussion of serializability in the collections 
> framework is warranted. Here's some alternative wording:
>
>
> diff -r 4a98c87dfd89 -r 6aea42e7cb15 
> src/java.base/share/classes/java/util/Collection.java
> --- a/src/java.base/share/classes/java/util/Collection.java??? Thu Oct 
> 03 23:13:28 2019 -0700
> +++ b/src/java.base/share/classes/java/util/Collection.java??? Fri Oct 
> 04 16:45:19 2019 -0700
> @@ -188,6 +188,38 @@
> ? * or if the only reference to the backing collection is through an
> ? * unmodifiable view, the view can be considered effectively immutable.
> ? *
> + * <h2><a id="serializable">Serializability of Collections</a></h2>
> + *
> + * <p>Serializability of collections is optional. As such, none of 
> the collections
> + * interfaces are declared to implement the {@link 
> java.io.Serializable} interface.
> + * However, serializability is regarded as being generally useful, so 
> most collection
> + * implementations are serializable.
> +
> + * <p>The collection implementations that are public classes (such as 
> {@code ArrayList}
> + * or {@code HashMap}) are declared to implement the {@code 
> Serializable} interface if they
> + * are in fact serializable. Some collections implementations are not 
> public classes,
> + * such as the <a href="unmodifiable">unmodifiable collections.</a> 
> In such cases, the
> + * serializability of such collections is described in the 
> specification of the method
> + * that creates them, or in some other suitable place. In cases where 
> the serializability
> + * of a collection is not specified, there is no guarantee about the 
> serializability of such
> + * collections. In particular, many <a href="view">view 
> collections</a> are not serializable.
> + *
> + * <p>A collection implementation that implements the {@code 
> Serializable} interface cannot
> + * be guaranteed to be serializable. The reason is that in general, 
> collections
> + * contain elements of other types, and it is not possible to 
> determine statically
> + * whether instances the element type are actually serializable. For 
> example, consider

... whether instances *of* the element type(s) are actually ...
(there are two element types in the Map<K, V>)

> + * a serializable {@code Collection<E>}, where {@code E} does not 
> implement the
> + * {@code Serializable} interface. The collection may be 
> serializable, if it contains only
> + * elements of some serializable subtype of {@code E}, or if it is 
> empty. Collections are
> + * thus said to be <i>conditionally serializable,</i> as the 
> serializability of the collection
> + * as a whole depends on whether the collection itself is 
> serializable and on whether all
> + * contained elements are also serializable.
> + *
> + * <p>An additional case occurs with instances of {@link SortedSet} 
> and {@link SortedMap}.
> + * These collections can be created with a {@link Comparator} that 
> imposes an ordering on
> + * the set elements or map keys. Such a collection is serializable 
> only if the provided
> + * {@code Comparator} is also serializable.
> + *
> ? * <p>This interface is a member of the
> ? * <a 
> href="{@docRoot}/java.base/java/util/package-summary.html#CollectionsFramework">
> ? * Java Collections Framework</a>.
>
>
>
> s'marks
>

Regards, Peter


From akozlov at azul.com  Sun Oct  6 16:23:46 2019
From: akozlov at azul.com (Anton Kozlov)
Date: Sun, 6 Oct 2019 19:23:46 +0300
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
Message-ID: <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>

Hi Mandy,

On 02.10.2019 01:08, Anton Kozlov wrote:> 
> > On 30.09.2019 21:18, Mandy Chung wrote:
>> Skimming through the implementation, it seems to me that the Runtime::loadLibrary0 does not need to be synchronized. 
>> ClassLoader::loadLibrary0 should ensure that a native library of a given name is loaded and registered only once.  
> 
> Interesting. I get confused at first by a comment nearby [1]. At first sight, it assumes that Runtime.loadLibrary0 is synchronized. But it's guarded by a monitor of loadedLibraryNames.
> 
> May be this will be simpler approach.

I cannot find a situation when this will be wrong. All the path from Runtime.loadLibrary (and Runtime.load) to NativeLibrary.loadLibrary do not need to be synchronized. Except for ClassLoader.sys_paths and usr_paths static fields initialization, they should be synchronized.

I looked at older releases, OpenJDK 7, 8. Relevant code is pretty much the same: Runtime.{load,loadLibrary} are synced [1], ClassLoader.loadLibrary eventually grabs a lock [2] and do bookkeeping for loading a native library only once.

So, if the Runtime.loadLibrary synchronization is redundant for JDK14, then it's so for older jdks, from the very beginning of _Open_JDK. I'd wish someone commented why is it there. Is it redundant since then.

I've updated the webrev with this approach and changed the comment. Link is at the bottom.

[1]: https://hg.openjdk.java.net/jdk6/jdk6/jdk/file/jdk6-b00/src/share/classes/java/lang/Runtime.java#l779
[2]: https://hg.openjdk.java.net/jdk6/jdk6/jdk/file/jdk6-b00/src/share/classes/java/lang/ClassLoader.java#l1732

On 03.10.2019 01:59, Mandy Chung wrote:
> Just on the test, instead of storing Target and Target2 classfile bytes in the source, the test can use jdk.test.lib.compiler.CompilerUtils 

Thanks for pointing that out, I've changed the test too.

Updated webrev:
http://cr.openjdk.java.net/~akozlov/8231584/webrev.02/

Thanks,
Anton


From tornaiandrasede at gmail.com  Sun Oct  6 15:21:47 2019
From: tornaiandrasede at gmail.com (=?UTF-8?Q?Tornai_Andr=C3=A1s?=)
Date: Sun, 6 Oct 2019 17:21:47 +0200
Subject: Regression after jpackage+1-49 update
Message-ID: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>

Hello,


After I updated my project from jpackage+1-35 to the latest jpackage+1-49 I
noticed that Java now throws NoClassDefFoundError while this was not the
case before.


Repro case:

import java.lang.reflect.Field;
import java.util.Optional;

public class Main {

    private Optional<Service> service;

    public static void main(String[] args) throws Exception {
        System.out.println(Runtime.version());
        Class<?> class0 = Main.class.getClassLoader().loadClass("Main");
        Field field0 = class0.getDeclaredField("service");
        field0.getGenericType();
    }
}

public class Service {

    public Service(OptionalService optionalService) {
    }

    public Service() {
        this(new OptionalService() {
        });
    }
}

public class OptionalService {
}



*With 14-jpackage+1-35*
c:\Private\jdk14-jpackage-1-35-vs-49>javac Main.java
c:\Private\jdk14-jpackage-1-35-vs-49>del OptionalService.class
c:\Private\jdk14-jpackage-1-35-vs-49>java Main
14-jpackage+1-35



*With 14-jpackage+1-49*
c:\Private\jdk14-jpackage-1-35-vs-49>javac Main.java
c:\Private\jdk14-jpackage-1-35-vs-49>del OptionalService.class
c:\Private\jdk14-jpackage-1-35-vs-49>java Main
14-jpackage+1-49
Exception in thread "main" java.lang.NoClassDefFoundError: OptionalService
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:420)
        at
java.base/sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114)
        at
java.base/sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
        at
java.base/sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
        at
java.base/sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68)
        at
java.base/sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138)
        at
java.base/sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
        at
java.base/sun.reflect.generics.repository.FieldRepository.computeGenericType(FieldRepository.java:90)
        at
java.base/sun.reflect.generics.repository.FieldRepository.getGenericType(FieldRepository.java:82)
        at java.base/java.lang.reflect.Field.getGenericType(Field.java:266)
        at Main.main(Main.java:12)
Caused by: java.lang.ClassNotFoundException: OptionalService
        at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
        at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 12 more


Regards,
Andr?s

From david.holmes at oracle.com  Mon Oct  7 03:35:47 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Oct 2019 13:35:47 +1000
Subject: Regression after jpackage+1-49 update
In-Reply-To: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
Message-ID: <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>

Hi,

On 7/10/2019 1:21 am, Tornai Andr?s wrote:
> Hello,
> 
> 
> After I updated my project from jpackage+1-35 to the latest jpackage+1-49 I
> noticed that Java now throws NoClassDefFoundError while this was not the
> case before.

Nothing to do with jpackage but a fix to Class.forName to ensure classes 
are linked as per the specification of forName. You can temporarily 
workaround with -XX:+ClassForNameDeferLinking, but your code needs to be 
updated to deal with LinkageErrors from Class.forName.

Cheers,
David
-----

> 
> Repro case:
> 
> import java.lang.reflect.Field;
> import java.util.Optional;
> 
> public class Main {
> 
>      private Optional<Service> service;
> 
>      public static void main(String[] args) throws Exception {
>          System.out.println(Runtime.version());
>          Class<?> class0 = Main.class.getClassLoader().loadClass("Main");
>          Field field0 = class0.getDeclaredField("service");
>          field0.getGenericType();
>      }
> }
> 
> public class Service {
> 
>      public Service(OptionalService optionalService) {
>      }
> 
>      public Service() {
>          this(new OptionalService() {
>          });
>      }
> }
> 
> public class OptionalService {
> }
> 
> 
> 
> *With 14-jpackage+1-35*
> c:\Private\jdk14-jpackage-1-35-vs-49>javac Main.java
> c:\Private\jdk14-jpackage-1-35-vs-49>del OptionalService.class
> c:\Private\jdk14-jpackage-1-35-vs-49>java Main
> 14-jpackage+1-35
> 
> 
> 
> *With 14-jpackage+1-49*
> c:\Private\jdk14-jpackage-1-35-vs-49>javac Main.java
> c:\Private\jdk14-jpackage-1-35-vs-49>del OptionalService.class
> c:\Private\jdk14-jpackage-1-35-vs-49>java Main
> 14-jpackage+1-49
> Exception in thread "main" java.lang.NoClassDefFoundError: OptionalService
>          at java.base/java.lang.Class.forName0(Native Method)
>          at java.base/java.lang.Class.forName(Class.java:420)
>          at
> java.base/sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114)
>          at
> java.base/sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
>          at
> java.base/sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
>          at
> java.base/sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68)
>          at
> java.base/sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138)
>          at
> java.base/sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
>          at
> java.base/sun.reflect.generics.repository.FieldRepository.computeGenericType(FieldRepository.java:90)
>          at
> java.base/sun.reflect.generics.repository.FieldRepository.getGenericType(FieldRepository.java:82)
>          at java.base/java.lang.reflect.Field.getGenericType(Field.java:266)
>          at Main.main(Main.java:12)
> Caused by: java.lang.ClassNotFoundException: OptionalService
>          at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
>          at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>          at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>          ... 12 more
> 
> 
> Regards,
> Andr?s
> 

From Alan.Bateman at oracle.com  Mon Oct  7 06:43:50 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 7 Oct 2019 07:43:50 +0100
Subject: Regression after jpackage+1-49 update
In-Reply-To: <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
Message-ID: <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>

On 07/10/2019 04:35, David Holmes wrote:
>
> Nothing to do with jpackage but a fix to Class.forName to ensure 
> classes are linked as per the specification of forName. You can 
> temporarily workaround with -XX:+ClassForNameDeferLinking, but your 
> code needs to be updated to deal with LinkageErrors from Class.forName.
In this case, it is core reflection code that it looking at the type 
parameters in the type of a field. I suspect this code needs to 
translate NCDEF to TypeNotPresentException, other linkage errors maybe 
need to be handled here too.

-Alan.

From david.holmes at oracle.com  Mon Oct  7 07:00:41 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Oct 2019 17:00:41 +1000
Subject: Regression after jpackage+1-49 update
In-Reply-To: <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
 <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
Message-ID: <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>

On 7/10/2019 4:43 pm, Alan Bateman wrote:
> On 07/10/2019 04:35, David Holmes wrote:
>>
>> Nothing to do with jpackage but a fix to Class.forName to ensure 
>> classes are linked as per the specification of forName. You can 
>> temporarily workaround with -XX:+ClassForNameDeferLinking, but your 
>> code needs to be updated to deal with LinkageErrors from Class.forName.
> In this case, it is core reflection code that it looking at the type 
> parameters in the type of a field. I suspect this code needs to 
> translate NCDEF to TypeNotPresentException, other linkage errors maybe 
> need to be handled here too.

Oops! Yes indeed.

Thanks Alan.

David
-----

> -Alan.

From Alan.Bateman at oracle.com  Mon Oct  7 08:12:38 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 7 Oct 2019 09:12:38 +0100
Subject: Regression after jpackage+1-49 update
In-Reply-To: <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
 <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
 <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>
Message-ID: <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>

On 07/10/2019 08:00, David Holmes wrote:
> On 7/10/2019 4:43 pm, Alan Bateman wrote:
>> On 07/10/2019 04:35, David Holmes wrote:
>>>
>>> Nothing to do with jpackage but a fix to Class.forName to ensure 
>>> classes are linked as per the specification of forName. You can 
>>> temporarily workaround with -XX:+ClassForNameDeferLinking, but your 
>>> code needs to be updated to deal with LinkageErrors from Class.forName.
>> In this case, it is core reflection code that it looking at the type 
>> parameters in the type of a field. I suspect this code needs to 
>> translate NCDEF to TypeNotPresentException, other linkage errors 
>> maybe need to be handled here too.
>
> Oops! Yes indeed.
I've created JDK-8231924 [1] to track this. We will need to a wider 
audit of Class.forName usages in the JDK in case there are other issues 
like this.

-Alan

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

From chris.hegarty at oracle.com  Mon Oct  7 09:29:01 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 7 Oct 2019 10:29:01 +0100
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
 <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
Message-ID: <3cec412d-7e7e-ddd1-9372-cdd9d77b908f@oracle.com>

This is a nice addition. LGTM.

-Chris.

On 05/10/2019 00:46, Stuart Marks wrote:
> 
> 
> On 10/3/19 8:32 AM, Joe Darcy wrote:
>> In response to the recent and on-going review of serializable types in 
>> the base module and elsewhere, I thought it would be helpful if the 
>> collections specs discussed how collections were serialiazable. In 
>> particular, the proposed terminology is that a collection is 
>> "conditionally serializable" if the collection type implements 
>> java.io.Serializable and all the elements of the collections are 
>> serializable.
>>
>> Candidate wording changes to java.util.Collection below. If this 
>> notion is deemed useful, I can also go through and add "This 
>> collection is conditionally serializable."notes to ArrayList, HashMap, 
>> and other such collections.
> 
> Hi Joe,
> 
> Thanks for doing this. In general I agree that there should be some 
> discussion about the serializability of collections. I think it's 
> reasonable to put that here (in the Collection interface) which seems to 
> represent the top-level documentation for the entire Collections 
> framework, not just that interface. I don't think it's necessary to 
> mention conditional serializability in every location. However, I think 
> a broader discussion of serializability in the collections framework is 
> warranted. Here's some alternative wording:
> 
> 
> diff -r 4a98c87dfd89 -r 6aea42e7cb15 
> src/java.base/share/classes/java/util/Collection.java
> --- a/src/java.base/share/classes/java/util/Collection.java??? Thu Oct 
> 03 23:13:28 2019 -0700
> +++ b/src/java.base/share/classes/java/util/Collection.java??? Fri Oct 
> 04 16:45:19 2019 -0700
> @@ -188,6 +188,38 @@
>  ? * or if the only reference to the backing collection is through an
>  ? * unmodifiable view, the view can be considered effectively immutable.
>  ? *
> + * <h2><a id="serializable">Serializability of Collections</a></h2>
> + *
> + * <p>Serializability of collections is optional. As such, none of the 
> collections
> + * interfaces are declared to implement the {@link 
> java.io.Serializable} interface.
> + * However, serializability is regarded as being generally useful, so 
> most collection
> + * implementations are serializable.
> +
> + * <p>The collection implementations that are public classes (such as 
> {@code ArrayList}
> + * or {@code HashMap}) are declared to implement the {@code 
> Serializable} interface if they
> + * are in fact serializable. Some collections implementations are not 
> public classes,
> + * such as the <a href="unmodifiable">unmodifiable collections.</a> In 
> such cases, the
> + * serializability of such collections is described in the 
> specification of the method
> + * that creates them, or in some other suitable place. In cases where 
> the serializability
> + * of a collection is not specified, there is no guarantee about the 
> serializability of such
> + * collections. In particular, many <a href="view">view collections</a> 
> are not serializable.
> + *
> + * <p>A collection implementation that implements the {@code 
> Serializable} interface cannot
> + * be guaranteed to be serializable. The reason is that in general, 
> collections
> + * contain elements of other types, and it is not possible to determine 
> statically
> + * whether instances the element type are actually serializable. For 
> example, consider
> + * a serializable {@code Collection<E>}, where {@code E} does not 
> implement the
> + * {@code Serializable} interface. The collection may be serializable, 
> if it contains only
> + * elements of some serializable subtype of {@code E}, or if it is 
> empty. Collections are
> + * thus said to be <i>conditionally serializable,</i> as the 
> serializability of the collection
> + * as a whole depends on whether the collection itself is serializable 
> and on whether all
> + * contained elements are also serializable.
> + *
> + * <p>An additional case occurs with instances of {@link SortedSet} and 
> {@link SortedMap}.
> + * These collections can be created with a {@link Comparator} that 
> imposes an ordering on
> + * the set elements or map keys. Such a collection is serializable only 
> if the provided
> + * {@code Comparator} is also serializable.
> + *
>  ? * <p>This interface is a member of the
>  ? * <a 
> href="{@docRoot}/java.base/java/util/package-summary.html#CollectionsFramework"> 
> 
>  ? * Java Collections Framework</a>.
> 
> 
> 
> s'marks
> 

From jan.lahoda at oracle.com  Mon Oct  7 10:40:08 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 7 Oct 2019 12:40:08 +0200
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <d6ce5be2-2cc0-afdc-6e2f-54851c9239fb@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <d6ce5be2-2cc0-afdc-6e2f-54851c9239fb@oracle.com>
Message-ID: <78308536-1708-46b9-d657-9babbf55daec@oracle.com>

Hi Joe,

Thanks for the suggestion, but I don't think we can do it using Taglets 
- as far as I know, Taglets cannot add tabs to the method listing. We 
would either need to modify javadoc, or (maybe) have a special doclet 
for JDK documentation.

Jan

On 04. 10. 19 7:08, Joe Darcy wrote:
> Hi Jan,
> 
> For future work, consider having a "Preview Methods" tag alongside 
> static, instance, deprecated, etc.
> 
> Cheers,
> 
> -Joe
> 
> On 10/3/2019 2:57 AM, Jan Lahoda wrote:
>> Hi,
>>
>> This is a continuation of Joe's patch from here:
>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>
>>
>> APIs associated with preview features are split into two groups: 
>> essential and non-essential. These are marked with an JDK-internal 
>> annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
>> javac follows the PreviewFeature annotation, and produces either 
>> warnings or errors for the usages of such APIs. For the @preview tag, 
>> there is a taglet in the JDK build that adds the content of the tag 
>> into the documentation. The first part of the @preview's text goes 
>> into the summary, the second part goes into the detailed description.
>>
>> For build, a tricky problem is that the jdk.compiler module uses the 
>> PreviewFeature annotation as well, but that is not in the bootstrap 
>> JDK. So, for the intermediate langtools build, the PreviewFeature 
>> annotation is copied from java.base.
>>
>> Proposed webrev:
>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>
>> Javadoc with the change:
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>
>> See for example:
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>
>> CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>
>> Feedback is welcome!
>>
>> Thanks,
>> ??? Jan

From Alan.Bateman at oracle.com  Mon Oct  7 11:42:20 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 7 Oct 2019 12:42:20 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
Message-ID: <fd950395-b743-e9e7-d5fa-78d39fa49e45@oracle.com>

On 04/10/2019 20:55, Roger Riggs wrote:
> Hi Andrew,
>
> That does seem more straightforward.
>
> The name ALWAYSCOMPACTABLE doesn't really match the rest of the
> nomenclature used in the compact string code.
>
> Can you change the name to LATIN1COMPATIBLE?
> Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 
> coding for used
> in StringCoding.
>
> I hope another Reviewer will take a look also.
I skimmed through the webrev and I think the approach looks good (and 
much better than the original suggestion to scan byte array when 
creating the Decoder).

-Alan

From claes.redestad at oracle.com  Mon Oct  7 12:09:05 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 7 Oct 2019 14:09:05 +0200
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
Message-ID: <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>

On 2019-10-04 21:55, Roger Riggs wrote:
> Can you change the name to LATIN1COMPATIBLE?
> Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 coding 
> for used in StringCoding.

To me, compatible has a specific meaning that's not really the case
here. Perhaps isLatin1Decodable/LATIN1DECODABLE would roll better of the
tongue? This would also align nicely with the decodeToLatin1 method.

Patch looks good to me as-is, though.

Thanks!

/Claes

From adam.farley at uk.ibm.com  Mon Oct  7 12:51:18 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Mon, 7 Oct 2019 13:51:18 +0100
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 <87mueh5zn7.fsf@mid.deneb.enyo.de>
 <a651b203-0348-c077-4b8c-b73a6a2d784c@oracle.com>
 <OF1EA80740.CBE2F323-ON00258489.00327BAC-80258489.00329ADF@notes.na.collabserv.com>
 <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com>
Message-ID: <OFB2F55F33.817DCB26-ON0025848C.00394F0C-8025848C.00469D69@notes.na.collabserv.com>

Good idea Joe. :)

I've added Sergey, Lana, Magnus, and Alan, all of whom seem to have at 
least a passing connection to these files in terms of commits.

Sergey, Lana, Magnus, and Alan: Four of the files in jdk8u appear to have 
a GPLv2 header without the usual Classpath Exception.

-- 
jdk/make/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java 

-- jdk/make/src/native/add_gnu_debuglink/add_gnu_debuglink.c 
-- jdk/make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c 
-- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser 

Can we please ask for your opinions on whether the CE should be added for 
some/all of these files in 8u, and whether you'd be prepared to 
review/sponsor such a change?

The points raised thus far:

- The Oracle nature of the header means an Oracle employee should approve 
of any change.
- Not all of these files wind up in a build, so some may only need to be 
considered as source.

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

Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/ 

Best Regards

Adam Farley 
IBM Runtimes


Joe Darcy <joe.darcy at oracle.com> wrote on 04/10/2019 17:28:59:

> From: Joe Darcy <joe.darcy at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: Java Core Libs <core-libs-dev at openjdk.java.net>, Florian Weimer 
> <fw at deneb.enyo.de>, jdk-updates-dev at openjdk.java.net
> Date: 04/10/2019 17:29
> Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
> 
> Hi Adam,
> Someone familiar with the history and usage of these files needs to 
> be involved with changing the license  and that doesn't include me.
> Cheers,
> -Joe
> On 10/4/2019 2:12 AM, Adam Farley8 wrote:
> Hi Joe, 
> 
> That sounds reasonable. 
> 
> Would you, or another Oracle employee, mind sponsoring the change?
> 
> Best Regards
> 
> Adam Farley 
> IBM Runtimes
> 
> 
> Joe Darcy <joe.darcy at oracle.com> wrote on 03/10/2019 23:30:14:
> 
> > From: Joe Darcy <joe.darcy at oracle.com> 
> > To: Florian Weimer <fw at deneb.enyo.de>, Adam Farley8 
<adam.farley at uk.ibm.com>
> > Cc: jdk-updates-dev at openjdk.java.net, Java Core Libs <core-libs-
> > dev at openjdk.java.net> 
> > Date: 03/10/2019 23:32 
> > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception 

> > 
> > It is customary to have the license of a file be updated from someone 
> > affiliated with the copyright holder of the file.
> > 
> > -Joe
> > 
> > On 10/3/2019 1:42 PM, Florian Weimer wrote:
> > > * Adam Farley8:
> > >
> > >> Four GPLv2 files in 8u seem to be missing the classpath 
> exception from the
> > >> copyright section.
> > >>
> > >> Requesting reviews and a sponsor.
> > >>
> > >> Bug: https://urldefense.proofpoint.com/v2/url?
> > 
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwICaQ&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=P5m8KWUXJf-
> > 
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=wcAkx_ZeKWB613imZ6cEieXyslKznP3D1_RhlLl9uyc&e=
> > >>
> > >> Webrev: https://urldefense.proofpoint.com/v2/url?
> > 
> 
u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=P5m8KWUXJf-
> > 
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=kS-
> > rJ0RYE_QlLRThKVPu5A3mooj1xWNheeAy1HLxTVs&e= 
> > > All these files are not used at run time, so this could be 
deliberate.
> > 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From Alan.Bateman at oracle.com  Mon Oct  7 12:57:53 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 7 Oct 2019 13:57:53 +0100
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <OFB2F55F33.817DCB26-ON0025848C.00394F0C-8025848C.00469D69@notes.na.collabserv.com>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 <87mueh5zn7.fsf@mid.deneb.enyo.de>
 <a651b203-0348-c077-4b8c-b73a6a2d784c@oracle.com>
 <OF1EA80740.CBE2F323-ON00258489.00327BAC-80258489.00329ADF@notes.na.collabserv.com>
 <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com>
 <OFB2F55F33.817DCB26-ON0025848C.00394F0C-8025848C.00469D69@notes.na.collabserv.com>
Message-ID: <84c2563e-752c-bc35-7033-55bfd31e41f2@oracle.com>

On 07/10/2019 13:51, Adam Farley8 wrote:
> :
> -- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser
It might be simpler to just get rid of the JObjC bits. If you dig 
through the JDK 8 history then you should see that JObjC.jar was dropped 
from the boot class path (it should never have been there in the first 
place). The remaining left overs were removed in JDK 9.

-Alan

From Alan.Bateman at oracle.com  Mon Oct  7 13:28:13 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 7 Oct 2019 14:28:13 +0100
Subject: RFR: 8230043: Lazily load libverify
In-Reply-To: <a7a78067-e308-f3a7-703f-4200a10258db@oracle.com>
References: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
 <9f721650-dfa1-71f4-4165-286af665a823@oracle.com>
 <a7a78067-e308-f3a7-703f-4200a10258db@oracle.com>
Message-ID: <9c167671-909c-6c69-3340-a61609a621ec@oracle.com>

On 25/08/2019 20:35, Claes Redestad wrote:
>
> Both functions abort similarly if UTF-8 sequences can't be decoded.
> The fix- version just gets rid of logic to check for slashes, which is 
> redundant at all existing call sites except the Class.forName one.
>
> The fact we return JNI_FALSE when verifyFixClassname fails is a bit 
> odd: this means we'll go into verifyClassname, fail the same way, and 
> still
> throw a CNFE, just with a slightly different message.
What you have is okay, I was mostly interesting in seeing if we could 
rename verifyFixClassname to fixClassname that returns JNI_TRUE if it 
succeeds and JNI_FALSE if fails due to a slash. We can look at that 
another time, I don't want to delay this improvement.

-Alan

From claes.redestad at oracle.com  Mon Oct  7 14:02:03 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 7 Oct 2019 16:02:03 +0200
Subject: RFR: 8230043: Lazily load libverify
In-Reply-To: <9c167671-909c-6c69-3340-a61609a621ec@oracle.com>
References: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
 <9f721650-dfa1-71f4-4165-286af665a823@oracle.com>
 <a7a78067-e308-f3a7-703f-4200a10258db@oracle.com>
 <9c167671-909c-6c69-3340-a61609a621ec@oracle.com>
Message-ID: <1e83272c-a249-d6e8-40a7-1dac7be7e138@oracle.com>

On 2019-10-07 15:28, Alan Bateman wrote:
>>
> What you have is okay, I was mostly interesting in seeing if we could 
> rename verifyFixClassname to fixClassname that returns JNI_TRUE if it 
> succeeds and JNI_FALSE if fails due to a slash. We can look at that 
> another time, I don't want to delay this improvement.

Thanks, Alan.

For the future, I'd also like to think about whether we can consolidate
all this . -> / translation stuff into a shared utility rather than
having code in libjava and HotSpot doing the same thing.

/Claes

From andrew_m_leonard at uk.ibm.com  Mon Oct  7 14:29:52 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 7 Oct 2019 15:29:52 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
 <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
Message-ID: <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>

Thanks for the feedback, so we just need to decide on the variable name..
I am leaning towards isLatin1Decodable since it is closer to implying the 
charset is decodable to Latin1 via the decodeToLatin1() method, whereas 
isLatin1Compatible sort of implies it is "compatible" and decodable in 
certain circumstances like ASCIICompatible is, which is not the case here. 
So Roger, you ok with isLatin1Decodable/LATIN1DECODABLE ?

Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Claes Redestad <claes.redestad at oracle.com>
To:     Roger Riggs <Roger.Riggs at oracle.com>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com>
Cc:     core-libs-dev at openjdk.java.net
Date:   07/10/2019 13:07
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS



On 2019-10-04 21:55, Roger Riggs wrote:
> Can you change the name to LATIN1COMPATIBLE?
> Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 coding 

> for used in StringCoding.

To me, compatible has a specific meaning that's not really the case
here. Perhaps isLatin1Decodable/LATIN1DECODABLE would roll better of the
tongue? This would also align nicely with the decodeToLatin1 method.

Patch looks good to me as-is, though.

Thanks!

/Claes




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From Roger.Riggs at oracle.com  Mon Oct  7 15:41:02 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 7 Oct 2019 11:41:02 -0400
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
 <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
 <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>
Message-ID: <4009de21-61a9-7fd3-ef36-cc2a85cf71a2@oracle.com>

Hi Andrew,

I'm fine with isLatin1Decodable/LATIN1DECODABLE.

To avoid confusion with "Latin-1", aka ISO-8859-1 the character set,
in prose, there may be an opportunity to reinforce that it refers to the
compact LATIN1 String coding.? Perhaps in ArrayDecoder.

I don't need to see another webrev.

Thanks, Roger


On 10/7/19 10:29 AM, Andrew Leonard wrote:
> Thanks for the feedback, so we just need to decide on the variable name..
> I am leaning towards isLatin1Decodable since it is closer to implying 
> the charset is decodable to Latin1 via the decodeToLatin1() method, 
> whereas isLatin1Compatible sort of implies it is "compatible" and 
> decodable in certain circumstances like ASCIICompatible is, which is 
> not the case here. So Roger, you ok with 
> isLatin1Decodable/LATIN1DECODABLE ?
>
> Cheers
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From: Claes Redestad <claes.redestad at oracle.com>
> To: Roger Riggs <Roger.Riggs at oracle.com>, Andrew Leonard 
> <andrew_m_leonard at uk.ibm.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 07/10/2019 13:07
> Subject: Re: RFR: 8231717: Improve performance of EBCDIC charset 
> decoding for COMPACT_STRINGS
> ------------------------------------------------------------------------
>
>
>
> On 2019-10-04 21:55, Roger Riggs wrote:
> > Can you change the name to LATIN1COMPATIBLE?
> > Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 
> coding
> > for used in StringCoding.
>
> To me, compatible has a specific meaning that's not really the case
> here. Perhaps isLatin1Decodable/LATIN1DECODABLE would roll better of the
> tongue? This would also align nicely with the decodeToLatin1 method.
>
> Patch looks good to me as-is, though.
>
> Thanks!
>
> /Claes
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From andrew_m_leonard at uk.ibm.com  Mon Oct  7 15:52:16 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 7 Oct 2019 16:52:16 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <4009de21-61a9-7fd3-ef36-cc2a85cf71a2@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
 <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
 <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>
 <4009de21-61a9-7fd3-ef36-cc2a85cf71a2@oracle.com>
Message-ID: <OF27010847.17D92AA7-ON0025848C.005707C7-8025848C.00572EC8@notes.na.collabserv.com>

Thanks Roger,

Yes, agree some comment to be explicit about it being the LATIN1 String 
coding would be good.
Are you ok to sponsor please? since Claes and Alan have reviewed.

Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Roger Riggs <Roger.Riggs at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
Cc:     Claes Redestad <claes.redestad at oracle.com>, 
core-libs-dev at openjdk.java.net, Alan Bateman <Alan.Bateman at oracle.com>
Date:   07/10/2019 16:43
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS



Hi Andrew,

I'm fine with isLatin1Decodable/LATIN1DECODABLE.

To avoid confusion with "Latin-1", aka ISO-8859-1 the character set, 
in prose, there may be an opportunity to reinforce that it refers to the 
compact LATIN1 String coding.  Perhaps in ArrayDecoder.

I don't need to see another webrev. 

Thanks, Roger


On 10/7/19 10:29 AM, Andrew Leonard wrote:
Thanks for the feedback, so we just need to decide on the variable name.. 
I am leaning towards isLatin1Decodable since it is closer to implying the 
charset is decodable to Latin1 via the decodeToLatin1() method, whereas 
isLatin1Compatible sort of implies it is "compatible" and decodable in 
certain circumstances like ASCIICompatible is, which is not the case here. 
So Roger, you ok with isLatin1Decodable/LATIN1DECODABLE ? 

Cheers 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:        Claes Redestad <claes.redestad at oracle.com> 
To:        Roger Riggs <Roger.Riggs at oracle.com>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com> 
Cc:        core-libs-dev at openjdk.java.net 
Date:        07/10/2019 13:07 
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS 



On 2019-10-04 21:55, Roger Riggs wrote:
> Can you change the name to LATIN1COMPATIBLE?
> Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 coding 

> for used in StringCoding.

To me, compatible has a specific meaning that's not really the case
here. Perhaps isLatin1Decodable/LATIN1DECODABLE would roll better of the
tongue? This would also align nicely with the decodeToLatin1 method.

Patch looks good to me as-is, though.

Thanks!

/Claes




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From Roger.Riggs at oracle.com  Mon Oct  7 16:10:56 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 7 Oct 2019 12:10:56 -0400
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <OF27010847.17D92AA7-ON0025848C.005707C7-8025848C.00572EC8@notes.na.collabserv.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
 <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
 <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>
 <4009de21-61a9-7fd3-ef36-cc2a85cf71a2@oracle.com>
 <OF27010847.17D92AA7-ON0025848C.005707C7-8025848C.00572EC8@notes.na.collabserv.com>
Message-ID: <e7ba1cc7-1ec0-4f7b-28a3-985a0c477637@oracle.com>

ok, I'll sponsor, update the webrev and I'll pick up the changeset from 
there.

Roger

On 10/7/19 11:52 AM, Andrew Leonard wrote:
> Thanks Roger,
>
> Yes, agree some comment to be explicit about it being the LATIN1 
> String coding would be good.
> Are you ok to sponsor please? since Claes and Alan have reviewed.
>
> Cheers
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From: Roger Riggs <Roger.Riggs at oracle.com>
> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc: Claes Redestad <claes.redestad at oracle.com>, 
> core-libs-dev at openjdk.java.net, Alan Bateman <Alan.Bateman at oracle.com>
> Date: 07/10/2019 16:43
> Subject: Re: RFR: 8231717: Improve performance of EBCDIC charset 
> decoding for COMPACT_STRINGS
> ------------------------------------------------------------------------
>
>
>
> Hi Andrew,
>
> I'm fine with isLatin1Decodable/LATIN1DECODABLE.
>
> To avoid confusion with "Latin-1", aka ISO-8859-1 the character set,
> in prose, there may be an opportunity to reinforce that it refers to the
> compact LATIN1 String coding.? Perhaps in ArrayDecoder.
>
> I don't need to see another webrev.
>
> Thanks, Roger
>
>
> On 10/7/19 10:29 AM, Andrew Leonard wrote:
> Thanks for the feedback, so we just need to decide on the variable name..
> I am leaning towards isLatin1Decodable since it is closer to implying 
> the charset is decodable to Latin1 via the decodeToLatin1() method, 
> whereas isLatin1Compatible sort of implies it is "compatible" and 
> decodable in certain circumstances like ASCIICompatible is, which is 
> not the case here. So Roger, you ok with 
> isLatin1Decodable/LATIN1DECODABLE ?
>
> Cheers
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: _andrew_m_leonard at uk.ibm.com_ 
> <mailto:andrew_m_leonard at uk.ibm.com>
>
>
>
>
> From: Claes Redestad _<claes.redestad at oracle.com>_ 
> <mailto:claes.redestad at oracle.com>
> To: Roger Riggs _<Roger.Riggs at oracle.com>_ 
> <mailto:Roger.Riggs at oracle.com>, Andrew Leonard 
> _<andrew_m_leonard at uk.ibm.com>_ <mailto:andrew_m_leonard at uk.ibm.com>
> Cc: _core-libs-dev at openjdk.java.net_ 
> <mailto:core-libs-dev at openjdk.java.net>
> Date: 07/10/2019 13:07
> Subject: Re: RFR: 8231717: Improve performance of EBCDIC charset 
> decoding for COMPACT_STRINGS
> ------------------------------------------------------------------------
>
>
>
> On 2019-10-04 21:55, Roger Riggs wrote:
> > Can you change the name to LATIN1COMPATIBLE?
> > Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 
> coding
> > for used in StringCoding.
>
> To me, compatible has a specific meaning that's not really the case
> here. Perhaps isLatin1Decodable/LATIN1DECODABLE would roll better of the
> tongue? This would also align nicely with the decodeToLatin1 method.
>
> Patch looks good to me as-is, though.
>
> Thanks!
>
> /Claes
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From andrew_m_leonard at uk.ibm.com  Mon Oct  7 17:03:32 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 7 Oct 2019 18:03:32 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <e7ba1cc7-1ec0-4f7b-28a3-985a0c477637@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
 <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
 <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>
 <4009de21-61a9-7fd3-ef36-cc2a85cf71a2@oracle.com>
 <OF27010847.17D92AA7-ON0025848C.005707C7-8025848C.00572EC8@notes.na.collabserv.com>
 <e7ba1cc7-1ec0-4f7b-28a3-985a0c477637@oracle.com>
Message-ID: <OFC900885B.9B52D851-ON0025848C.005DAE0A-8025848C.005DB4E9@notes.na.collabserv.com>

Thanks Roger, much appreciated

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Roger Riggs <Roger.Riggs at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
Cc:     Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad 
<claes.redestad at oracle.com>, core-libs-dev at openjdk.java.net
Date:   07/10/2019 17:11
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS



ok, I'll sponsor, update the webrev and I'll pick up the changeset from 
there.

Roger

On 10/7/19 11:52 AM, Andrew Leonard wrote:
Thanks Roger, 

Yes, agree some comment to be explicit about it being the LATIN1 String 
coding would be good. 
Are you ok to sponsor please? since Claes and Alan have reviewed. 

Cheers 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:        Roger Riggs <Roger.Riggs at oracle.com> 
To:        Andrew Leonard <andrew_m_leonard at uk.ibm.com> 
Cc:        Claes Redestad <claes.redestad at oracle.com>, 
core-libs-dev at openjdk.java.net, Alan Bateman <Alan.Bateman at oracle.com> 
Date:        07/10/2019 16:43 
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS 



Hi Andrew,

I'm fine with isLatin1Decodable/LATIN1DECODABLE.

To avoid confusion with "Latin-1", aka ISO-8859-1 the character set, 
in prose, there may be an opportunity to reinforce that it refers to the 
compact LATIN1 String coding.  Perhaps in ArrayDecoder.

I don't need to see another webrev. 

Thanks, Roger


On 10/7/19 10:29 AM, Andrew Leonard wrote: 
Thanks for the feedback, so we just need to decide on the variable name.. 
I am leaning towards isLatin1Decodable since it is closer to implying the 
charset is decodable to Latin1 via the decodeToLatin1() method, whereas 
isLatin1Compatible sort of implies it is "compatible" and decodable in 
certain circumstances like ASCIICompatible is, which is not the case here. 
So Roger, you ok with isLatin1Decodable/LATIN1DECODABLE ? 

Cheers 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:        Claes Redestad <claes.redestad at oracle.com> 
To:        Roger Riggs <Roger.Riggs at oracle.com>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com> 
Cc:        core-libs-dev at openjdk.java.net 
Date:        07/10/2019 13:07 
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS 



On 2019-10-04 21:55, Roger Riggs wrote:
> Can you change the name to LATIN1COMPATIBLE?
> Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 coding 

> for used in StringCoding.

To me, compatible has a specific meaning that's not really the case
here. Perhaps isLatin1Decodable/LATIN1DECODABLE would roll better of the
tongue? This would also align nicely with the decodeToLatin1 method.

Patch looks good to me as-is, though.

Thanks!

/Claes




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From claes.redestad at oracle.com  Mon Oct  7 18:38:59 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 7 Oct 2019 20:38:59 +0200
Subject: RFR: 8231355: Remove unused utility methods in libjava
Message-ID: <e45158f2-30df-3748-1c74-b1c63164a681@oracle.com>

Hi,

please review this patch which removes unused methods and redundant
aliases from jni_util and friends in libjava.

There's one affected call site in the hotspot runtime code, otherwise
this is mainly a java.base-internal cleanup.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8231355
Webrev: http://cr.openjdk.java.net/~redestad/8231355/open.00/

Testing: tier1+2

Thanks!

/Claes

From alexander.matveev at oracle.com  Mon Oct  7 21:33:32 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 7 Oct 2019 14:33:32 -0700
Subject: RFR: JDK-8231856: pkg installer dialog contains background image
 which does not look correct
Message-ID: <129f6e23-ca80-deee-cefd-56b4ed866652@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Fixed by using correct icon for pkg.
- Added icon for dark theme and it will be called 
appName-background-darkAqua.png, for separate customization between 
light and dark theme.
- pkg xml will be written using XML APIs.
- See JBS for screenshots on how pkg will look like.
- MAC_CF_BUNDLE_IDENTIFIER will be used instead of IDENTIFIER, since 
MAC_CF_BUNDLE_IDENTIFIER is correct value to use after JDK-8231281.

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

[2] http://cr.openjdk.java.net/~almatvee/8231856/webrev.00/

Thanks,
Alexander

From alexey.semenyuk at oracle.com  Mon Oct  7 21:41:56 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 7 Oct 2019 17:41:56 -0400
Subject: RFR: JDK-8231856: pkg installer dialog contains background image
 which does not look correct
In-Reply-To: <129f6e23-ca80-deee-cefd-56b4ed866652@oracle.com>
References: <129f6e23-ca80-deee-cefd-56b4ed866652@oracle.com>
Message-ID: <64767d58-190d-744e-4368-34e276b62d8b@oracle.com>

Looks good.

- Alexey

On 10/7/2019 5:33 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Fixed by using correct icon for pkg.
> - Added icon for dark theme and it will be called 
> appName-background-darkAqua.png, for separate customization between 
> light and dark theme.
> - pkg xml will be written using XML APIs.
> - See JBS for screenshots on how pkg will look like.
> - MAC_CF_BUNDLE_IDENTIFIER will be used instead of IDENTIFIER, since 
> MAC_CF_BUNDLE_IDENTIFIER is correct value to use after JDK-8231281.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231856
>
> [2] http://cr.openjdk.java.net/~almatvee/8231856/webrev.00/
>
> Thanks,
> Alexander


From stuart.marks at oracle.com  Mon Oct  7 22:16:55 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 7 Oct 2019 15:16:55 -0700
Subject: JDK 14 RF(pre)R: add section on "conditionally serializable"
 collections
In-Reply-To: <2ef6f7d8-b0b8-e14b-b296-7376af378b2f@gmail.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
 <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
 <2ef6f7d8-b0b8-e14b-b296-7376af378b2f@gmail.com>
Message-ID: <ffba0cb7-507d-e702-6740-8b70cf45febd@oracle.com>



On 10/5/19 12:09 AM, Peter Levart wrote:
> Hi Stuart,
> 
> I also prefer your wording. There's just a nit...
> 
>> + * whether instances the element type are actually serializable. For example, 
>> consider
> 
> ... whether instances *of* the element type(s) are actually ...
> (there are two element types in the Map<K, V>)

Thanks for proofreading! I'll update the wording when I file the CSR for this, 
shortly.

s'marks


From david.holmes at oracle.com  Mon Oct  7 22:19:47 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Oct 2019 08:19:47 +1000
Subject: RFR: 8231355: Remove unused utility methods in libjava
In-Reply-To: <e45158f2-30df-3748-1c74-b1c63164a681@oracle.com>
References: <e45158f2-30df-3748-1c74-b1c63164a681@oracle.com>
Message-ID: <f7d2efb4-5475-35cc-f83e-c93b07d66e8d@oracle.com>

Hi Claes,

This all looks good to me!

Thanks,
David

On 8/10/2019 4:38 am, Claes Redestad wrote:
> Hi,
> 
> please review this patch which removes unused methods and redundant
> aliases from jni_util and friends in libjava.
> 
> There's one affected call site in the hotspot runtime code, otherwise
> this is mainly a java.base-internal cleanup.
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8231355
> Webrev: http://cr.openjdk.java.net/~redestad/8231355/open.00/
> 
> Testing: tier1+2
> 
> Thanks!
> 
> /Claes

From mandy.chung at oracle.com  Mon Oct  7 22:20:29 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 7 Oct 2019 15:20:29 -0700
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
 <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
Message-ID: <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>



On 10/6/19 9:23 AM, Anton Kozlov wrote:
> Hi Mandy,
>
> On 02.10.2019 01:08, Anton Kozlov wrote:>
>>> On 30.09.2019 21:18, Mandy Chung wrote:
>>> Skimming through the implementation, it seems to me that the Runtime::loadLibrary0 does not need to be synchronized.
>>> ClassLoader::loadLibrary0 should ensure that a native library of a given name is loaded and registered only once.
>> Interesting. I get confused at first by a comment nearby [1]. At first sight, it assumes that Runtime.loadLibrary0 is synchronized. But it's guarded by a monitor of loadedLibraryNames.
>>
>> May be this will be simpler approach.
> I cannot find a situation when this will be wrong. All the path from Runtime.loadLibrary (and Runtime.load) to NativeLibrary.loadLibrary do not need to be synchronized. Except for ClassLoader.sys_paths and usr_paths static fields initialization, they should be synchronized.

I think another way doing it is to initialize ClassLoader.sys_paths and 
usr_paths fields at System::initPhase1. These static fields can be 
initialized after the library path system properties are set and before 
calling VM.initLevel(1).?? ClassLoader::loadLibrary can assert if 
sys_path and usr_paths are non-null.

> I looked at older releases, OpenJDK 7, 8. Relevant code is pretty much the same: Runtime.{load,loadLibrary} are synced [1], ClassLoader.loadLibrary eventually grabs a lock [2] and do bookkeeping for loading a native library only once.
>
> So, if the Runtime.loadLibrary synchronization is redundant for JDK14, then it's so for older jdks, from the very beginning of _Open_JDK. I'd wish someone commented why is it there. Is it redundant since then.

The Runtime.{load,loadLibrary} methods synchronize on the Runtime 
instance since day 1.?? The ClassLoader and NativeLibrary implementation 
have been changed over time and it looks like this redundant 
synchronization is just unnoticed.
> I've updated the webrev with this approach and changed the comment. Link is at the bottom.
>
> :
>
> Updated webrev:
> http://cr.openjdk.java.net/~akozlov/8231584/webrev.02/
>

I prefer to name the test and directory with the API it verifies. For 
example rename the directory to loadLibrary and rename the test files to

LoadLibraryTest.java
src/Target.java
src/Target2.java

 ? 66???? static void exitFailed() {
 ? 67???????? System.exit(1);
 ? 68???? }
 ? 69

The test should simply throw an exception.

   70     static void exitPassed() {
   71         System.exit(95);
   72     }
  
  ?94                 // Finish the test
   95                 exitPassed();


Is there a better way to finish up the test?? someLibrary does not 
exist.? Can it handshake by setting a global state that Target::<clinit> 
can validate and expect UnsatisfiedLinkError to be thrown?

  103         public Class findClass(String name) throws ClassNotFoundException {

use generic Class<?>

The threads should also be daemon threads so that the VM will terminate 
if they are alive.

Mandy

From andy.herrick at oracle.com  Mon Oct  7 22:37:51 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 7 Oct 2019 18:37:51 -0400
Subject: RFR: JDK-8231856: pkg installer dialog contains background image
 which does not look correct
In-Reply-To: <129f6e23-ca80-deee-cefd-56b4ed866652@oracle.com>
References: <129f6e23-ca80-deee-cefd-56b4ed866652@oracle.com>
Message-ID: <9696765d-b52c-f0ef-b2f1-255c9afaf912@oracle.com>

OK - looks fine.

/Andy

On 10/7/2019 5:33 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Fixed by using correct icon for pkg.
> - Added icon for dark theme and it will be called 
> appName-background-darkAqua.png, for separate customization between 
> light and dark theme.
> - pkg xml will be written using XML APIs.
> - See JBS for screenshots on how pkg will look like.
> - MAC_CF_BUNDLE_IDENTIFIER will be used instead of IDENTIFIER, since 
> MAC_CF_BUNDLE_IDENTIFIER is correct value to use after JDK-8231281.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231856
>
> [2] http://cr.openjdk.java.net/~almatvee/8231856/webrev.00/
>
> Thanks,
> Alexander

From brent.christian at oracle.com  Mon Oct  7 22:51:11 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 7 Oct 2019 15:51:11 -0700
Subject: RFR: 8226297: Dual-pivot quicksort improvements
In-Reply-To: <392719f4-d67c-f900-0f2d-6c9f826a5392@oracle.com>
References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com>
 <CAKjRUT7dzzvsrZYBi3Hu624WV10WFp_Y1DZDKhjZuxkXoWD8eg@mail.gmail.com>
 <64e3ebb1-095e-08c0-ffc1-125346e2c960@oracle.com>
 <1565120849.689130733@f473.i.mail.ru>
 <e8b8b49f-dc82-38d6-3578-7cdf6ab6317b@oracle.com>
 <CAKjRUT51Ma+2ke9BZBcu4UX-Pmp4sk-tziX9HwjN1mjVAV1LoA@mail.gmail.com>
 <392719f4-d67c-f900-0f2d-6c9f826a5392@oracle.com>
Message-ID: <1a031e52-b824-65bc-1ec1-c6d80a231cd9@oracle.com>

Hi, Vladimir

I've read through the changes[1].  I have the following comments:

---
src/java.base/share/classes/java/util/Arrays.java

* Regarding the indentation changes in the equals() methods:

-     * <pre>    {@code new Double(d1).equals(new Double(d2))}</pre>
+     * <pre>{@code new Double(d1).equals(new Double(d2))}</pre>
...
-     * <pre>    {@code new Double(d1).equals(new Double(d2))}</pre>
+     * <pre>{@code new Double(d1).equals(new Double(d2))}</pre>
...
-     * <pre>    {@code new Float(f1).equals(new Float(f2))}</pre>
+     * <pre>{@code new Float(f1).equals(new Float(f2))}</pre>
...
-     * <pre>    {@code new Float(f1).equals(new Float(f2))}</pre>
+     * <pre>{@code new Float(f1).equals(new Float(f2))}</pre>

Looking at the generated JavaDoc, this indentation is intentional.  I've 
reverted these changes.

* Otherwise, the JavaDoc changes are limited to within @implNote 
(previously written out as "Implementation note", in some cases).  I 
don't believe a CSR is warranted.

---
test/jdk/java/util/Arrays/Sorting.java

Some general comments:

* I see a lot of renames[2] that I don't think add value, and clutter 
the changes (1000+ total changed lines in a 2000 line file).  I feel 
similarly about the changes from post- to pre- incrementing of the for() 
loop indices.  If it's OK with you, Vladimir, I can take care of 
reverting these changes.

* I like that the the various DualPivotQuickSort methods are tested 
directly (via SortingHelper).  I'd prefer that we also continue testing 
direct calls to Arrays.sort(), as that's what users will call.  What 
would be the best way to add that back in?  (Maybe a SortingHelper 
variant that calls Arrays.sort()?).

* Having the test operation depend on setting various values to the 
static 'sortingHelper' field seems brittle to me.  This could be a good 
opportunity to convert from static to instance methods, make 
'sortingHelper' and 'name' member variables, and create separate Sorting 
objects for each SortingHelper. Such a refactoring is not strictly 
necessary, but I think it would be nice to have.

---
test/jdk/java/util/Arrays/FailedFloat.java

Is this test necessary, given the addition of testFloatNegativeZero() in 
Sorting.java ?

Thanks,
-Brent

1. 
http://cr.openjdk.java.net/~bchristi/8226297/webrev05-adaptive/webrev/index.html

2. Name changes in Sorting.java:
     testAndCheck -> testQuicksort
     seed -> random
     ourDescription -> name
     failedSort -> failSort
     failed -> fail
     myKey -> key
     myValue -> value
     Merge->Merging [Sort|Builder]
     MyRandom->TestRandom
     failedCompare->failCompare
     change TypeConverter, FloatBuilder, DoubleBuilder, SortedBuilder to 
be non-static


From john.r.rose at oracle.com  Mon Oct  7 23:01:51 2019
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 7 Oct 2019 16:01:51 -0700
Subject: RFR: 8231355: Remove unused utility methods in libjava
In-Reply-To: <e45158f2-30df-3748-1c74-b1c63164a681@oracle.com>
References: <e45158f2-30df-3748-1c74-b1c63164a681@oracle.com>
Message-ID: <D54B061E-6606-4B7A-8B06-751B378C801B@oracle.com>

On Oct 7, 2019, at 11:38 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8231355 <https://bugs.openjdk.java.net/browse/JDK-8231355>
> Webrev: http://cr.openjdk.java.net/~redestad/8231355/open.00/ <http://cr.openjdk.java.net/~redestad/8231355/open.00/>
> 
> Testing: tier1+2

"436 lines changed: 2 ins; 433 del; 1 mod?
Nice!


From stuart.marks at oracle.com  Mon Oct  7 23:24:14 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 7 Oct 2019 16:24:14 -0700
Subject: JDK 14 RFR JDK-8231913: add section on "conditionally
 serializable" collections
In-Reply-To: <ffba0cb7-507d-e702-6740-8b70cf45febd@oracle.com>
References: <867a95db-8807-ecb1-e70c-fbdcf5d4727f@oracle.com>
 <c150f004-b8e6-d69f-e6f9-e63b92956244@oracle.com>
 <2ef6f7d8-b0b8-e14b-b296-7376af378b2f@gmail.com>
 <ffba0cb7-507d-e702-6740-8b70cf45febd@oracle.com>
Message-ID: <49eb2df0-46a9-bfc0-1e4e-16549b8b9bac@oracle.com>

Hi,

Per discussion earlier in this thread, Joe had filed

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

as an RFE to add this text to the Collection interface spec. Please review the 
corresponding CSR, which contains the updated, proposed specification text:

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

(To indicate review/approval of a CSR, please edit the CSR issue and add your 
OpenJDK name to the "Reviewed By" box.)

Thanks,

s'marks


From Alan.Bateman at oracle.com  Tue Oct  8 07:02:10 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 8 Oct 2019 08:02:10 +0100
Subject: RFR: 8231355: Remove unused utility methods in libjava
In-Reply-To: <e45158f2-30df-3748-1c74-b1c63164a681@oracle.com>
References: <e45158f2-30df-3748-1c74-b1c63164a681@oracle.com>
Message-ID: <4e0cd8be-8f20-8d76-fd0a-7057893a62d2@oracle.com>

On 07/10/2019 19:38, Claes Redestad wrote:
> Hi,
>
> please review this patch which removes unused methods and redundant
> aliases from jni_util and friends in libjava.
>
> There's one affected call site in the hotspot runtime code, otherwise
> this is mainly a java.base-internal cleanup.
>
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8231355
> Webrev: http://cr.openjdk.java.net/~redestad/8231355/open.00/
Looks good. It's possible that some of these will come back, if needed, 
but that is easy to do.

-Alan.

From OGATAK at jp.ibm.com  Tue Oct  8 10:23:01 2019
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Tue, 8 Oct 2019 19:23:01 +0900
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
Message-ID: <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>

Hi all,

I posted two changes and got reply that performance evaluation is needed. 
I found that making Method.methodAccessor non-volatile (webrev.02) is 
better than avoid copying methodAccessor value when it is null 
(webrev.01), as shown below.

So I'd like to ask review of the former change.  I updated weberv using 
the latest code base (though there was no difference from webrev.02):

Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.03/

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


For this performance evaluation, I calculated 75 percentile of 9 runs of 
SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers.  I 
bound a JVM to a NUMA node and set the number of GC threads to the same as 
the number of physical cores.  These tuning reduced run-to-run fluctuation 
on POWER (as usual...).

SPECjbb2015:
  webrev.02:  critical jOPS +1.6%, max jOPS +0.2%
  webrev.01:  critical jOPS +0.4%, max jOPS +0.2%


For DaCapo, some benchmark still improved performance and some degraded, 
but the geometric mean of all benchmarks were small:
  weberv.02: +0.3%
  weberv.01: +0.2%

The difference of improvement/degradation between the two changes in each 
benchmark were less than 0.8%.

The range of improvement/degradation in each benchmark were:
  webrev.02: between +2.4% and -1.0%
  webrev.01: between +1.6% and -1.8%


So I think webrev.02 (i.e., making methodAccessor non-volatile) is a good 
change, since it improved SPECjbb critical jOPS by 1.6%.


Regards,
Ogata


Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39:

> From: Kazunori Ogata/Japan/IBM
> To: Mandy Chung <mandy.chung at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 2019/08/27 15:41
> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() and 
leafCopy()
> 
> Hi Mandy,
> 
> Let me post interim results of the performance evaluation, though I'm 
> still measuring benchmarks and analyzing them.
> 
> For SPECjbb2015, skipping storing null (webrev.01) was faster than 
making 
> methodAccessor non-volatile (webrev.02).  The improvements of each of 
the 
> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%, 
> respectively.  This is only an average of six runs.
> 
> For DaCapo, the results were mixed.  In some benchmark, both of the 
> changes degraded performance.  In some others, webrev.01 was better, but 

> weberv.02 was better in some others.
> 
> I'll continue evaluation, but it is helpful if you could give me some 
> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015.
> 
> Regards,
> Ogata
> 
> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41:
> 
> > From: Kazunori Ogata/Japan/IBM
> > To: Mandy Chung <mandy.chung at oracle.com>
> > Cc: core-libs-dev at openjdk.java.net
> > Date: 2019/08/21 20:02
> > Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() 
and leafCopy()
> > 
> > Hi Mandy,
> > 
> > Thank you for reviewing the webrev.  I updated it to add a space after 

> > "if" and also put four spaces for indentation (it was three).
> > 
> > http://cr.openjdk.java.net/~ogatak/8229871/webrev.01/
> > 
> > Thank you so much for checking the history of fieldAccessor.  I was 
> > surprised that fieldAccessor was made non-volatile in JDK5, but 
> > methodAccessor was left as volatile for 15 years after that...
> > 
> > I agree we need benchmark data.  My simple micro benchmark that 
repeats 
> > invoking Class.getMethods() improved performance by 70% when it made 
non-
> > volatile (as shown in the following webrev).  I'll try to run larger 
> > benchmarks, such as SPECjbb2015, to see real impact.
> > 
> > http://cr.openjdk.java.net/~ogatak/8229871/webrev.02/
> > 
> > Regards,
> > Ogata
> > 
> > Mandy Chung <mandy.chung at oracle.com> wrote on 2019/08/21 01:21:42:
> > 
> > > From: Mandy Chung <mandy.chung at oracle.com>
> > > To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > > Cc: core-libs-dev at openjdk.java.net
> > > Date: 2019/08/21 01:21
> > > Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of 
> > > Method.copy() and leafCopy()
> > > 
> > > Hi Ogata,
> > > 
> > > The patch looks okay.  Nit: please add a space between if and (.
> > > 
> > > About volatile methodAccessor field, I checked the history.  Both 
> > > fieldAccessor and methodAccessor were started as volatile and the 
> > > fieldAccessor declaration was updated due to JDK-5044412.   As you 
> > > observe, I think the methodAccessor field could be made 
non-volatile.  
> > > OTOH that might impact when it's inflated to spin bytecode for this 
> > > method invocation.  I don't know how importance to keep its volatile 
vs 
> > > non-volatile in practice without doing benchmarking/real application 

> > > testing.
> > > 
> > > Mandy
> > > 
> > > On 8/19/19 2:51 AM, Kazunori Ogata wrote:
> > > > Hi,
> > > >
> > > > May I have review for "JDK-8229871: Imporve performance of 
Method.copy()
> > > > and leafCopy()"?
> > > >
> > > > Method.copy() and leafCopy() creates a copy of a Method object 
with
> > > > sharing MethodAccessor object. Since the methodAccessor field is a
> > > > volatile variable, copying this field needs memory fence to ensure 
the
> > > > field is visible to all threads on the weak memory platforms such 
as POWER
> > > > and ARM.
> > > >
> > > > When the methodAccessor of the root object is null (i.e., not 
initialized
> > > > yet), we do not need to copy the null value because this field of 
the
> > > > copied object has been initialized to null in the constructor. We 
can
> > > > reduce overhead of the memory fence only when the root's 
methodAccessor is
> > > > non-null. This change improved performance by 5.8% using a micro 
benchmark
> > > > that repeatedly invokes Class.getMethods().
> > > >
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
> > > >
> > > > Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.00/
> > > >
> > > >
> > > > By the way, why Method.methodAccessor is volatile, while
> > > > Field.fieldAccessor and Field.overrideFieldAccessor are not 
volatile?  I
> > > > know the use of volatile reduces probability of creating 
duplicated method
> > > > accessor, but the chance still exists.  I couldn't find the 
difference
> > > > between Method and Field classes to make Method.methodAccessor 
volatile.
> > > > If we can make it non-volatile, it is more preferable than a quick 
hack
> > > > above.
> > > >
> > > >
> > > > Regards,
> > > > Ogata
> > > >
> > > 
> > > 



From claes.redestad at oracle.com  Tue Oct  8 13:31:29 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 8 Oct 2019 15:31:29 +0200
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
Message-ID: <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>

Hi,

webrev.02 looks good to me.

I think the performance results makes sense since avoiding a volatile
store (and the potentially expensive store barriers this involves)
should be the main benefit. Adding a branch to avoid storing null would
help partially, but not hot Methods.

Pre-existing issue, but it's somewhat weird that we have two assignments
outside the package-private constructor: adding root and methodAccessor
to the constructor would make more immediate sense to me, since we do
the same thing at the only two callsites:

         Method res = new Method(clazz, name, parameterTypes, returnType,
                 exceptionTypes, modifiers, slot, signature,
                 annotations, parameterAnnotations, annotationDefault);
         res.root = root;
         res.methodAccessor = methodAccessor;

->

         Method res = new Method(clazz, name, parameterTypes, returnType,
                 exceptionTypes, modifiers, slot, signature,
                 annotations, parameterAnnotations, annotationDefault,
                 root, methodAccessor);

This package-private constructor could also be made private. My guess is
there was some time when this was used from outside Method and changing
it was deemed unsavory..

Thanks!

/Claes

On 2019-10-08 12:23, Kazunori Ogata wrote:
> Hi all,
> 
> I posted two changes and got reply that performance evaluation is needed.
> I found that making Method.methodAccessor non-volatile (webrev.02) is
> better than avoid copying methodAccessor value when it is null
> (webrev.01), as shown below.
> 
> So I'd like to ask review of the former change.  I updated weberv using
> the latest code base (though there was no difference from webrev.02):
> 
> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.03/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
> 
> 
> For this performance evaluation, I calculated 75 percentile of 9 runs of
> SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers.  I
> bound a JVM to a NUMA node and set the number of GC threads to the same as
> the number of physical cores.  These tuning reduced run-to-run fluctuation
> on POWER (as usual...).
> 
> SPECjbb2015:
>    webrev.02:  critical jOPS +1.6%, max jOPS +0.2%
>    webrev.01:  critical jOPS +0.4%, max jOPS +0.2%
> 
> 
> For DaCapo, some benchmark still improved performance and some degraded,
> but the geometric mean of all benchmarks were small:
>    weberv.02: +0.3%
>    weberv.01: +0.2%
> 
> The difference of improvement/degradation between the two changes in each
> benchmark were less than 0.8%.
> 
> The range of improvement/degradation in each benchmark were:
>    webrev.02: between +2.4% and -1.0%
>    webrev.01: between +1.6% and -1.8%
> 
> 
> So I think webrev.02 (i.e., making methodAccessor non-volatile) is a good
> change, since it improved SPECjbb critical jOPS by 1.6%.
> 
> 
> Regards,
> Ogata
> 
> 
> Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39:
> 
>> From: Kazunori Ogata/Japan/IBM
>> To: Mandy Chung <mandy.chung at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Date: 2019/08/27 15:41
>> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() and
> leafCopy()
>>
>> Hi Mandy,
>>
>> Let me post interim results of the performance evaluation, though I'm
>> still measuring benchmarks and analyzing them.
>>
>> For SPECjbb2015, skipping storing null (webrev.01) was faster than
> making
>> methodAccessor non-volatile (webrev.02).  The improvements of each of
> the
>> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%,
>> respectively.  This is only an average of six runs.
>>
>> For DaCapo, the results were mixed.  In some benchmark, both of the
>> changes degraded performance.  In some others, webrev.01 was better, but
> 
>> weberv.02 was better in some others.
>>
>> I'll continue evaluation, but it is helpful if you could give me some
>> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015.
>>
>> Regards,
>> Ogata
>>
>> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41:
>>
>>> From: Kazunori Ogata/Japan/IBM
>>> To: Mandy Chung <mandy.chung at oracle.com>
>>> Cc: core-libs-dev at openjdk.java.net
>>> Date: 2019/08/21 20:02
>>> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy()
> and leafCopy()
>>>
>>> Hi Mandy,
>>>
>>> Thank you for reviewing the webrev.  I updated it to add a space after
> 
>>> "if" and also put four spaces for indentation (it was three).
>>>
>>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.01/
>>>
>>> Thank you so much for checking the history of fieldAccessor.  I was
>>> surprised that fieldAccessor was made non-volatile in JDK5, but
>>> methodAccessor was left as volatile for 15 years after that...
>>>
>>> I agree we need benchmark data.  My simple micro benchmark that
> repeats
>>> invoking Class.getMethods() improved performance by 70% when it made
> non-
>>> volatile (as shown in the following webrev).  I'll try to run larger
>>> benchmarks, such as SPECjbb2015, to see real impact.
>>>
>>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.02/
>>>
>>> Regards,
>>> Ogata
>>>
>>> Mandy Chung <mandy.chung at oracle.com> wrote on 2019/08/21 01:21:42:
>>>
>>>> From: Mandy Chung <mandy.chung at oracle.com>
>>>> To: Kazunori Ogata <OGATAK at jp.ibm.com>
>>>> Cc: core-libs-dev at openjdk.java.net
>>>> Date: 2019/08/21 01:21
>>>> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of
>>>> Method.copy() and leafCopy()
>>>>
>>>> Hi Ogata,
>>>>
>>>> The patch looks okay.  Nit: please add a space between if and (.
>>>>
>>>> About volatile methodAccessor field, I checked the history.  Both
>>>> fieldAccessor and methodAccessor were started as volatile and the
>>>> fieldAccessor declaration was updated due to JDK-5044412.   As you
>>>> observe, I think the methodAccessor field could be made
> non-volatile.
>>>> OTOH that might impact when it's inflated to spin bytecode for this
>>>> method invocation.  I don't know how importance to keep its volatile
> vs
>>>> non-volatile in practice without doing benchmarking/real application
> 
>>>> testing.
>>>>
>>>> Mandy
>>>>
>>>> On 8/19/19 2:51 AM, Kazunori Ogata wrote:
>>>>> Hi,
>>>>>
>>>>> May I have review for "JDK-8229871: Imporve performance of
> Method.copy()
>>>>> and leafCopy()"?
>>>>>
>>>>> Method.copy() and leafCopy() creates a copy of a Method object
> with
>>>>> sharing MethodAccessor object. Since the methodAccessor field is a
>>>>> volatile variable, copying this field needs memory fence to ensure
> the
>>>>> field is visible to all threads on the weak memory platforms such
> as POWER
>>>>> and ARM.
>>>>>
>>>>> When the methodAccessor of the root object is null (i.e., not
> initialized
>>>>> yet), we do not need to copy the null value because this field of
> the
>>>>> copied object has been initialized to null in the constructor. We
> can
>>>>> reduce overhead of the memory fence only when the root's
> methodAccessor is
>>>>> non-null. This change improved performance by 5.8% using a micro
> benchmark
>>>>> that repeatedly invokes Class.getMethods().
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.00/
>>>>>
>>>>>
>>>>> By the way, why Method.methodAccessor is volatile, while
>>>>> Field.fieldAccessor and Field.overrideFieldAccessor are not
> volatile?  I
>>>>> know the use of volatile reduces probability of creating
> duplicated method
>>>>> accessor, but the chance still exists.  I couldn't find the
> difference
>>>>> between Method and Field classes to make Method.methodAccessor
> volatile.
>>>>> If we can make it non-volatile, it is more preferable than a quick
> hack
>>>>> above.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Ogata
>>>>>
>>>>
>>>>
> 
> 

From Roger.Riggs at oracle.com  Tue Oct  8 13:59:51 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 8 Oct 2019 09:59:51 -0400
Subject: [14] RFR: DecimalFormat.setGroupingSize(int) allows setting
 negative grouping size
In-Reply-To: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
Message-ID: <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>

Hi Naoto,

DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".

Otherwise looks fine. No need for another webrev.

Thanks, Roger




On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8212749
>
> The proposed CSR and changeset are located at:
>
> https://bugs.openjdk.java.net/browse/JDK-8231851
> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>
> Naoto


From adam.farley at uk.ibm.com  Tue Oct  8 15:06:16 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 8 Oct 2019 16:06:16 +0100
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
In-Reply-To: <84c2563e-752c-bc35-7033-55bfd31e41f2@oracle.com>
References: <OFED94B7DC.69CFC72A-ON00258488.00515B56-80258488.0051CB0D@notes.na.collabserv.com>
 <87mueh5zn7.fsf@mid.deneb.enyo.de>
 <a651b203-0348-c077-4b8c-b73a6a2d784c@oracle.com>
 <OF1EA80740.CBE2F323-ON00258489.00327BAC-80258489.00329ADF@notes.na.collabserv.com>
 <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com>
 <OFB2F55F33.817DCB26-ON0025848C.00394F0C-8025848C.00469D69@notes.na.collabserv.com>
 <84c2563e-752c-bc35-7033-55bfd31e41f2@oracle.com>
Message-ID: <OFEFB9A65D.734AAB4C-ON0025848D.0051E5C4-8025848D.0052F991@notes.na.collabserv.com>

Hi Alan,

Removing jobjc will require changes to a bunch of files. If there's 
support for it, I can do the work, but we should split it into a seperate 
bug.

So the questions are:

1) Can I get a second opinion on the complete removal of everything jobjc 
(in a seperate bug)?

2) What are peoples' thoughts on having the Classpath Exception added to 
the remaining three files?

-- 
jdk/make/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java 

-- jdk/make/src/native/add_gnu_debuglink/add_gnu_debuglink.c 
-- jdk/make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c 

Best Regards

Adam Farley 
IBM Runtimes


Alan Bateman <Alan.Bateman at oracle.com> wrote on 07/10/2019 13:57:53:

> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, Joe Darcy 
> <joe.darcy at oracle.com>, Sergey.Bylokhov at oracle.com, 
> lana.steuck at oracle.com, magnus.ihse.bursie at oracle.com
> Cc: Java Core Libs <core-libs-dev at openjdk.java.net>, Florian Weimer 
> <fw at deneb.enyo.de>, jdk-updates-dev at openjdk.java.net
> Date: 07/10/2019 13:58
> Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
> 
> On 07/10/2019 13:51, Adam Farley8 wrote:
> :
> -- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser 
> It might be simpler to just get rid of the JObjC bits. If you dig 
> through the JDK 8 history then you should see that JObjC.jar was 
> dropped from the boot class path (it should never have been there in
> the first place). The remaining left overs were removed in JDK 9.
> 
> -Alan
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From jan.lahoda at oracle.com  Tue Oct  8 15:27:10 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 8 Oct 2019 17:27:10 +0200
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
Message-ID: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>

Thanks for the new code Erik!

A new webrev/patch that includes this better way of copying is here:
http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/

Any feedback is welcome!

Thanks,
     Jan

On 03. 10. 19 18:06, Erik Joelsson wrote:
> Hello Jan,
> 
> The build change looks ok, but I would recommend this construct for 
> copying the file instead:
> 
> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>  ??? FILES := 
> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \
>  ??? DEST := 
> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, 
> \
> ))
> 
> TARGETS += $(COPY_PREVIEW_FEATURES)
> 
> Then you automatically get all the corner case handling we have 
> implemented over the years for logging, making directories and copying 
> files. Your version is still correct for this case though.
> 
> /Erik
> 
> On 2019-10-03 02:57, Jan Lahoda wrote:
>> Hi,
>>
>> This is a continuation of Joe's patch from here:
>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>
>>
>> APIs associated with preview features are split into two groups: 
>> essential and non-essential. These are marked with an JDK-internal 
>> annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
>> javac follows the PreviewFeature annotation, and produces either 
>> warnings or errors for the usages of such APIs. For the @preview tag, 
>> there is a taglet in the JDK build that adds the content of the tag 
>> into the documentation. The first part of the @preview's text goes 
>> into the summary, the second part goes into the detailed description.
>>
>> For build, a tricky problem is that the jdk.compiler module uses the 
>> PreviewFeature annotation as well, but that is not in the bootstrap 
>> JDK. So, for the intermediate langtools build, the PreviewFeature 
>> annotation is copied from java.base.
>>
>> Proposed webrev:
>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>
>> Javadoc with the change:
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>
>> See for example:
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>
>> CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>
>> Feedback is welcome!
>>
>> Thanks,
>> ??? Jan

From naoto.sato at oracle.com  Tue Oct  8 15:59:58 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 8 Oct 2019 08:59:58 -0700
Subject: [14] RFR: DecimalFormat.setGroupingSize(int) allows setting
 negative grouping size
In-Reply-To: <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
Message-ID: <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>

Hi Roger,

Thank you for the review. In fact, Joe commented about the validity of 
zero on the CSR, so I will need to modify the method description such as:

diff -r 9576895d0f9a 
src/java.base/share/classes/java/text/DecimalFormat.java
--- a/src/java.base/share/classes/java/text/DecimalFormat.java
+++ b/src/java.base/share/classes/java/text/DecimalFormat.java
@@ -2770,10 +2770,13 @@
      /**
       * Set the grouping size. Grouping size is the number of digits 
between
       * grouping separators in the integer portion of a number.  For 
example,
-     * in the number "123,456.78", the grouping size is 3.
-     * <br>
+     * in the number "123,456.78", the grouping size is 3. Grouping size of
+     * zero designates that grouping is not used, which provides the same
+     * formatting as if calling {@link #setGroupingUsed(boolean)
+     * setGroupingUsed(false)}.
+     * <p>
       * The value passed in is converted to a byte, which may lose 
information.
-     * Invalid value, i.e., negative or greater than
+     * Values that are negative or greater than
       * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will throw an
       * {@code IllegalArgumentException}.
       *

I will file a follow-on CSR and merge changesets.

Naoto

On 10/8/19 6:59 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".
> 
> Otherwise looks fine. No need for another webrev.
> 
> Thanks, Roger
> 
> 
> 
> 
> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>
>> The proposed CSR and changeset are located at:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8231851
>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>
>> Naoto
> 

From erik.joelsson at oracle.com  Tue Oct  8 16:04:17 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 8 Oct 2019 09:04:17 -0700
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
Message-ID: <ce6c0449-ea91-6975-ef61-6d40caf80e53@oracle.com>

Build changes look good.

/Erik

On 2019-10-08 08:27, Jan Lahoda wrote:
> Thanks for the new code Erik!
>
> A new webrev/patch that includes this better way of copying is here:
> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>
> Any feedback is welcome!
>
> Thanks,
> ??? Jan
>
> On 03. 10. 19 18:06, Erik Joelsson wrote:
>> Hello Jan,
>>
>> The build change looks ok, but I would recommend this construct for 
>> copying the file instead:
>>
>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>> ???? FILES := 
>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, 
>> \
>> ???? DEST := 
>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, 
>> \
>> ))
>>
>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>
>> Then you automatically get all the corner case handling we have 
>> implemented over the years for logging, making directories and 
>> copying files. Your version is still correct for this case though.
>>
>> /Erik
>>
>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>> Hi,
>>>
>>> This is a continuation of Joe's patch from here:
>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>>
>>>
>>> APIs associated with preview features are split into two groups: 
>>> essential and non-essential. These are marked with an JDK-internal 
>>> annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
>>> javac follows the PreviewFeature annotation, and produces either 
>>> warnings or errors for the usages of such APIs. For the @preview 
>>> tag, there is a taglet in the JDK build that adds the content of the 
>>> tag into the documentation. The first part of the @preview's text 
>>> goes into the summary, the second part goes into the detailed 
>>> description.
>>>
>>> For build, a tricky problem is that the jdk.compiler module uses the 
>>> PreviewFeature annotation as well, but that is not in the bootstrap 
>>> JDK. So, for the intermediate langtools build, the PreviewFeature 
>>> annotation is copied from java.base.
>>>
>>> Proposed webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>
>>> Javadoc with the change:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>
>>> See for example:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>>
>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>>
>>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>
>>> CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>
>>> Feedback is welcome!
>>>
>>> Thanks,
>>> ??? Jan

From kiran.sidhartha.ravikumar at oracle.com  Tue Oct  8 16:17:20 2019
From: kiran.sidhartha.ravikumar at oracle.com (Kiran Ravikumar)
Date: Tue, 08 Oct 2019 17:17:20 +0100
Subject: RFR: JDK-8231770 - Test java/util/zip/FlaterTest.java fails with
 -Xcheck:jni
Message-ID: <5D9CB690.3040403@oracle.com>

Hi Guys,

I am a new hire with the Oracle Java Platform Group and will be working mainly on JDK Update releases. Below is my first contribution. Looking forward to contribute more to the community.

Please review the fix:

Bug :https://bugs.openjdk.java.net/browse/JDK-8231770
Webrev :https://cr.openjdk.java.net/~coffeys/webrev.8231770/webrev/  <https://cr.openjdk.java.net/%7Ecoffeys/webrev.8231770/webrev/>
Explanation : Minor correction to the native code that had wrong arguments. Updated the corresponding test to run with -Xcheck:jni to prevent further occurrences of similar issue.


Thanks,
Kiran


From sverre.moe at gmail.com  Tue Oct  8 16:43:10 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Tue, 8 Oct 2019 18:43:10 +0200
Subject: Regression after jpackage+1-49 update
In-Reply-To: <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
 <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
 <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>
 <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>
Message-ID: <CALAJ+5AHqvubB9PERwnnod9sHbOfONpR9BefrRpuAi2cBwP0Ew@mail.gmail.com>

Some comments about the jpackage+1-49 update.

1) It has become a lot more verbose since jpackage+1-35. Makes using the
verbose argument difficult to actually see relevant output, like the actual
rpmbuild/dpkg command output.

It seems to be running rpmbuild --version twice
Running [rpmbuild --version]
RPM version 4.14.1
Running [rpmbuild --version]
RPM version 4.14.1

Same goes for dpkg-deb --version. It is run twice.

It is running a lot of ldd commands, is that necessary? They are extremely
verbose.
Perhaps jpackage needs different verbosity levels if anyone is actually
interested in all these ldd outputs.

The dpkg command fails a lot with IOException.
dpkg-query: no path found matching pattern /usr/lib64/libX11.so.6
java.io.IOException: command [dpkg, -s, /usr/lib64/libX11.so.6] exited with
1 code

2) Previous resources for RPM are no longer used:
The resources for application.desktop and application.png is no longer used
with building RPM.
Have these been removed? Nothing in the changes listed since previous build
has any mention that this has been removed.

With jpackage+1-35
Using default package resource java32,png [menu icon] (add application.png
to the resource-dir to customize)
Using default package resource template,desktop [Menu shortcut descriptor]
(add application.desktop to the resource-dir to customize)
Using default package resource template.spec [RPM spec file] (add
application.spec to the resource-dir to customize)

With jpackage+1-49
Using default package resource template.spec [RPM spec file] (add
application.spec to the resource-dir to customize)


/Sverre


man. 7. okt. 2019 kl. 10:15 skrev Alan Bateman <Alan.Bateman at oracle.com>:

> On 07/10/2019 08:00, David Holmes wrote:
> > On 7/10/2019 4:43 pm, Alan Bateman wrote:
> >> On 07/10/2019 04:35, David Holmes wrote:
> >>>
> >>> Nothing to do with jpackage but a fix to Class.forName to ensure
> >>> classes are linked as per the specification of forName. You can
> >>> temporarily workaround with -XX:+ClassForNameDeferLinking, but your
> >>> code needs to be updated to deal with LinkageErrors from Class.forName.
> >> In this case, it is core reflection code that it looking at the type
> >> parameters in the type of a field. I suspect this code needs to
> >> translate NCDEF to TypeNotPresentException, other linkage errors
> >> maybe need to be handled here too.
> >
> > Oops! Yes indeed.
> I've created JDK-8231924 [1] to track this. We will need to a wider
> audit of Class.forName usages in the JDK in case there are other issues
> like this.
>
> -Alan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231924
>

From OGATAK at jp.ibm.com  Tue Oct  8 16:57:28 2019
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Wed, 9 Oct 2019 01:57:28 +0900
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>
Message-ID: <OF73A7D8F4.231D969C-ON4925848D.005CBF00-4925848D.005D2AFF@notes.na.collabserv.com>

Hi Claes,

Thank you for your review and comment.

I was also wondering why only these two fields aren't initialized in the 
constructor.  Shall I also make the change you mentioned?


Regards,
Ogata


Claes Redestad <claes.redestad at oracle.com> wrote on 2019/10/08 22:31:29:

> From: Claes Redestad <claes.redestad at oracle.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, core-libs-dev at openjdk.java.net
> Date: 2019/10/08 22:31
> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of 
> Method.copy() and leafCopy()
> 
> Hi,
> 
> webrev.02 looks good to me.
> 
> I think the performance results makes sense since avoiding a volatile
> store (and the potentially expensive store barriers this involves)
> should be the main benefit. Adding a branch to avoid storing null would
> help partially, but not hot Methods.
> 
> Pre-existing issue, but it's somewhat weird that we have two assignments
> outside the package-private constructor: adding root and methodAccessor
> to the constructor would make more immediate sense to me, since we do
> the same thing at the only two callsites:
> 
>          Method res = new Method(clazz, name, parameterTypes, 
returnType,
>                  exceptionTypes, modifiers, slot, signature,
>                  annotations, parameterAnnotations, annotationDefault);
>          res.root = root;
>          res.methodAccessor = methodAccessor;
> 
> ->
> 
>          Method res = new Method(clazz, name, parameterTypes, 
returnType,
>                  exceptionTypes, modifiers, slot, signature,
>                  annotations, parameterAnnotations, annotationDefault,
>                  root, methodAccessor);
> 
> This package-private constructor could also be made private. My guess is
> there was some time when this was used from outside Method and changing
> it was deemed unsavory..
> 
> Thanks!
> 
> /Claes
> 
> On 2019-10-08 12:23, Kazunori Ogata wrote:
> > Hi all,
> > 
> > I posted two changes and got reply that performance evaluation is 
needed.
> > I found that making Method.methodAccessor non-volatile (webrev.02) is
> > better than avoid copying methodAccessor value when it is null
> > (webrev.01), as shown below.
> > 
> > So I'd like to ask review of the former change.  I updated weberv 
using
> > the latest code base (though there was no difference from webrev.02):
> > 
> > Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.03/
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
> > 
> > 
> > For this performance evaluation, I calculated 75 percentile of 9 runs 
of
> > SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers. I
> > bound a JVM to a NUMA node and set the number of GC threads to the 
same as
> > the number of physical cores.  These tuning reduced run-to-run 
fluctuation
> > on POWER (as usual...).
> > 
> > SPECjbb2015:
> >    webrev.02:  critical jOPS +1.6%, max jOPS +0.2%
> >    webrev.01:  critical jOPS +0.4%, max jOPS +0.2%
> > 
> > 
> > For DaCapo, some benchmark still improved performance and some 
degraded,
> > but the geometric mean of all benchmarks were small:
> >    weberv.02: +0.3%
> >    weberv.01: +0.2%
> > 
> > The difference of improvement/degradation between the two changes in 
each
> > benchmark were less than 0.8%.
> > 
> > The range of improvement/degradation in each benchmark were:
> >    webrev.02: between +2.4% and -1.0%
> >    webrev.01: between +1.6% and -1.8%
> > 
> > 
> > So I think webrev.02 (i.e., making methodAccessor non-volatile) is a 
good
> > change, since it improved SPECjbb critical jOPS by 1.6%.
> > 
> > 
> > Regards,
> > Ogata
> > 
> > 
> > Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39:
> > 
> >> From: Kazunori Ogata/Japan/IBM
> >> To: Mandy Chung <mandy.chung at oracle.com>
> >> Cc: core-libs-dev at openjdk.java.net
> >> Date: 2019/08/27 15:41
> >> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() 
and
> > leafCopy()
> >>
> >> Hi Mandy,
> >>
> >> Let me post interim results of the performance evaluation, though I'm
> >> still measuring benchmarks and analyzing them.
> >>
> >> For SPECjbb2015, skipping storing null (webrev.01) was faster than
> > making
> >> methodAccessor non-volatile (webrev.02).  The improvements of each of
> > the
> >> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%,
> >> respectively.  This is only an average of six runs.
> >>
> >> For DaCapo, the results were mixed.  In some benchmark, both of the
> >> changes degraded performance.  In some others, webrev.01 was better, 
but
> > 
> >> weberv.02 was better in some others.
> >>
> >> I'll continue evaluation, but it is helpful if you could give me some
> >> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015.
> >>
> >> Regards,
> >> Ogata
> >>
> >> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41:
> >>
> >>> From: Kazunori Ogata/Japan/IBM
> >>> To: Mandy Chung <mandy.chung at oracle.com>
> >>> Cc: core-libs-dev at openjdk.java.net
> >>> Date: 2019/08/21 20:02
> >>> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy()
> > and leafCopy()
> >>>
> >>> Hi Mandy,
> >>>
> >>> Thank you for reviewing the webrev.  I updated it to add a space 
after
> > 
> >>> "if" and also put four spaces for indentation (it was three).
> >>>
> >>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.01/
> >>>
> >>> Thank you so much for checking the history of fieldAccessor.  I was
> >>> surprised that fieldAccessor was made non-volatile in JDK5, but
> >>> methodAccessor was left as volatile for 15 years after that...
> >>>
> >>> I agree we need benchmark data.  My simple micro benchmark that
> > repeats
> >>> invoking Class.getMethods() improved performance by 70% when it made
> > non-
> >>> volatile (as shown in the following webrev).  I'll try to run larger
> >>> benchmarks, such as SPECjbb2015, to see real impact.
> >>>
> >>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.02/
> >>>
> >>> Regards,
> >>> Ogata
> >>>
> >>> Mandy Chung <mandy.chung at oracle.com> wrote on 2019/08/21 01:21:42:
> >>>
> >>>> From: Mandy Chung <mandy.chung at oracle.com>
> >>>> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> >>>> Cc: core-libs-dev at openjdk.java.net
> >>>> Date: 2019/08/21 01:21
> >>>> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of
> >>>> Method.copy() and leafCopy()
> >>>>
> >>>> Hi Ogata,
> >>>>
> >>>> The patch looks okay.  Nit: please add a space between if and (.
> >>>>
> >>>> About volatile methodAccessor field, I checked the history.  Both
> >>>> fieldAccessor and methodAccessor were started as volatile and the
> >>>> fieldAccessor declaration was updated due to JDK-5044412.   As you
> >>>> observe, I think the methodAccessor field could be made
> > non-volatile.
> >>>> OTOH that might impact when it's inflated to spin bytecode for this
> >>>> method invocation.  I don't know how importance to keep its 
volatile
> > vs
> >>>> non-volatile in practice without doing benchmarking/real 
application
> > 
> >>>> testing.
> >>>>
> >>>> Mandy
> >>>>
> >>>> On 8/19/19 2:51 AM, Kazunori Ogata wrote:
> >>>>> Hi,
> >>>>>
> >>>>> May I have review for "JDK-8229871: Imporve performance of
> > Method.copy()
> >>>>> and leafCopy()"?
> >>>>>
> >>>>> Method.copy() and leafCopy() creates a copy of a Method object
> > with
> >>>>> sharing MethodAccessor object. Since the methodAccessor field is a
> >>>>> volatile variable, copying this field needs memory fence to ensure
> > the
> >>>>> field is visible to all threads on the weak memory platforms such
> > as POWER
> >>>>> and ARM.
> >>>>>
> >>>>> When the methodAccessor of the root object is null (i.e., not
> > initialized
> >>>>> yet), we do not need to copy the null value because this field of
> > the
> >>>>> copied object has been initialized to null in the constructor. We
> > can
> >>>>> reduce overhead of the memory fence only when the root's
> > methodAccessor is
> >>>>> non-null. This change improved performance by 5.8% using a micro
> > benchmark
> >>>>> that repeatedly invokes Class.getMethods().
> >>>>>
> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
> >>>>>
> >>>>> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.00/
> >>>>>
> >>>>>
> >>>>> By the way, why Method.methodAccessor is volatile, while
> >>>>> Field.fieldAccessor and Field.overrideFieldAccessor are not
> > volatile?  I
> >>>>> know the use of volatile reduces probability of creating
> > duplicated method
> >>>>> accessor, but the chance still exists.  I couldn't find the
> > difference
> >>>>> between Method and Field classes to make Method.methodAccessor
> > volatile.
> >>>>> If we can make it non-volatile, it is more preferable than a quick
> > hack
> >>>>> above.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>> Ogata
> >>>>>
> >>>>
> >>>>
> > 
> > 
> 



From alexey.semenyuk at oracle.com  Tue Oct  8 17:16:33 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 8 Oct 2019 13:16:33 -0400
Subject: Regression after jpackage+1-49 update
In-Reply-To: <CALAJ+5AHqvubB9PERwnnod9sHbOfONpR9BefrRpuAi2cBwP0Ew@mail.gmail.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
 <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
 <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>
 <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>
 <CALAJ+5AHqvubB9PERwnnod9sHbOfONpR9BefrRpuAi2cBwP0Ew@mail.gmail.com>
Message-ID: <5e353524-ec3e-23ea-353e-837ae1836fb6@oracle.com>



On 10/8/2019 12:43 PM, Sverre Moe wrote:
> Some comments about the jpackage+1-49 update.
>
> 1) It has become a lot more verbose since jpackage+1-35. Makes using the
> verbose argument difficult to actually see relevant output, like the actual
> rpmbuild/dpkg command output.
>
> It seems to be running rpmbuild --version twice
> Running [rpmbuild --version]
> RPM version 4.14.1
> Running [rpmbuild --version]
> RPM version 4.14.1
>
> Same goes for dpkg-deb --version. It is run twice.
>
> It is running a lot of ldd commands, is that necessary? They are extremely
> verbose.
ldd is used in building a list of prerequisite packages. ldd is applied 
to every shared library and binary in app's image, that is why it is 
invoked so many times.

> Perhaps jpackage needs different verbosity levels if anyone is actually
> interested in all these ldd outputs.
>
> The dpkg command fails a lot with IOException.
> dpkg-query: no path found matching pattern /usr/lib64/libX11.so.6
> java.io.IOException: command [dpkg, -s, /usr/lib64/libX11.so.6] exited with
> 1 code
The command tries to locate a package providing /usr/lib64/libX11.so.6 
needed by one of binaries in app image and fails. Does 
/usr/lib64/libX11.so.6 exist?

>
> 2) Previous resources for RPM are no longer used:
> The resources for application.desktop and application.png is no longer used
> with building RPM.
> Have these been removed? Nothing in the changes listed since previous build
> has any mention that this has been removed.
>
> With jpackage+1-35
> Using default package resource java32,png [menu icon] (add application.png
> to the resource-dir to customize)
> Using default package resource template,desktop [Menu shortcut descriptor]
> (add application.desktop to the resource-dir to customize)
> Using default package resource template.spec [RPM spec file] (add
> application.spec to the resource-dir to customize)
>
> With jpackage+1-49
> Using default package resource template.spec [RPM spec file] (add
> application.spec to the resource-dir to customize)
We don't add desktop integration in the package by default unless there 
is one of `--icon` `--file-associations` options on jpackage command line.
To force adding desktop integration in the package you need to specify 
`--linux-shortcut` option. See [1]

- Alexey

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

>
> /Sverre
>
>
> man. 7. okt. 2019 kl. 10:15 skrev Alan Bateman <Alan.Bateman at oracle.com>:
>
>> On 07/10/2019 08:00, David Holmes wrote:
>>> On 7/10/2019 4:43 pm, Alan Bateman wrote:
>>>> On 07/10/2019 04:35, David Holmes wrote:
>>>>> Nothing to do with jpackage but a fix to Class.forName to ensure
>>>>> classes are linked as per the specification of forName. You can
>>>>> temporarily workaround with -XX:+ClassForNameDeferLinking, but your
>>>>> code needs to be updated to deal with LinkageErrors from Class.forName.
>>>> In this case, it is core reflection code that it looking at the type
>>>> parameters in the type of a field. I suspect this code needs to
>>>> translate NCDEF to TypeNotPresentException, other linkage errors
>>>> maybe need to be handled here too.
>>> Oops! Yes indeed.
>> I've created JDK-8231924 [1] to track this. We will need to a wider
>> audit of Class.forName usages in the JDK in case there are other issues
>> like this.
>>
>> -Alan
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231924
>>


From Alan.Bateman at oracle.com  Tue Oct  8 17:43:39 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 8 Oct 2019 18:43:39 +0100
Subject: RFR: JDK-8231770 - Test java/util/zip/FlaterTest.java fails with
 -Xcheck:jni
In-Reply-To: <5D9CB690.3040403@oracle.com>
References: <5D9CB690.3040403@oracle.com>
Message-ID: <908fcca5-64e3-01c9-81b5-ff4fb256db51@oracle.com>

On 08/10/2019 17:17, Kiran Ravikumar wrote:
> Hi Guys,
>
> I am a new hire with the Oracle Java Platform Group and will be 
> working mainly on JDK Update releases. Below is my first contribution. 
> Looking forward to contribute more to the community.
>
> Please review the fix:
>
> Bug :https://bugs.openjdk.java.net/browse/JDK-8231770
> Webrev :https://cr.openjdk.java.net/~coffeys/webrev.8231770/webrev/ 
> <https://cr.openjdk.java.net/%7Ecoffeys/webrev.8231770/webrev/>
> Explanation : Minor correction to the native code that had wrong 
> arguments. Updated the corresponding test to run with -Xcheck:jni to 
> prevent further occurrences of similar issue.
>
Looks good.


From sverre.moe at gmail.com  Tue Oct  8 17:53:45 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Tue, 8 Oct 2019 19:53:45 +0200
Subject: Regression after jpackage+1-49 update
In-Reply-To: <5e353524-ec3e-23ea-353e-837ae1836fb6@oracle.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
 <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
 <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>
 <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>
 <CALAJ+5AHqvubB9PERwnnod9sHbOfONpR9BefrRpuAi2cBwP0Ew@mail.gmail.com>
 <5e353524-ec3e-23ea-353e-837ae1836fb6@oracle.com>
Message-ID: <CALAJ+5Cvs-ZEvyV9nwRtLxF79AAeBMtKoir45FfDXyEMVrMRBg@mail.gmail.com>

tir. 8. okt. 2019 kl. 19:19 skrev Alexey Semenyuk <
alexey.semenyuk at oracle.com>:

>
>
> On 10/8/2019 12:43 PM, Sverre Moe wrote:
> > Some comments about the jpackage+1-49 update.
> >
> > 1) It has become a lot more verbose since jpackage+1-35. Makes using the
> > verbose argument difficult to actually see relevant output, like the
> actual
> > rpmbuild/dpkg command output.
>


> > It is running a lot of ldd commands, is that necessary? They are
> extremely
> > verbose.
> ldd is used in building a list of prerequisite packages. ldd is applied
> to every shared library and binary in app's image, that is why it is
> invoked so many times.
>
> Is this new in jpackage+1-49? It was not part of the verbose output using
jpackage+1-35.


> > Perhaps jpackage needs different verbosity levels if anyone is actually
> > interested in all these ldd outputs.
> >
> > The dpkg command fails a lot with IOException.
> > dpkg-query: no path found matching pattern /usr/lib64/libX11.so.6
> > java.io.IOException: command [dpkg, -s, /usr/lib64/libX11.so.6] exited
> with
> > 1 code
> The command tries to locate a package providing /usr/lib64/libX11.so.6
> needed by one of binaries in app image and fails. Does
> /usr/lib64/libX11.so.6 exist?
>
> All the files it tries to locate does exist, but it still fails with an
Exception.

Running [dpkg, -S, /usr/lib64/libXrender.so.1]
dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1
java.io.IOException: Command [dpkg, -S, /usr/lib64/libXrender.so.1] exited
with 1 code
       at
jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68)
       at
jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$initLibProvidersLookup$13(LinuxDebBundler.java:239)
       at
jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.lambda$execute$1(LibProvidersLookup.java:64)
       at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
       at
java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1694)
       at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
       at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
       at
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
       at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
       at
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
       at
jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.execute(LibProvidersLookup.java:75)
       at
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.getListOfNeededPackages(LinuxPackageBundler.java:210)
       at
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.createDefaultReplacementData(LinuxPackageBundler.java:236)
       at
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:175)
       at
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627)
       at
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
       at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
       at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)

Could the error message from dpkg be because I am not running on a Debian
type distribution.
> dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1
Building an DEB package has not been a problem before on a RedHat type
distribution.


> 2) Previous resources for RPM are no longer used:
> > The resources for application.desktop and application.png is no longer
> used
> > with building RPM.
> > Have these been removed? Nothing in the changes listed since previous
> build
> > has any mention that this has been removed.
> >
> > With jpackage+1-35
> > Using default package resource java32,png [menu icon] (add
> application.png
> > to the resource-dir to customize)
> > Using default package resource template,desktop [Menu shortcut
> descriptor]
> > (add application.desktop to the resource-dir to customize)
> > Using default package resource template.spec [RPM spec file] (add
> > application.spec to the resource-dir to customize)
> >
> > With jpackage+1-49
> > Using default package resource template.spec [RPM spec file] (add
> > application.spec to the resource-dir to customize)
> We don't add desktop integration in the package by default unless there
> is one of `--icon` `--file-associations` options on jpackage command line.
> To force adding desktop integration in the package you need to specify
> `--linux-shortcut` option. See [1]
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8229779
>
> Thanks, adding the --linux-shortcut solves that problem.
However it seems to be a regression there in choosing the desktop resource
file.

Using default package resource template.desktop [Menu shortcut descriptor]
(add application-application.desktop to the resource-dir to customize)

It should be just "application.desktop", not
"application-application.desktop".

/Sverre

From claes.redestad at oracle.com  Tue Oct  8 18:37:42 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 8 Oct 2019 20:37:42 +0200
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <OF73A7D8F4.231D969C-ON4925848D.005CBF00-4925848D.005D2AFF@notes.na.collabserv.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>
 <OF73A7D8F4.231D969C-ON4925848D.005CBF00-4925848D.005D2AFF@notes.na.collabserv.com>
Message-ID: <cc518a00-00a0-0a12-f9ed-ae0ac8e30f87@oracle.com>



On 2019-10-08 18:57, Kazunori Ogata wrote:
> Hi Claes,
> 
> Thank you for your review and comment.
> 
> I was also wondering why only these two fields aren't initialized in the
> constructor.  Shall I also make the change you mentioned?

I think it might be better as a follow-up, since there might exist some
reason not to do that cleanup at all and I don't think we should hold up
this improvement.

Thanks!

/Claes

From alexey.semenyuk at oracle.com  Tue Oct  8 18:55:24 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 8 Oct 2019 14:55:24 -0400
Subject: Regression after jpackage+1-49 update
In-Reply-To: <CALAJ+5Cvs-ZEvyV9nwRtLxF79AAeBMtKoir45FfDXyEMVrMRBg@mail.gmail.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
 <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
 <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>
 <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>
 <CALAJ+5AHqvubB9PERwnnod9sHbOfONpR9BefrRpuAi2cBwP0Ew@mail.gmail.com>
 <5e353524-ec3e-23ea-353e-837ae1836fb6@oracle.com>
 <CALAJ+5Cvs-ZEvyV9nwRtLxF79AAeBMtKoir45FfDXyEMVrMRBg@mail.gmail.com>
Message-ID: <b125f6d0-a0ff-f2a2-972d-a7ff6eedba50@oracle.com>



On 10/8/2019 1:53 PM, Sverre Moe wrote:
> tir. 8. okt. 2019 kl. 19:19 skrev Alexey Semenyuk 
> <alexey.semenyuk at oracle.com <mailto:alexey.semenyuk at oracle.com>>:
>
>
>
>     On 10/8/2019 12:43 PM, Sverre Moe wrote:
>     > Some comments about the jpackage+1-49 update.
>     >
>     > 1) It has become a lot more verbose since jpackage+1-35. Makes
>     using the
>     > verbose argument difficult to actually see relevant output, like
>     the actual
>     > rpmbuild/dpkg command output.
>
>     > It is running a lot of ldd commands, is that necessary? They are
>     extremely
>     > verbose.
>     ldd is used in building a list of prerequisite packages. ldd is
>     applied
>     to every shared library and binary in app's image, that is why it is
>     invoked so many times.
>
> Is this new in jpackage+1-49? It was not part of the verbose output 
> using jpackage+1-35.
Correct. jpackage tries to build list of packages needed by application 
(mostly by Java runtime) since 1-49.

>     > Perhaps jpackage needs different verbosity levels if anyone is
>     actually
>     > interested in all these ldd outputs.
>     >
>     > The dpkg command fails a lot with IOException.
>     > dpkg-query: no path found matching pattern /usr/lib64/libX11.so.6
>     > java.io.IOException: command [dpkg, -s, /usr/lib64/libX11.so.6]
>     exited with
>     > 1 code
>     The command tries to locate a package providing
>     /usr/lib64/libX11.so.6
>     needed by one of binaries in app image and fails. Does
>     /usr/lib64/libX11.so.6 exist?
>
> All the files it tries to locate does exist, but it still fails with 
> an Exception.
>
> Running [dpkg, -S, /usr/lib64/libXrender.so.1]
> dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1
> java.io.IOException: Command [dpkg, -S, /usr/lib64/libXrender.so.1] 
> exited with 1 code
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$initLibProvidersLookup$13(LinuxDebBundler.java:239)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.lambda$execute$1(LibProvidersLookup.java:64)
> ? ? ? ?at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> ? ? ? ?at 
> java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1694)
> ? ? ? ?at 
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> ? ? ? ?at 
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> ? ? ? ?at 
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> ? ? ? ?at 
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ? ? ? ?at 
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.execute(LibProvidersLookup.java:75)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.getListOfNeededPackages(LinuxPackageBundler.java:210)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.createDefaultReplacementData(LinuxPackageBundler.java:236)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:175)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627)
> ? ? ? ?at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
> ? ? ? ?at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> ? ? ? ?at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)
> Could the error message from dpkg be because I am not running on a 
> Debian type distribution.
Yes. This is the reason for all failures with `dpkg -S` command.
> > dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1
> Building an DEB package has not been a problem before on a RedHat type 
> distribution.
Failures of `dpkg -S` command are harmless, application package will 
just have empty list of prerequisite packages.
We should probably not run `ldd` and subsequent `dpkg -S` commands in 
the environment where `dpkg -S` fails. Filed [1] to track this.

>
>     > 2) Previous resources for RPM are no longer used:
>     > The resources for application.desktop and application.png is no
>     longer used
>     > with building RPM.
>     > Have these been removed? Nothing in the changes listed since
>     previous build
>     > has any mention that this has been removed.
>     >
>     > With jpackage+1-35
>     > Using default package resource java32,png [menu icon] (add
>     application.png
>     > to the resource-dir to customize)
>     > Using default package resource template,desktop [Menu shortcut
>     descriptor]
>     > (add application.desktop to the resource-dir to customize)
>     > Using default package resource template.spec [RPM spec file] (add
>     > application.spec to the resource-dir to customize)
>     >
>     > With jpackage+1-49
>     > Using default package resource template.spec [RPM spec file] (add
>     > application.spec to the resource-dir to customize)
>     We don't add desktop integration in the package by default unless
>     there
>     is one of `--icon` `--file-associations` options on jpackage
>     command line.
>     To force adding desktop integration in the package you need to
>     specify
>     `--linux-shortcut` option. See [1]
>
>     - Alexey
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8229779
>
> Thanks, adding the --linux-shortcut solves that problem.
> However it seems to be a regression there in choosing the desktop 
> resource file.
>
> Using default package resource template.desktop [Menu shortcut 
> descriptor] (add application-application.desktop to the resource-dir 
> to customize)
>
> It should be just "application.desktop", not 
> "application-application.desktop".
XDG recommends .desktop files should have vendor prefix.
jpackage uses package name as a prefix for .desktop files it registers 
in the system with `xdg-desktop-menu` command.
However the prefix should not be used when looking up for a file in 
resource directory.
So you are right, this is a regression. I filed [2] to track this.

- Alexey

[1] https://bugs.openjdk.java.net/browse/JDK-8232024
[2] https://bugs.openjdk.java.net/browse/JDK-8232029

>
> /Sverre
>


From andy.herrick at oracle.com  Tue Oct  8 19:06:25 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 8 Oct 2019 15:06:25 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that use
 jpackage
Message-ID: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

This change is to Expose the macro $APPDIR for use in --java-options 
value, to rename macros to mean what they are called, and to eliminate 
several unused macros.

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

[2] http://cr.openjdk.java.net/~herrick/8231910/

/Andy


From philip.race at oracle.com  Tue Oct  8 19:23:43 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 08 Oct 2019 12:23:43 -0700
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications
 that use jpackage
In-Reply-To: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
Message-ID: <5D9CE23F.4070101@oracle.com>

      protected String getCfgAppDir() {
-        return Path.of("$APPDIR").resolve(
-                ApplicationLayout.linuxAppImage().appDirectory()).toString() + File.separator;
+        return Path.of("$ROOTDIR").resolve(
+                ApplicationLayout.linuxAppImage().appDirectory()).toString()
+                + File.separator;


Do you really want to leave the method name unchanged ?

-phil.

On 10/8/19, 12:06 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This change is to Expose the macro $APPDIR for use in --java-options 
> value, to rename macros to mean what they are called, and to eliminate 
> several unused macros.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>
> [2] http://cr.openjdk.java.net/~herrick/8231910/
>
> /Andy
>

From mandy.chung at oracle.com  Tue Oct  8 19:24:35 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 8 Oct 2019 12:24:35 -0700
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>
Message-ID: <e712ff32-2e4c-d4fb-031b-17665e840fd7@oracle.com>



On 10/8/19 6:31 AM, Claes Redestad wrote:
> Hi,
>
> webrev.02 looks good to me.
>

webrev.02 looks fine to me as well.

> I think the performance results makes sense since avoiding a volatile
> store (and the potentially expensive store barriers this involves)
> should be the main benefit. Adding a branch to avoid storing null would
> help partially, but not hot Methods.
>
> Pre-existing issue, but it's somewhat weird that we have two assignments
> outside the package-private constructor: adding root and methodAccessor
> to the constructor would make more immediate sense to me, since we do
> the same thing at the only two callsites:
>
> ??????? Method res = new Method(clazz, name, parameterTypes, returnType,
> ??????????????? exceptionTypes, modifiers, slot, signature,
> ??????????????? annotations, parameterAnnotations, annotationDefault);
> ??????? res.root = root;
> ??????? res.methodAccessor = methodAccessor;
>
> ->
>
> ??????? Method res = new Method(clazz, name, parameterTypes, returnType,
> ??????????????? exceptionTypes, modifiers, slot, signature,
> ??????????????? annotations, parameterAnnotations, annotationDefault,
> ??????????????? root, methodAccessor);
>
> This package-private constructor could also be made private. My guess is
> there was some time when this was used from outside Method and changing
> it was deemed unsavory..

The parameters of the Method constructor are the content from a 
ClassFile to represent a method whereas root and methodAccessor fields 
are not part of it. The current implementation allocates a Method 
instance and sets the fields individually instead of calling the 
constructor probably due to bootstrapping.

I suggest to keep it as it is.? OTOH making the constructor private is fine.

Mandy

From alexey.semenyuk at oracle.com  Tue Oct  8 19:33:19 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 8 Oct 2019 15:33:19 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
Message-ID: <a5e3a862-df2c-07cf-0cf1-9ea5d5882807@oracle.com>

Andy,

AbstractAppImageBuilder.java: is extra ` + File.separator` by intention?

WinMsiBundler.java: static cache will be a potential problem if jpackage 
will be used as tool provider, i.e. in scenario when jpackage will be 
called multiple times per jvm session.

- Alexey

On 10/8/2019 3:06 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This change is to Expose the macro $APPDIR for use in --java-options 
> value, to rename macros to mean what they are called, and to eliminate 
> several unused macros.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>
> [2] http://cr.openjdk.java.net/~herrick/8231910/
>
> /Andy
>


From andy.herrick at oracle.com  Tue Oct  8 19:44:53 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 8 Oct 2019 15:44:53 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <5D9CE23F.4070101@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
 <5D9CE23F.4070101@oracle.com>
Message-ID: <9a801e60-e08a-e4b5-2989-e8fa069ce39e@oracle.com>

yes - $ROOTDIR now means what $APPDIR used to, and this method gets 
$ROOTDIR/app/ , so getCfgAppDir() is still the right name.

/Andy

On 10/8/2019 3:23 PM, Philip Race wrote:
>       protected String getCfgAppDir() {
> - return Path.of("$APPDIR").resolve(
> - ApplicationLayout.linuxAppImage().appDirectory()).toString() + 
> File.separator;
> + return Path.of("$ROOTDIR").resolve(
> + ApplicationLayout.linuxAppImage().appDirectory()).toString()
> + + File.separator;
>
> Do you really want to leave the method name unchanged ?
>
> -phil.
>
> On 10/8/19, 12:06 PM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> This change is to Expose the macro $APPDIR for use in --java-options 
>> value, to rename macros to mean what they are called, and to 
>> eliminate several unused macros.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>>
>> [2] http://cr.openjdk.java.net/~herrick/8231910/
>>
>> /Andy
>>

From andy.herrick at oracle.com  Tue Oct  8 20:21:30 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 8 Oct 2019 16:21:30 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <a5e3a862-df2c-07cf-0cf1-9ea5d5882807@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
 <a5e3a862-df2c-07cf-0cf1-9ea5d5882807@oracle.com>
Message-ID: <df616284-4328-06b6-b8e6-ed8908a5ff95@oracle.com>


On 10/8/2019 3:33 PM, Alexey Semenyuk wrote:
> Andy,
>
> AbstractAppImageBuilder.java: is extra ` + File.separator` by intention?
this was just trying to be consistent - doesn't matter to native code 
who is only one to see this value - but I should probably change back.
>
> WinMsiBundler.java: static cache will be a potential problem if 
> jpackage will be used as tool provider, i.e. in scenario when jpackage 
> will be called multiple times per jvm session.

??

it is only the versions of the tool that is static.

you think app will use ToolProvider to call jpackage, then wait while 
user installs new version of WIX on system, then app will use 
ToolProvider again ?

I suppose that is possible.

Anyway - the code to get the wix tools version only once is not really a 
part of this fix, just triggered by your desire to print out all of the 
usage text from candle and light when getting their version with 
--verbose option.

So I can remove that from this fix.

/Andy


>
> - Alexey
>
> On 10/8/2019 3:06 PM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> This change is to Expose the macro $APPDIR for use in --java-options 
>> value, to rename macros to mean what they are called, and to 
>> eliminate several unused macros.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>>
>> [2] http://cr.openjdk.java.net/~herrick/8231910/
>>
>> /Andy
>>
>

From alexey.semenyuk at oracle.com  Tue Oct  8 20:27:36 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 8 Oct 2019 16:27:36 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <df616284-4328-06b6-b8e6-ed8908a5ff95@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
 <a5e3a862-df2c-07cf-0cf1-9ea5d5882807@oracle.com>
 <df616284-4328-06b6-b8e6-ed8908a5ff95@oracle.com>
Message-ID: <86cd9df5-993c-455b-40a7-b8bd426cbf10@oracle.com>



On 10/8/2019 4:21 PM, Andy Herrick wrote:
>
> On 10/8/2019 3:33 PM, Alexey Semenyuk wrote:
>> Andy,
>>
>> AbstractAppImageBuilder.java: is extra ` + File.separator` by intention?
> this was just trying to be consistent - doesn't matter to native code 
> who is only one to see this value - but I should probably change back.
>>
>> WinMsiBundler.java: static cache will be a potential problem if 
>> jpackage will be used as tool provider, i.e. in scenario when 
>> jpackage will be called multiple times per jvm session.
>
> ??
>
> it is only the versions of the tool that is static.
>
> you think app will use ToolProvider to call jpackage, then wait while 
> user installs new version of WIX on system, then app will use 
> ToolProvider again ?
>
> I suppose that is possible.
Yep, this is highly unlikely, but still possible.

>
> Anyway - the code to get the wix tools version only once is not really 
> a part of this fix, just triggered by your desire to print out all of 
> the usage text from candle and light when getting their version with 
> --verbose option.
>
> So I can remove that from this fix.
Just making the fields non static would be good, I guess.

- Alexey

>
> /Andy
>
>
>>
>> - Alexey
>>
>> On 10/8/2019 3:06 PM, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> This change is to Expose the macro $APPDIR for use in --java-options 
>>> value, to rename macros to mean what they are called, and to 
>>> eliminate several unused macros.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8231910/
>>>
>>> /Andy
>>>
>>


From andy.herrick at oracle.com  Tue Oct  8 21:02:48 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 8 Oct 2019 17:02:48 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <86cd9df5-993c-455b-40a7-b8bd426cbf10@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
 <a5e3a862-df2c-07cf-0cf1-9ea5d5882807@oracle.com>
 <df616284-4328-06b6-b8e6-ed8908a5ff95@oracle.com>
 <86cd9df5-993c-455b-40a7-b8bd426cbf10@oracle.com>
Message-ID: <14951b1c-9622-f5e9-80ff-72e0352f1f49@oracle.com>


On 10/8/2019 4:27 PM, Alexey Semenyuk wrote:
>>
>> Anyway - the code to get the wix tools version only once is not 
>> really a part of this fix, just triggered by your desire to print out 
>> all of the usage text from candle and light when getting their 
>> version with --verbose option.
>>
>> So I can remove that from this fix.
> Just making the fields non static would be good, I guess.
>
> - Alexey 


I can't do that, the two variables are used from a static method.

I might look at just avoiding calling validateWixTools() multiple times, 
but that still leaves 2 calls to findToolVersion(getLightPath())


/Andy


From andy.herrick at oracle.com  Tue Oct  8 22:09:43 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 8 Oct 2019 18:09:43 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
Message-ID: <ff45f2dd-be8a-42f8-7f05-357f67c2715d@oracle.com>

Minor revision after some discussion:

[3]:? http://cr.openjdk.java.net/~herrick/8231910/webrev.02

/Andy

On 10/8/2019 3:06 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This change is to Expose the macro $APPDIR for use in --java-options 
> value, to rename macros to mean what they are called, and to eliminate 
> several unused macros.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>
> [2] http://cr.openjdk.java.net/~herrick/8231910/
>
> /Andy
>

From vlv.spb.ru at mail.ru  Tue Oct  8 22:18:32 2019
From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=)
Date: Wed, 09 Oct 2019 01:18:32 +0300
Subject: =?UTF-8?B?UmVbMl06IFJGUjogODIyNjI5NzogRHVhbC1waXZvdCBxdWlja3NvcnQgaW1w?=
 =?UTF-8?B?cm92ZW1lbnRz?=
In-Reply-To: <1a031e52-b824-65bc-1ec1-c6d80a231cd9@oracle.com>
References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com>
 <392719f4-d67c-f900-0f2d-6c9f826a5392@oracle.com>
 <1a031e52-b824-65bc-1ec1-c6d80a231cd9@oracle.com>
Message-ID: <1570573112.22458835@f475.i.mail.ru>

Hi Brent,

Thank you for review, see my comments inline:

>Oct 8, 2019, 1:53 +03:00 ?? Brent Christian <brent.christian at oracle.com>:
>
>Hi, Vladimir
>
>I've read through the changes[1].  I have the following comments:
>
>---
>src/java.base/share/classes/java/util/Arrays.java
>
>* Regarding the indentation changes in the equals() methods:
>
>-     * <pre>    {@code new Double(d1).equals(new Double(d2))}</pre>
>+     * <pre>{@code new Double(d1).equals(new Double(d2))}</pre>
>...
>-     * <pre>    {@code new Double(d1).equals(new Double(d2))}</pre>
>+     * <pre>{@code new Double(d1).equals(new Double(d2))}</pre>
>...
>-     * <pre>    {@code new Float(f1).equals(new Float(f2))}</pre>
>+     * <pre>{@code new Float(f1).equals(new Float(f2))}</pre>
>...
>-     * <pre>    {@code new Float(f1).equals(new Float(f2))}</pre>
>+     * <pre>{@code new Float(f1).equals(new Float(f2))}</pre>
>
>Looking at the generated JavaDoc, this indentation is intentional.  I've 
>reverted these changes.
>
>* Otherwise, the JavaDoc changes are limited to within @implNote 
>(previously written out as "Implementation note", in some cases).  I 
>don't believe a CSR is warranted.

Agree, thank you for reverting these changes.

>---
>test/jdk/java/util/Arrays/Sorting.java
>
>Some general comments:
>
>* I see a lot of renames[2] that I don't think add value, and clutter 
>the changes (1000+ total changed lines in a 2000 line file).  I feel 
>similarly about the changes from post- to pre- incrementing of the for() 
>loop indices.  If it's OK with you, Vladimir, I can take care of 
>reverting these changes.

The following renaming changes are important
and should be kept. My explanation is here:

* testAndCheck -> testQuicksort

Quicksort only was tested in previous version
(parallel Quicksort was tested in other class).
Now all tests are common for parallel and sequential
Quicksorts, plus tests for heap sort are also added.
Therefore, testAndCheck is spitted into two methods:
testQuicksort and testHeapSort.

* Merge -> Merging [Sort|Builder]

Before starting Quicksort we check if given array is
almost sorted. In this case sorted sub-parts are merged.
It is not the same as merge sort, therefore I use proper
name "merging" instead of "merge".

* ourDescription -> name, myKey -> key,
myValue -> value, MyRandom -> TestRandom

There was practice to use prefix "my" for
non-static fields of a class, and "our" for static
fields. Now this approach is not actual because it
is easy to recognize the type of a field in modern IDE
the names are shorter.

* seed -> random

I renamed to have consistent names "random : randoms"
in for-loop instead of "seed : randoms", see "for (long random : randoms)"
----------------

* Other changes, like failed -> fail, i++ -> ++i,
and TypeConverter, FloatBuilder, DoubleBuilder, SortedBuilder
to be non-static can be reverted.

I can revert them, if you agree.

>* I like that the various DualPivotQuickSort methods are tested 
>directly (via SortingHelper).  I'd prefer that we also continue testing 
>direct calls to Arrays.sort(), as that's what users will call.  What 
>would be the best way to add that back in?  (Maybe a SortingHelper 
>variant that calls Arrays.sort()?).
I will add direct calls to Arrays.sort() and Arrays.parallelSort() also.

>* Having the test operation depend on setting various values to the 
>static 'sortingHelper' field seems brittle to me.  This could be a good 
>opportunity to convert from static to instance methods, make 
>'sortingHelper' and 'name' member variables, and create separate Sorting 
>objects for each SortingHelper. Such a refactoring is not strictly 
>necessary, but I think it would be nice to have.

Good idea, I will implement it and send you update version very soon.

>---
>test/jdk/java/util/Arrays/FailedFloat.java
>
>Is this test necessary, given the addition of testFloatNegativeZero() in 
>Sorting.java ?

Not necessary, because testFloatNegativeZero() covers this case.
This class was created to reproduce bug when float-pointing zeros
and NaNs are sorted.

Please remove FailedFloat.java. It makes sense to add the source of this class to 8226297.

>Thanks,
>-Brent
>
>1. 
>http://cr.openjdk.java.net/~bchristi/8226297/webrev05-adaptive/webrev/index.html
>
>2. Name changes in Sorting.java:
>?????testAndCheck -> testQuicksort
>?????seed -> random
>?????ourDescription -> name
>?????failedSort -> failSort
>?????failed -> fail
>?????myKey -> key
>?????myValue -> value
>?????Merge->Merging [Sort|Builder]
>?????MyRandom->TestRandom
>?????failedCompare->failCompare
>?????change TypeConverter, FloatBuilder, DoubleBuilder, SortedBuilder to 
>be non-static
Thank you,
Vladimir

From alexey.semenyuk at oracle.com  Tue Oct  8 22:29:27 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 8 Oct 2019 18:29:27 -0400
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <ff45f2dd-be8a-42f8-7f05-357f67c2715d@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
 <ff45f2dd-be8a-42f8-7f05-357f67c2715d@oracle.com>
Message-ID: <aa54be46-39da-7570-f97c-8a088df5c939@oracle.com>

Looks good.

- Alexey

On 10/8/2019 6:09 PM, Andy Herrick wrote:
> Minor revision after some discussion:
>
> [3]:? http://cr.openjdk.java.net/~herrick/8231910/webrev.02
>
> /Andy
>
> On 10/8/2019 3:06 PM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> This change is to Expose the macro $APPDIR for use in --java-options 
>> value, to rename macros to mean what they are called, and to 
>> eliminate several unused macros.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>>
>> [2] http://cr.openjdk.java.net/~herrick/8231910/
>>
>> /Andy
>>


From alexander.matveev at oracle.com  Tue Oct  8 23:20:30 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 8 Oct 2019 16:20:30 -0700
Subject: RFR: JDK-8231910: Expose the APPDIR variable to applications that
 use jpackage
In-Reply-To: <aa54be46-39da-7570-f97c-8a088df5c939@oracle.com>
References: <dacb1601-60cc-be06-8d64-6564cf7a7f3d@oracle.com>
 <ff45f2dd-be8a-42f8-7f05-357f67c2715d@oracle.com>
 <aa54be46-39da-7570-f97c-8a088df5c939@oracle.com>
Message-ID: <5d3d7fdd-a39d-d00e-2ec3-73b312111237@oracle.com>

Hi Andy,

Looks good.

Thanks,
Alexander

On 10/8/2019 3:29 PM, Alexey Semenyuk wrote:
> Looks good.
>
> - Alexey
>
> On 10/8/2019 6:09 PM, Andy Herrick wrote:
>> Minor revision after some discussion:
>>
>> [3]:? http://cr.openjdk.java.net/~herrick/8231910/webrev.02
>>
>> /Andy
>>
>> On 10/8/2019 3:06 PM, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> This change is to Expose the macro $APPDIR for use in --java-options 
>>> value, to rename macros to mean what they are called, and to 
>>> eliminate several unused macros.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231910
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8231910/
>>>
>>> /Andy
>>>
>


From brent.christian at oracle.com  Wed Oct  9 00:23:17 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 8 Oct 2019 17:23:17 -0700
Subject: Regression after jpackage+1-49 update
In-Reply-To: <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>
References: <CAPCtbB_+ErKO54RGHKUa9DJtVD7Odr3YLuOMJ6r=wJDT8Mt6zA@mail.gmail.com>
 <fe16c5b1-3480-6192-16db-fb83ec2feba4@oracle.com>
 <baa0aade-9808-48ab-384a-e3d180a49508@oracle.com>
 <242be47c-a800-bb5c-061d-765cc4cccdc8@oracle.com>
 <58172086-1cdf-6259-b213-ba8e0132558d@oracle.com>
Message-ID: <746ecb44-82e1-3c2e-42e7-16c7f878477e@oracle.com>

On 10/7/19 1:12 AM, Alan Bateman wrote:
>> On 7/10/2019 4:43 pm, Alan Bateman wrote:
>>> On 07/10/2019 04:35, David Holmes wrote:
>>>> >>>> You can temporarily workaround with
>>>> -XX:+ClassForNameDeferLinking, but your code needs to be
>>>> updated to deal with LinkageErrors from Class.forName. >>>
>>> I suspect this code needs to translate NCDEF to
>>> TypeNotPresentException, other linkage errors maybe need to be
>>> handled here too. >
> I've created JDK-8231924 to track this.

Addressing JDK-8231924 will fix it so Field.getGenericType() throws a 
TypeNotPresentException, as specified.

I suspect that prior to the Class.forName() linking fix[1], there was no 
attempt to link the 'OptionalService' class (referring to Tornai's test 
case - it throws no exception with -XX:+ClassForNameDeferLinking).

It could be that the code would also need to be updated to link 
successfully, in order to avoid a TypeNotPresentException.

-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8212117

From brent.christian at oracle.com  Wed Oct  9 00:41:28 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 8 Oct 2019 17:41:28 -0700
Subject: RFR: 8226297: Dual-pivot quicksort improvements
In-Reply-To: <1570573112.22458835@f475.i.mail.ru>
References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com>
 <392719f4-d67c-f900-0f2d-6c9f826a5392@oracle.com>
 <1a031e52-b824-65bc-1ec1-c6d80a231cd9@oracle.com>
 <1570573112.22458835@f475.i.mail.ru>
Message-ID: <b5379549-2d67-9c3c-ab8a-56accd5477db@oracle.com>

Hi, Vladimir

On 10/8/19 3:18 PM, Vladimir Yaroslavskiy wrote:
> 
> The following renaming changes are important
> and should be kept. My explanation is here
 > ...

Thanks for the explanation - much appreciated.

> * Other changes, like failed -> fail, i++ -> ++i,
> and TypeConverter, FloatBuilder, DoubleBuilder, SortedBuilder
> to be non-static can be reverted.
> 
> I can revert them, if you agree.

That would be great, thanks.

>     * I like that the various DualPivotQuickSort methods are tested
>     directly (via SortingHelper). I'd prefer that we also continue testing
>     direct calls to Arrays.sort(), as that's what users will call. What
>     would be the best way to add that back in? (Maybe a SortingHelper
>     variant that calls Arrays.sort()?).
> 
> I will add direct calls to Arrays.sort() and Arrays.parallelSort() also.

Great, thank you.

>     * Having the test operation depend on setting various values to the
>     static 'sortingHelper' field seems brittle to me. This could be a good
>     opportunity to convert from static to instance methods, make
>     'sortingHelper' and 'name' member variables, and create separate
>     Sorting
>     objects for each SortingHelper. Such a refactoring is not strictly
>     necessary, but I think it would be nice to have.
> 
> 
> Good idea, I will implement it and send you update version very soon.

Sounds good!

>>     test/jdk/java/util/Arrays/FailedFloat.java
>> 
>>     Is this test necessary, given the addition of
>>     testFloatNegativeZero() in
>>     Sorting.java ?
> 
> Not necessary, because testFloatNegativeZero() covers this case.
> This class was created to reproduce bug when float-pointing zeros
> and NaNs are sorted.
> 
> Please remove FailedFloat.java. It makes sense to add the source of this 
> class to 8226297.

Done and done.

-Brent

From alexander.matveev at oracle.com  Wed Oct  9 02:24:34 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 8 Oct 2019 19:24:34 -0700
Subject: RFR: JDK-8231858: [macos] App does not run if installed with pkg
Message-ID: <dee63c23-8a74-00fc-c92f-835ac94c9427@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Fixed by adding read permissions to all jars during installation.

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

[2] http://cr.openjdk.java.net/~almatvee/8231858/webrev.00/

Thanks,
Alexander

From alexey.semenyuk at oracle.com  Wed Oct  9 02:49:16 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 8 Oct 2019 22:49:16 -0400
Subject: RFR: JDK-8231858: [macos] App does not run if installed with pkg
In-Reply-To: <dee63c23-8a74-00fc-c92f-835ac94c9427@oracle.com>
References: <dee63c23-8a74-00fc-c92f-835ac94c9427@oracle.com>
Message-ID: <29b87a78-0d30-34af-58bf-84c3e1543f1f@oracle.com>

Looks good

On 10/8/2019 10:24 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Fixed by adding read permissions to all jars during installation.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231858
>
> [2] http://cr.openjdk.java.net/~almatvee/8231858/webrev.00/
>
> Thanks,
> Alexander


From sean.coffey at oracle.com  Wed Oct  9 06:31:59 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 9 Oct 2019 07:31:59 +0100
Subject: RFR: JDK-8231770 - Test java/util/zip/FlaterTest.java fails with
 -Xcheck:jni
In-Reply-To: <5D9CB690.3040403@oracle.com>
References: <5D9CB690.3040403@oracle.com>
Message-ID: <e7cb71fd-cfbc-83a4-26df-66b70266259f@oracle.com>

Looks good Kiran. I'll sponsor this for you.

regards,
Sean.

On 08/10/2019 17:17, Kiran Ravikumar wrote:
> Hi Guys,
>
> I am a new hire with the Oracle Java Platform Group and will be 
> working mainly on JDK Update releases. Below is my first contribution. 
> Looking forward to contribute more to the community.
>
> Please review the fix:
>
> Bug :https://bugs.openjdk.java.net/browse/JDK-8231770
> Webrev :https://cr.openjdk.java.net/~coffeys/webrev.8231770/webrev/ 
> <https://cr.openjdk.java.net/%7Ecoffeys/webrev.8231770/webrev/>
> Explanation : Minor correction to the native code that had wrong 
> arguments. Updated the corresponding test to run with -Xcheck:jni to 
> prevent further occurrences of similar issue.
>
>
> Thanks,
> Kiran
>

From peter.levart at gmail.com  Wed Oct  9 07:44:13 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 9 Oct 2019 09:44:13 +0200
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
Message-ID: <14b28640-cd16-c672-c4bb-754116e882da@gmail.com>

Hi Ogata,

May I just add that volatile field ensured that MethodAccessor object 
was correctly published. DelegatingMethodAccessortImpl is not safe to be 
published via data race because it contains plain `delegate` field 
initialized in the constructor. In addition, the object that is first 
assigned to that field is NativeMethodAccessorImpl which has plain 
`parent` field. You can get NPE when invoking the Method.invoke from 
multuiple threads if Method.methodAccessor is not volatile.

In addition, It would be nice to have two microbenchmarks exercising:
a) Method copy performance
b) Method invocation performance

Regards, Peter

P.S. When exploring the possibility of an alternative MethodAccessor 
implementation (using MethodHandle(s)):

http://cr.openjdk.java.net/~plevart/jdk-dev/6824466_MHReflectionAccessors/webrev.00.2/

...I found out that it was possible to re-arrange the play between 
DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and generated 
MethodAccessor in such a way that the DelegatingMethodAccessortImpl 
becomes safe to be published via data race. This allowed for 
Method.methodAccessor field to become plain field. In addition this 
field can be made @Stable which further optimizes access to 
MethodAccessor instance when Method instance can be constant-folded, 
which showed in special microbenchmarks.

So perhaps you could try to use above implementation (just changes to 
DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and part of 
Reflection factory but without MH* stuff) and measure it against current 
and your implementation (which as shown above has a data-race flaw).

On 10/8/19 12:23 PM, Kazunori Ogata wrote:
> Hi all,
>
> I posted two changes and got reply that performance evaluation is needed.
> I found that making Method.methodAccessor non-volatile (webrev.02) is
> better than avoid copying methodAccessor value when it is null
> (webrev.01), as shown below.
>
> So I'd like to ask review of the former change.  I updated weberv using
> the latest code base (though there was no difference from webrev.02):
>
> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.03/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
>
>
> For this performance evaluation, I calculated 75 percentile of 9 runs of
> SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers.  I
> bound a JVM to a NUMA node and set the number of GC threads to the same as
> the number of physical cores.  These tuning reduced run-to-run fluctuation
> on POWER (as usual...).
>
> SPECjbb2015:
>    webrev.02:  critical jOPS +1.6%, max jOPS +0.2%
>    webrev.01:  critical jOPS +0.4%, max jOPS +0.2%
>
>
> For DaCapo, some benchmark still improved performance and some degraded,
> but the geometric mean of all benchmarks were small:
>    weberv.02: +0.3%
>    weberv.01: +0.2%
>
> The difference of improvement/degradation between the two changes in each
> benchmark were less than 0.8%.
>
> The range of improvement/degradation in each benchmark were:
>    webrev.02: between +2.4% and -1.0%
>    webrev.01: between +1.6% and -1.8%
>
>
> So I think webrev.02 (i.e., making methodAccessor non-volatile) is a good
> change, since it improved SPECjbb critical jOPS by 1.6%.
>
>
> Regards,
> Ogata
>
>
> Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39:
>
>> From: Kazunori Ogata/Japan/IBM
>> To: Mandy Chung <mandy.chung at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Date: 2019/08/27 15:41
>> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() and
> leafCopy()
>> Hi Mandy,
>>
>> Let me post interim results of the performance evaluation, though I'm
>> still measuring benchmarks and analyzing them.
>>
>> For SPECjbb2015, skipping storing null (webrev.01) was faster than
> making
>> methodAccessor non-volatile (webrev.02).  The improvements of each of
> the
>> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%,
>> respectively.  This is only an average of six runs.
>>
>> For DaCapo, the results were mixed.  In some benchmark, both of the
>> changes degraded performance.  In some others, webrev.01 was better, but
>> weberv.02 was better in some others.
>>
>> I'll continue evaluation, but it is helpful if you could give me some
>> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015.
>>
>> Regards,
>> Ogata
>>
>> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41:
>>
>>> From: Kazunori Ogata/Japan/IBM
>>> To: Mandy Chung <mandy.chung at oracle.com>
>>> Cc: core-libs-dev at openjdk.java.net
>>> Date: 2019/08/21 20:02
>>> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy()
> and leafCopy()
>>> Hi Mandy,
>>>
>>> Thank you for reviewing the webrev.  I updated it to add a space after
>>> "if" and also put four spaces for indentation (it was three).
>>>
>>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.01/
>>>
>>> Thank you so much for checking the history of fieldAccessor.  I was
>>> surprised that fieldAccessor was made non-volatile in JDK5, but
>>> methodAccessor was left as volatile for 15 years after that...
>>>
>>> I agree we need benchmark data.  My simple micro benchmark that
> repeats
>>> invoking Class.getMethods() improved performance by 70% when it made
> non-
>>> volatile (as shown in the following webrev).  I'll try to run larger
>>> benchmarks, such as SPECjbb2015, to see real impact.
>>>
>>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.02/
>>>
>>> Regards,
>>> Ogata
>>>
>>> Mandy Chung <mandy.chung at oracle.com> wrote on 2019/08/21 01:21:42:
>>>
>>>> From: Mandy Chung <mandy.chung at oracle.com>
>>>> To: Kazunori Ogata <OGATAK at jp.ibm.com>
>>>> Cc: core-libs-dev at openjdk.java.net
>>>> Date: 2019/08/21 01:21
>>>> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of
>>>> Method.copy() and leafCopy()
>>>>
>>>> Hi Ogata,
>>>>
>>>> The patch looks okay.  Nit: please add a space between if and (.
>>>>
>>>> About volatile methodAccessor field, I checked the history.  Both
>>>> fieldAccessor and methodAccessor were started as volatile and the
>>>> fieldAccessor declaration was updated due to JDK-5044412.   As you
>>>> observe, I think the methodAccessor field could be made
> non-volatile.
>>>> OTOH that might impact when it's inflated to spin bytecode for this
>>>> method invocation.  I don't know how importance to keep its volatile
> vs
>>>> non-volatile in practice without doing benchmarking/real application
>>>> testing.
>>>>
>>>> Mandy
>>>>
>>>> On 8/19/19 2:51 AM, Kazunori Ogata wrote:
>>>>> Hi,
>>>>>
>>>>> May I have review for "JDK-8229871: Imporve performance of
> Method.copy()
>>>>> and leafCopy()"?
>>>>>
>>>>> Method.copy() and leafCopy() creates a copy of a Method object
> with
>>>>> sharing MethodAccessor object. Since the methodAccessor field is a
>>>>> volatile variable, copying this field needs memory fence to ensure
> the
>>>>> field is visible to all threads on the weak memory platforms such
> as POWER
>>>>> and ARM.
>>>>>
>>>>> When the methodAccessor of the root object is null (i.e., not
> initialized
>>>>> yet), we do not need to copy the null value because this field of
> the
>>>>> copied object has been initialized to null in the constructor. We
> can
>>>>> reduce overhead of the memory fence only when the root's
> methodAccessor is
>>>>> non-null. This change improved performance by 5.8% using a micro
> benchmark
>>>>> that repeatedly invokes Class.getMethods().
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.00/
>>>>>
>>>>>
>>>>> By the way, why Method.methodAccessor is volatile, while
>>>>> Field.fieldAccessor and Field.overrideFieldAccessor are not
> volatile?  I
>>>>> know the use of volatile reduces probability of creating
> duplicated method
>>>>> accessor, but the chance still exists.  I couldn't find the
> difference
>>>>> between Method and Field classes to make Method.methodAccessor
> volatile.
>>>>> If we can make it non-volatile, it is more preferable than a quick
> hack
>>>>> above.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Ogata
>>>>>
>>>>
>


From magnus.ihse.bursie at oracle.com  Wed Oct  9 08:42:56 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 9 Oct 2019 10:42:56 +0200
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
Message-ID: <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>

I can?t see how the compilation is dependent on the copy being finished. Since Erik contributed this it will probably be correct :) but I?d appreciate an explanation on how this dependency is guaranteed. 

Or maybe I?m misunderstanding what this is supposed to do?

/Magnus

> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
> 
> Thanks for the new code Erik!
> 
> A new webrev/patch that includes this better way of copying is here:
> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
> 
> Any feedback is welcome!
> 
> Thanks,
>    Jan
> 
>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>> Hello Jan,
>> The build change looks ok, but I would recommend this construct for copying the file instead:
>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>     FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \
>>     DEST := $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, \
>> ))
>> TARGETS += $(COPY_PREVIEW_FEATURES)
>> Then you automatically get all the corner case handling we have implemented over the years for logging, making directories and copying files. Your version is still correct for this case though.
>> /Erik
>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>> Hi,
>>> 
>>> This is a continuation of Joe's patch from here:
>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>> 
>>> APIs associated with preview features are split into two groups: essential and non-essential. These are marked with an JDK-internal annotation, PreviewFeature, and a tag in the javadoc, @preview. The javac follows the PreviewFeature annotation, and produces either warnings or errors for the usages of such APIs. For the @preview tag, there is a taglet in the JDK build that adds the content of the tag into the documentation. The first part of the @preview's text goes into the summary, the second part goes into the detailed description.
>>> 
>>> For build, a tricky problem is that the jdk.compiler module uses the PreviewFeature annotation as well, but that is not in the bootstrap JDK. So, for the intermediate langtools build, the PreviewFeature annotation is copied from java.base.
>>> 
>>> Proposed webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>> 
>>> Javadoc with the change:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>> 
>>> See for example:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>> 
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>> 
>>> CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>> 
>>> Feedback is welcome!
>>> 
>>> Thanks,
>>>     Jan


From peter.levart at gmail.com  Wed Oct  9 08:45:47 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 9 Oct 2019 10:45:47 +0200
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <cc518a00-00a0-0a12-f9ed-ae0ac8e30f87@oracle.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>
 <OF73A7D8F4.231D969C-ON4925848D.005CBF00-4925848D.005D2AFF@notes.na.collabserv.com>
 <cc518a00-00a0-0a12-f9ed-ae0ac8e30f87@oracle.com>
Message-ID: <007587e0-58b6-18e5-ebe7-ecb74b5c5871@gmail.com>



On 10/8/19 8:37 PM, Claes Redestad wrote:
>
>
> On 2019-10-08 18:57, Kazunori Ogata wrote:
>> Hi Claes,
>>
>> Thank you for your review and comment.
>>
>> I was also wondering why only these two fields aren't initialized in the
>> constructor.? Shall I also make the change you mentioned?
>
> I think it might be better as a follow-up, since there might exist some
> reason not to do that cleanup at all and I don't think we should hold up
> this improvement.

Perhaps the decision for methodAccessor to be absent from constructor 
was the fact that it starts as null and can later be set also in the 
following direction:

 ??? root.methodAccessor = this.methodAccessor;

...in this case the `root` has already been constructed and `this` is 
what is being constructed. I prefer only one way of setting a particular 
field instead of two ways.

Regards, Peter

>
> Thanks!
>
> /Claes


From chris.hegarty at oracle.com  Wed Oct  9 09:22:12 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 9 Oct 2019 10:22:12 +0100
Subject: RFR: JDK-8231770 - Test java/util/zip/FlaterTest.java fails with
 -Xcheck:jni
In-Reply-To: <5D9CB690.3040403@oracle.com>
References: <5D9CB690.3040403@oracle.com>
Message-ID: <03bfcec8-d2b1-7db4-f066-5b7ffb5fb41d@oracle.com>


On 08/10/2019 17:17, Kiran Ravikumar wrote:
> Hi Guys,
> 
> I am a new hire with the Oracle Java Platform Group and will be working 
> mainly on JDK Update releases. Below is my first contribution. Looking 
> forward to contribute more to the community.
> 
> Please review the fix:
> 
> Bug :https://bugs.openjdk.java.net/browse/JDK-8231770
> Webrev :https://cr.openjdk.java.net/~coffeys/webrev.8231770/webrev/  

LGTM.

-Chris.

From chris.hegarty at oracle.com  Wed Oct  9 11:56:29 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 9 Oct 2019 12:56:29 +0100
Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable
 non-transient instance fields in serializable classes
In-Reply-To: <a92456c2-1a13-b29f-5ee7-83610f07feb3@oracle.com>
References: <ac630074-c805-a9f3-9cb6-f2cfa8816154@oracle.com>
 <a92456c2-1a13-b29f-5ee7-83610f07feb3@oracle.com>
Message-ID: <24ce0afd-8c02-06eb-252f-228d51da477b@oracle.com>

Joe,

On 05/10/2019 04:04, Joe Darcy wrote:
> Hello,
> 
> Please review the revised fix:
> 
>  ??? http://cr.openjdk.java.net/~darcy/8231202.1/

Given the prior discussion in this thread, then I think this version 
looks fine ( which consists solely of warning suppressions ).

-Chris.

From Roger.Riggs at oracle.com  Wed Oct  9 14:28:51 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 9 Oct 2019 10:28:51 -0400
Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable
 non-transient instance fields in serializable classes
In-Reply-To: <24ce0afd-8c02-06eb-252f-228d51da477b@oracle.com>
References: <ac630074-c805-a9f3-9cb6-f2cfa8816154@oracle.com>
 <a92456c2-1a13-b29f-5ee7-83610f07feb3@oracle.com>
 <24ce0afd-8c02-06eb-252f-228d51da477b@oracle.com>
Message-ID: <ae4fc503-c66b-3678-be8b-13da1d82f273@oracle.com>

+1

On 10/9/19 7:56 AM, Chris Hegarty wrote:
> Joe,
>
> On 05/10/2019 04:04, Joe Darcy wrote:
>> Hello,
>>
>> Please review the revised fix:
>>
>> ???? http://cr.openjdk.java.net/~darcy/8231202.1/
>
> Given the prior discussion in this thread, then I think this version 
> looks fine ( which consists solely of warning suppressions ).
>
> -Chris.


From andy.herrick at oracle.com  Wed Oct  9 15:10:30 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 9 Oct 2019 11:10:30 -0400
Subject: RFR: JDK-8231858: [macos] App does not run if installed with pkg
In-Reply-To: <dee63c23-8a74-00fc-c92f-835ac94c9427@oracle.com>
References: <dee63c23-8a74-00fc-c92f-835ac94c9427@oracle.com>
Message-ID: <9e8d1fbc-953f-bdbb-5112-d54f9ca797da@oracle.com>

looks good.

/Andy

On 10/8/2019 10:24 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Fixed by adding read permissions to all jars during installation.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231858
>
> [2] http://cr.openjdk.java.net/~almatvee/8231858/webrev.00/
>
> Thanks,
> Alexander

From erik.joelsson at oracle.com  Wed Oct  9 15:41:22 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 9 Oct 2019 08:41:22 -0700
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
Message-ID: <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>

Oh, you are absolutely correct, the dependency is missing.

We need something like this inside "define SetupInterimModule":

$$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)

/Erik

On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
> I can?t see how the compilation is dependent on the copy being finished. Since Erik contributed this it will probably be correct :) but I?d appreciate an explanation on how this dependency is guaranteed.
>
> Or maybe I?m misunderstanding what this is supposed to do?
>
> /Magnus
>
>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
>>
>> Thanks for the new code Erik!
>>
>> A new webrev/patch that includes this better way of copying is here:
>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>>
>> Any feedback is welcome!
>>
>> Thanks,
>>     Jan
>>
>>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>>> Hello Jan,
>>> The build change looks ok, but I would recommend this construct for copying the file instead:
>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>>      FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \
>>>      DEST := $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, \
>>> ))
>>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>> Then you automatically get all the corner case handling we have implemented over the years for logging, making directories and copying files. Your version is still correct for this case though.
>>> /Erik
>>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> This is a continuation of Joe's patch from here:
>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html
>>>>
>>>> APIs associated with preview features are split into two groups: essential and non-essential. These are marked with an JDK-internal annotation, PreviewFeature, and a tag in the javadoc, @preview. The javac follows the PreviewFeature annotation, and produces either warnings or errors for the usages of such APIs. For the @preview tag, there is a taglet in the JDK build that adds the content of the tag into the documentation. The first part of the @preview's text goes into the summary, the second part goes into the detailed description.
>>>>
>>>> For build, a tricky problem is that the jdk.compiler module uses the PreviewFeature annotation as well, but that is not in the bootstrap JDK. So, for the intermediate langtools build, the PreviewFeature annotation is copied from java.base.
>>>>
>>>> Proposed webrev:
>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>>
>>>> Javadoc with the change:
>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>>
>>>> See for example:
>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html
>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html
>>>>
>>>> JBS:
>>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>>
>>>> CSR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>>
>>>> Feedback is welcome!
>>>>
>>>> Thanks,
>>>>      Jan

From akozlov at azul.com  Wed Oct  9 16:24:16 2019
From: akozlov at azul.com (Anton Kozlov)
Date: Wed, 9 Oct 2019 19:24:16 +0300
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
 <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
 <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>
Message-ID: <fbec6c6d-2324-ec0d-9440-ed42fa7d4304@azul.com>

Hi Mandy,

thanks for the review!

Updated webrev with fixes:
http://cr.openjdk.java.net/~akozlov/8231584/webrev.03/

Few notes below:

On 08.10.2019 01:20, Mandy Chung wrote:
> I think another way doing it is to initialize ClassLoader.sys_paths and usr_paths fields at System::initPhase1. These static fields can be initialized after the library path system properties are set and before calling VM.initLevel(1).?? ClassLoader::loadLibrary can assert if sys_path and usr_paths are non-null.

Agree with this.  A more natural place would be phase3, where system class loader is initialized.  But something from phase2 loads a library.

> I prefer to name the test and directory with the API it verifies.? For example rename the directory to loadLibrary and rename the test files to

Renamed, full path to the test is java/lang/Runtime/loadLibrary/LoadLibraryTest, as the issue involves Runtime.loadLibrary in first place.

>   70     static void exitPassed() {
>   71         System.exit(95);
>   72     }
>  
>  ?94                 // Finish the test
>   95                 exitPassed();
> 
> 
> Is there a better way to finish up the test?? someLibrary does not exist.? Can it handshake by setting a global state that Target::<clinit> can validate and expect UnsatisfiedLinkError to be thrown?

Thanks, changed this way.  A mark is stored in TestClassLoader after findLibrary passed after the point of deadlock.  The mark is checked in the end of the test. 

Thanks,
Anton


From andvolkov at gmail.com  Wed Oct  9 14:58:40 2019
From: andvolkov at gmail.com (Andrey Volkov)
Date: Wed, 9 Oct 2019 17:58:40 +0300
Subject: How to use "resource-dir" option for jpackage?
Message-ID: <CACY3ECAa3k4gdKDPKHZPaiOvzdn6_KiZaPH7Mg67NqyMjOgL2A@mail.gmail.com>

Hello.

Can you give a hint or en example how to use --resource-dir option for
jpackage?
According to the help, it is possible to override jpackage's resources
(icons, logos, etc. that are shown in installers). Is it right?

-- 
Best regards,
Andrey Volkov

From andy.herrick at oracle.com  Wed Oct  9 17:09:37 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 9 Oct 2019 13:09:37 -0400
Subject: How to use "resource-dir" option for jpackage?
In-Reply-To: <CACY3ECAa3k4gdKDPKHZPaiOvzdn6_KiZaPH7Mg67NqyMjOgL2A@mail.gmail.com>
References: <CACY3ECAa3k4gdKDPKHZPaiOvzdn6_KiZaPH7Mg67NqyMjOgL2A@mail.gmail.com>
Message-ID: <d820c066-02c9-157b-430e-ad96b118c8b1@oracle.com>


On 10/9/2019 10:58 AM, Andrey Volkov wrote:
> Hello.
>
> Can you give a hint or en example how to use --resource-dir option for
> jpackage?
> According to the help, it is possible to override jpackage's resources
> (icons, logos, etc. that are shown in installers). Is it right?

generally yes, if the logo is loaded from an internal resource, you 
should be able to override it in this way.

On Windows the msi installer has no images that come from jpackage 
resources, so will use macOS for an example.

I run:

> jpackage --name mjar-test --module me.mymodule/me.mymodule.Main 
> --module-path mjars/mjar.jar --verbose
>
then as part of the verbose output I see:

> Using default package resource background dmg.png [dmg background] add 
> mjar-test-background.png to the resource dir to customize.
>
so I create a dir "resources" and I put my image file in it as 
mjar-test-background.png then I re-run with command:

> jpackage --name mjar-test --resource-dir resources --module 
> me.mymodule/me.mymodule.Main --module-path mjars/mjar.jar --verbose
>
And now it should create? dmg installer with your customized dmg 
background image.


/Andy



From joe.darcy at oracle.com  Wed Oct  9 17:10:36 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 9 Oct 2019 10:10:36 -0700
Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable
 non-transient instance fields in serializable classes
In-Reply-To: <ae4fc503-c66b-3678-be8b-13da1d82f273@oracle.com>
References: <ac630074-c805-a9f3-9cb6-f2cfa8816154@oracle.com>
 <a92456c2-1a13-b29f-5ee7-83610f07feb3@oracle.com>
 <24ce0afd-8c02-06eb-252f-228d51da477b@oracle.com>
 <ae4fc503-c66b-3678-be8b-13da1d82f273@oracle.com>
Message-ID: <b7372da6-ee0f-6e74-9715-218e6037af41@oracle.com>

Thanks for the reviews.

Running some final checks, I'd also like to include two more 
@SuppressWarnings to clear the issues in java.base outside of 
java.util.concurrent; patch below.

Thanks,

-Joe

diff -r 6e017b301287 
src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java
--- 
a/src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java 
Wed Oct 09 09:57:41 2019 -0700
+++ 
b/src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java 
Wed Oct 09 10:07:53 2019 -0700
@@ -49,6 +49,7 @@
 ???? private static final long serialVersionUID = 100L;
 ???? private static final PlatformLogger logger = 
HttpURLConnection.getHttpLogger();

+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? private final HttpCallerInfo hci;

 ???? // These maps are used to manage the GSS availability for diffrent
@@ -67,6 +68,7 @@
 ???? }

 ???? // The HTTP Negotiate Helper
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? private Negotiator negotiator = null;

 ??? /**

On 10/9/2019 7:28 AM, Roger Riggs wrote:
> +1
>
> On 10/9/19 7:56 AM, Chris Hegarty wrote:
>> Joe,
>>
>> On 05/10/2019 04:04, Joe Darcy wrote:
>>> Hello,
>>>
>>> Please review the revised fix:
>>>
>>> http://cr.openjdk.java.net/~darcy/8231202.1/
>>
>> Given the prior discussion in this thread, then I think this version 
>> looks fine ( which consists solely of warning suppressions ).
>>
>> -Chris.
>

From Roger.Riggs at oracle.com  Wed Oct  9 17:13:59 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 9 Oct 2019 13:13:59 -0400
Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable
 non-transient instance fields in serializable classes
In-Reply-To: <b7372da6-ee0f-6e74-9715-218e6037af41@oracle.com>
References: <ac630074-c805-a9f3-9cb6-f2cfa8816154@oracle.com>
 <a92456c2-1a13-b29f-5ee7-83610f07feb3@oracle.com>
 <24ce0afd-8c02-06eb-252f-228d51da477b@oracle.com>
 <ae4fc503-c66b-3678-be8b-13da1d82f273@oracle.com>
 <b7372da6-ee0f-6e74-9715-218e6037af41@oracle.com>
Message-ID: <41999929-f29d-5a9b-80d8-632d6cd6189e@oracle.com>

Looks fine.

Roger


On 10/9/19 1:10 PM, Joe Darcy wrote:
> Thanks for the reviews.
>
> Running some final checks, I'd also like to include two more 
> @SuppressWarnings to clear the issues in java.base outside of 
> java.util.concurrent; patch below.
>
> Thanks,
>
> -Joe
>
> diff -r 6e017b301287 
> src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java
> --- 
> a/src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java 
> Wed Oct 09 09:57:41 2019 -0700
> +++ 
> b/src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java 
> Wed Oct 09 10:07:53 2019 -0700
> @@ -49,6 +49,7 @@
> ???? private static final long serialVersionUID = 100L;
> ???? private static final PlatformLogger logger = 
> HttpURLConnection.getHttpLogger();
>
> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
> ???? private final HttpCallerInfo hci;
>
> ???? // These maps are used to manage the GSS availability for diffrent
> @@ -67,6 +68,7 @@
> ???? }
>
> ???? // The HTTP Negotiate Helper
> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
> ???? private Negotiator negotiator = null;
>
> ??? /**
>
> On 10/9/2019 7:28 AM, Roger Riggs wrote:
>> +1
>>
>> On 10/9/19 7:56 AM, Chris Hegarty wrote:
>>> Joe,
>>>
>>> On 05/10/2019 04:04, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> Please review the revised fix:
>>>>
>>>> http://cr.openjdk.java.net/~darcy/8231202.1/
>>>
>>> Given the prior discussion in this thread, then I think this version 
>>> looks fine ( which consists solely of warning suppressions ).
>>>
>>> -Chris.
>>


From naoto.sato at oracle.com  Wed Oct  9 17:47:36 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 9 Oct 2019 10:47:36 -0700
Subject: [14] RFR 8212749: DecimalFormat.setGroupingSize(int) allows
 setting negative grouping size, 8231984: Clarify semantics of
 DecimalFormat.getGroupingSize(0)
In-Reply-To: <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
Message-ID: <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>

I revised the fix, incorporating the clarification of the value zero as 
the grouping size, which has separate JIRA issue and CSR as follows:

https://bugs.openjdk.java.net/browse/JDK-8231984
https://bugs.openjdk.java.net/browse/JDK-8232012

The merged changeset is as follows:

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

Please review.

Naoto

On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
> Hi Roger,
> 
> Thank you for the review. In fact, Joe commented about the validity of 
> zero on the CSR, so I will need to modify the method description such as:
> 
> diff -r 9576895d0f9a 
> src/java.base/share/classes/java/text/DecimalFormat.java
> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
> @@ -2770,10 +2770,13 @@
>  ???? /**
>  ????? * Set the grouping size. Grouping size is the number of digits 
> between
>  ????? * grouping separators in the integer portion of a number.? For 
> example,
> -???? * in the number "123,456.78", the grouping size is 3.
> -???? * <br>
> +???? * in the number "123,456.78", the grouping size is 3. Grouping 
> size of
> +???? * zero designates that grouping is not used, which provides the same
> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
> +???? * setGroupingUsed(false)}.
> +???? * <p>
>  ????? * The value passed in is converted to a byte, which may lose 
> information.
> -???? * Invalid value, i.e., negative or greater than
> +???? * Values that are negative or greater than
>  ????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will throw an
>  ????? * {@code IllegalArgumentException}.
>  ????? *
> 
> I will file a follow-on CSR and merge changesets.
> 
> Naoto
> 
> On 10/8/19 6:59 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".
>>
>> Otherwise looks fine. No need for another webrev.
>>
>> Thanks, Roger
>>
>>
>>
>>
>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>
>>> The proposed CSR and changeset are located at:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>
>>> Naoto
>>

From joe.darcy at oracle.com  Wed Oct  9 22:37:53 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 9 Oct 2019 15:37:53 -0700
Subject: JDK 14 RFR of JDK-8232076: Suppress warnings on non-serializable
 non-transient instance fields java.naming
Message-ID: <514f6678-f7e7-3c08-5fb2-0ca207eb57e4@oracle.com>

Hello,

The serialization review continues, this time a few fields in the 
java.naming module:

 ??? http://cr.openjdk.java.net/~darcy/8232076.0/

Patch below; thanks,

-Joe

--- 
old/src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java 
2019-10-09 15:32:45.258000000 -0700
+++ 
new/src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java 
2019-10-09 15:32:45.062000000 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2019, 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
@@ -51,6 +51,7 @@
 ???? /**
 ????? * Whether links were encountered.
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected Object followingLink = null;

 ???? /**
@@ -71,6 +72,7 @@
 ????? * The last resolved context. Used to set the "AltNameCtx" in a
 ????? * CannotProceedException.
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected Context resolvedContext = null;

 ???? /**
--- old/src/java.naming/share/classes/javax/naming/Binding.java 
2019-10-09 15:32:45.750000000 -0700
+++ new/src/java.naming/share/classes/javax/naming/Binding.java 
2019-10-09 15:32:45.566000000 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2019, 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
@@ -54,6 +54,7 @@
 ????? * @see #getObject
 ????? * @see #setObject
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? private Object boundObj;

 ???? /**
--- 
old/src/java.naming/share/classes/javax/naming/CannotProceedException.java 
2019-10-09 15:32:46.218000000 -0700
+++ 
new/src/java.naming/share/classes/javax/naming/CannotProceedException.java 
2019-10-09 15:32:46.022000000 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2019, 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
@@ -127,6 +127,7 @@
 ????? * @see #altName
 ????? * @see javax.naming.spi.ObjectFactory#getObjectInstance
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected Context altNameCtx = null;

 ???? /**
--- old/src/java.naming/share/classes/javax/naming/LinkException.java 
2019-10-09 15:32:46.706000000 -0700
+++ new/src/java.naming/share/classes/javax/naming/LinkException.java 
2019-10-09 15:32:46.502000000 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2019, 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
@@ -85,6 +85,7 @@
 ?????? * @see #getLinkResolvedObj
 ?????? * @see #setLinkResolvedObj
 ?????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected Object linkResolvedObj;

 ???? /**
--- old/src/java.naming/share/classes/javax/naming/NamingException.java 
2019-10-09 15:32:47.210000000 -0700
+++ new/src/java.naming/share/classes/javax/naming/NamingException.java 
2019-10-09 15:32:47.002000000 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1999, 2003, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2019, 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
@@ -79,6 +79,7 @@
 ?????? * @see #getResolvedObj
 ?????? * @see #setResolvedObj
 ?????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected Object resolvedObj;
 ???? /**
 ????? * Contains the remaining name that has not been resolved yet.
--- 
old/src/java.naming/share/classes/javax/naming/event/NamingEvent.java 
2019-10-09 15:32:47.710000000 -0700
+++ 
new/src/java.naming/share/classes/javax/naming/event/NamingEvent.java 
2019-10-09 15:32:47.522000000 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1999, 2000, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2019, 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
@@ -122,6 +122,7 @@
 ????? * Contains information about the change that generated this event.
 ????? * @serial
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected Object changeInfo;

 ???? /**
--- 
old/src/java.naming/share/classes/javax/naming/spi/ResolveResult.java 
2019-10-09 15:32:48.218000000 -0700
+++ 
new/src/java.naming/share/classes/javax/naming/spi/ResolveResult.java 
2019-10-09 15:32:48.010000000 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2019, 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
@@ -50,6 +50,7 @@
 ????? * Constructors should always initialize this.
 ????? * @serial
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected Object resolvedObj;
 ???? /**
 ????? * Field containing the remaining name yet to be resolved.


From naoto.sato at oracle.com  Wed Oct  9 22:39:50 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 9 Oct 2019 15:39:50 -0700
Subject: [14] RFR: 8231273: Upgrade CLDR to v36
Message-ID: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8231273/webrev.00/

The webrev is huge, but majority of the changes is just to replace the 
CLDR source locale data from version 35.1 to 36. The real code changes 
are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
handles aliases for currency/percent formats, and retrieves per-element 
fallback strings for compact number patterns. Also relevant tests are 
modified accordingly.

Naoto

From naoto.sato at oracle.com  Wed Oct  9 22:45:55 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 9 Oct 2019 15:45:55 -0700
Subject: [14] RFR: 8225435: Upgrade IANA Language Subtag Registry to the
 latest for JDK14
Message-ID: <b86c7fa1-5c81-4d2f-3a4d-d6978216ceeb@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8225435/webrev.00/

The change is to upgrade the data file to the latest (dated 2019-09-16). 
A relevant test case is modified accordingly.

Naoto

From lance.andersen at oracle.com  Wed Oct  9 23:07:04 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 9 Oct 2019 19:07:04 -0400
Subject: JDK 14 RFR of JDK-8232076: Suppress warnings on non-serializable
 non-transient instance fields java.naming
In-Reply-To: <514f6678-f7e7-3c08-5fb2-0ca207eb57e4@oracle.com>
References: <514f6678-f7e7-3c08-5fb2-0ca207eb57e4@oracle.com>
Message-ID: <FB9263EF-A3FF-47B9-8340-7D7070CFDFC2@oracle.com>

Looks OK Joe

> On Oct 9, 2019, at 6:37 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> The serialization review continues, this time a few fields in the java.naming module:
> 
>     http://cr.openjdk.java.net/~darcy/8232076.0/
> 
> Patch below; thanks,
> 
> -Joe
> 
> --- old/src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java 2019-10-09 15:32:45.258000000 -0700
> +++ new/src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java 2019-10-09 15:32:45.062000000 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, 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
> @@ -51,6 +51,7 @@
>      /**
>       * Whether links were encountered.
>       */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      protected Object followingLink = null;
> 
>      /**
> @@ -71,6 +72,7 @@
>       * The last resolved context. Used to set the "AltNameCtx" in a
>       * CannotProceedException.
>       */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      protected Context resolvedContext = null;
> 
>      /**
> --- old/src/java.naming/share/classes/javax/naming/Binding.java 2019-10-09 15:32:45.750000000 -0700
> +++ new/src/java.naming/share/classes/javax/naming/Binding.java 2019-10-09 15:32:45.566000000 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, 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
> @@ -54,6 +54,7 @@
>       * @see #getObject
>       * @see #setObject
>       */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      private Object boundObj;
> 
>      /**
> --- old/src/java.naming/share/classes/javax/naming/CannotProceedException.java 2019-10-09 15:32:46.218000000 -0700
> +++ new/src/java.naming/share/classes/javax/naming/CannotProceedException.java 2019-10-09 15:32:46.022000000 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, 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
> @@ -127,6 +127,7 @@
>       * @see #altName
>       * @see javax.naming.spi.ObjectFactory#getObjectInstance
>       */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      protected Context altNameCtx = null;
> 
>      /**
> --- old/src/java.naming/share/classes/javax/naming/LinkException.java 2019-10-09 15:32:46.706000000 -0700
> +++ new/src/java.naming/share/classes/javax/naming/LinkException.java 2019-10-09 15:32:46.502000000 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, 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
> @@ -85,6 +85,7 @@
>        * @see #getLinkResolvedObj
>        * @see #setLinkResolvedObj
>        */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      protected Object linkResolvedObj;
> 
>      /**
> --- old/src/java.naming/share/classes/javax/naming/NamingException.java 2019-10-09 15:32:47.210000000 -0700
> +++ new/src/java.naming/share/classes/javax/naming/NamingException.java 2019-10-09 15:32:47.002000000 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2003, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, 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
> @@ -79,6 +79,7 @@
>        * @see #getResolvedObj
>        * @see #setResolvedObj
>        */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      protected Object resolvedObj;
>      /**
>       * Contains the remaining name that has not been resolved yet.
> --- old/src/java.naming/share/classes/javax/naming/event/NamingEvent.java 2019-10-09 15:32:47.710000000 -0700
> +++ new/src/java.naming/share/classes/javax/naming/event/NamingEvent.java 2019-10-09 15:32:47.522000000 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2000, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, 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
> @@ -122,6 +122,7 @@
>       * Contains information about the change that generated this event.
>       * @serial
>       */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      protected Object changeInfo;
> 
>      /**
> --- old/src/java.naming/share/classes/javax/naming/spi/ResolveResult.java 2019-10-09 15:32:48.218000000 -0700
> +++ new/src/java.naming/share/classes/javax/naming/spi/ResolveResult.java 2019-10-09 15:32:48.010000000 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, 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
> @@ -50,6 +50,7 @@
>       * Constructors should always initialize this.
>       * @serial
>       */
> +    @SuppressWarnings("serial") // Not statically typed as Serializable
>      protected Object resolvedObj;
>      /**
>       * Field containing the remaining name yet to be resolved.
> 

 <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 alexander.matveev at oracle.com  Thu Oct 10 03:50:08 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 9 Oct 2019 20:50:08 -0700
Subject: RFR: JDK-8232042: [macos] Installation fails if application name
 contains spaces
Message-ID: <fa524acd-d445-4b01-8099-f164ec60b07e@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Patch is based on JDK-8231856 fix.
- Fixed by using URI to escape URLs. URLEncoder.encode() encodes form 
data and it will use "+" for space. pkg build tool expects URL with 
space encoded as "%20".

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

[2] http://cr.openjdk.java.net/~almatvee/8232042/webrev.01/

Thanks,
Alexander

From mandy.chung at oracle.com  Thu Oct 10 05:00:48 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 9 Oct 2019 22:00:48 -0700
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <fbec6c6d-2324-ec0d-9440-ed42fa7d4304@azul.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
 <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
 <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>
 <fbec6c6d-2324-ec0d-9440-ed42fa7d4304@azul.com>
Message-ID: <1231b609-87c1-a500-5c8a-f9c144d632c3@oracle.com>



On 10/9/19 9:24 AM, Anton Kozlov wrote:
> Updated webrev with fixes:
> http://cr.openjdk.java.net/~akozlov/8231584/webrev.03/

I like this version.? Some minor comments:

2014 static synchronized void initLibraryPaths() { This does not need 
synchronized since it's still during phase 1 before other thread can 
execute java code.


LoadLibraryTest.java
- please add @bug 8231584
- there are places silently catching the checked exception
   e.g. line 62, 97, 117, 140, 157.  I suggest throw an unchecked
   exception instead to help diagnosis in case the test fails.

  121             return defineClass(null, b, 0, b.length);

- it should pass name instead of null
- in fact, TestClassLoader only needs to delegate the parent classloader
   as it doesn't have any .class to find.  So no need to override findClass.


Thanks
Mandy


From andrew_m_leonard at uk.ibm.com  Thu Oct 10 12:32:50 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Thu, 10 Oct 2019 13:32:50 +0100
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <e7ba1cc7-1ec0-4f7b-28a3-985a0c477637@oracle.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
 <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
 <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>
 <4009de21-61a9-7fd3-ef36-cc2a85cf71a2@oracle.com>
 <OF27010847.17D92AA7-ON0025848C.005707C7-8025848C.00572EC8@notes.na.collabserv.com>
 <e7ba1cc7-1ec0-4f7b-28a3-985a0c477637@oracle.com>
Message-ID: <OF908CECEE.B2E8E12F-ON0025848F.0044A719-8025848F.0044EA31@notes.na.collabserv.com>

Hi Roger,
I've updated the webrev here : 
http://cr.openjdk.java.net/~aleonard/8231717/webrev.02/
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:   Roger Riggs <Roger.Riggs at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
Cc:     Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad 
<claes.redestad at oracle.com>, core-libs-dev at openjdk.java.net
Date:   07/10/2019 17:11
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS



ok, I'll sponsor, update the webrev and I'll pick up the changeset from 
there.

Roger

On 10/7/19 11:52 AM, Andrew Leonard wrote:
Thanks Roger, 

Yes, agree some comment to be explicit about it being the LATIN1 String 
coding would be good. 
Are you ok to sponsor please? since Claes and Alan have reviewed. 

Cheers 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:        Roger Riggs <Roger.Riggs at oracle.com> 
To:        Andrew Leonard <andrew_m_leonard at uk.ibm.com> 
Cc:        Claes Redestad <claes.redestad at oracle.com>, 
core-libs-dev at openjdk.java.net, Alan Bateman <Alan.Bateman at oracle.com> 
Date:        07/10/2019 16:43 
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS 



Hi Andrew,

I'm fine with isLatin1Decodable/LATIN1DECODABLE.

To avoid confusion with "Latin-1", aka ISO-8859-1 the character set, 
in prose, there may be an opportunity to reinforce that it refers to the 
compact LATIN1 String coding.  Perhaps in ArrayDecoder.

I don't need to see another webrev. 

Thanks, Roger


On 10/7/19 10:29 AM, Andrew Leonard wrote: 
Thanks for the feedback, so we just need to decide on the variable name.. 
I am leaning towards isLatin1Decodable since it is closer to implying the 
charset is decodable to Latin1 via the decodeToLatin1() method, whereas 
isLatin1Compatible sort of implies it is "compatible" and decodable in 
certain circumstances like ASCIICompatible is, which is not the case here. 
So Roger, you ok with isLatin1Decodable/LATIN1DECODABLE ? 

Cheers 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 




From:        Claes Redestad <claes.redestad at oracle.com> 
To:        Roger Riggs <Roger.Riggs at oracle.com>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com> 
Cc:        core-libs-dev at openjdk.java.net 
Date:        07/10/2019 13:07 
Subject:        Re: RFR: 8231717: Improve performance of EBCDIC charset 
decoding for COMPACT_STRINGS 



On 2019-10-04 21:55, Roger Riggs wrote:
> Can you change the name to LATIN1COMPATIBLE?
> Its similar to the ASCIICOMPATIBLE case and tied in to the Latin1 coding 

> for used in StringCoding.

To me, compatible has a specific meaning that's not really the case
here. Perhaps isLatin1Decodable/LATIN1DECODABLE would roll better of the
tongue? This would also align nicely with the decodeToLatin1 method.

Patch looks good to me as-is, though.

Thanks!

/Claes




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From maurizio.cimadamore at oracle.com  Thu Oct 10 15:54:21 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 10 Oct 2019 16:54:21 +0100
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
Message-ID: <d5ddcfbc-4c54-3c8e-d1b0-c20024bdce39@oracle.com>

The javac changes looks good.

I guess I would have preferred to move the check for preview from Check 
to Preview, and also create a tighter integration between 
PreviewFeature.Feature and javac's Feature enum, so that we could 
generate tight error messages, but I guess we can also do that as a 
followup.

Maurizio

On 03/10/2019 10:57, Jan Lahoda wrote:
> Hi,
>
> This is a continuation of Joe's patch from here:
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>
>
> APIs associated with preview features are split into two groups: 
> essential and non-essential. These are marked with an JDK-internal 
> annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
> javac follows the PreviewFeature annotation, and produces either 
> warnings or errors for the usages of such APIs. For the @preview tag, 
> there is a taglet in the JDK build that adds the content of the tag 
> into the documentation. The first part of the @preview's text goes 
> into the summary, the second part goes into the detailed description.
>
> For build, a tricky problem is that the jdk.compiler module uses the 
> PreviewFeature annotation as well, but that is not in the bootstrap 
> JDK. So, for the intermediate langtools build, the PreviewFeature 
> annotation is copied from java.base.
>
> Proposed webrev:
> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>
> Javadoc with the change:
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>
> See for example:
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>
> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8226585
>
> CSR:
> https://bugs.openjdk.java.net/browse/JDK-8231411
>
> Feedback is welcome!
>
> Thanks,
> ??? Jan

From akozlov at azul.com  Thu Oct 10 16:54:02 2019
From: akozlov at azul.com (Anton Kozlov)
Date: Thu, 10 Oct 2019 19:54:02 +0300
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <1231b609-87c1-a500-5c8a-f9c144d632c3@oracle.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
 <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
 <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>
 <fbec6c6d-2324-ec0d-9440-ed42fa7d4304@azul.com>
 <1231b609-87c1-a500-5c8a-f9c144d632c3@oracle.com>
Message-ID: <8daaa4b6-4b86-ec77-0a29-79bfacf7c4f4@azul.com>

Hi Mandy,

On 10.10.2019 08:00, Mandy Chung wrote:
> 2014 static synchronized void initLibraryPaths() { 
> This does not need synchronized since it's still during phase 1 before other thread can execute java code.

Thanks! I missed this

> LoadLibraryTest.java
> - please add @bug 8231584
> - there are places silently catching the checked exception 
>   e.g. line 62, 97, 117, 140, 157.  I suggest throw an unchecked
>   exception instead to help diagnosis in case the test fails.
> 
>  121             return defineClass(null, b, 0, b.length);
> 
> - it should pass name instead of null
> - in fact, TestClassLoader only needs to delegate the parent classloader
>   as it doesn't have any .class to find.  So no need to override findClass.

-- fixed as well

Updated review is:

http://cr.openjdk.java.net/~akozlov/8231584/webrev.04/

Thanks,
Anton


From andy.herrick at oracle.com  Thu Oct 10 17:14:20 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 10 Oct 2019 13:14:20 -0400
Subject: RFR: JDK-8232042: [macos] Installation fails if application name
 contains spaces
In-Reply-To: <fa524acd-d445-4b01-8099-f164ec60b07e@oracle.com>
References: <fa524acd-d445-4b01-8099-f164ec60b07e@oracle.com>
Message-ID: <de8a84f9-e113-bb23-1e29-4f46d8f7eec9@oracle.com>

looks OK.

/Andy

On 10/9/2019 11:50 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Patch is based on JDK-8231856 fix.
> - Fixed by using URI to escape URLs. URLEncoder.encode() encodes form 
> data and it will use "+" for space. pkg build tool expects URL with 
> space encoded as "%20".
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232042
>
> [2] http://cr.openjdk.java.net/~almatvee/8232042/webrev.01/
>
> Thanks,
> Alexander

From sverre.moe at gmail.com  Thu Oct 10 17:46:55 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Thu, 10 Oct 2019 19:46:55 +0200
Subject: JEP-343: jpackage Windows installer localization
Message-ID: <CALAJ+5A3TGNWdR-WcgkEgCovNhMrWc8Nwky60crSWCG1-UzAJg@mail.gmail.com>

It should be possible to provide localized strings to the Windows installer
with jpackage.

WiX supports building localized installers through the use of language
files that include localized strings.
https://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/make_installer_localizable.html

There are three localization resources for Windows in jpackage.
Though there is only one String in those three localization files,
"message.install.dir.exist", all in English and there are more Strings in
English in the main.wxs file that are not localized.
MsiInstallerStrings_en.wxl
MsiInstallerStrings_ja.wxl
MsiInstallerStrings_zh_CN.wxl

These could be customized by providing an application_en.wxl or
application_es.wxl, or any other language to the resource directory.
Perhaps also allow for further customization by providing an
application.wxs to the resource directory to use instead of the main.wxs.

/Sverre

From alexey.semenyuk at oracle.com  Thu Oct 10 18:42:54 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 10 Oct 2019 14:42:54 -0400
Subject: RFR: JDK-8232042: [macos] Installation fails if application name
 contains spaces
In-Reply-To: <fa524acd-d445-4b01-8099-f164ec60b07e@oracle.com>
References: <fa524acd-d445-4b01-8099-f164ec60b07e@oracle.com>
Message-ID: <3193b368-a01d-7665-2834-7fe6c7071597@oracle.com>

Looks good.

It would be good to have this fix accompanied with the relevant jtreg test.

- Alexey

On 10/9/2019 11:50 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Patch is based on JDK-8231856 fix.
> - Fixed by using URI to escape URLs. URLEncoder.encode() encodes form 
> data and it will use "+" for space. pkg build tool expects URL with 
> space encoded as "%20".
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232042
>
> [2] http://cr.openjdk.java.net/~almatvee/8232042/webrev.01/
>
> Thanks,
> Alexander


From alexey.semenyuk at oracle.com  Thu Oct 10 18:52:23 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 10 Oct 2019 14:52:23 -0400
Subject: JEP-343: jpackage Windows installer localization
In-Reply-To: <CALAJ+5A3TGNWdR-WcgkEgCovNhMrWc8Nwky60crSWCG1-UzAJg@mail.gmail.com>
References: <CALAJ+5A3TGNWdR-WcgkEgCovNhMrWc8Nwky60crSWCG1-UzAJg@mail.gmail.com>
Message-ID: <f472bb77-c09c-6bb4-c2df-aaf058ddfff8@oracle.com>

Sverre,

I've captured your input in [1]. Currently Windows installers are not 
localized. We just have sources structured to support localization.
This is a major effort to implement if multiple languages in msi 
installers generated by jpackage are required.

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

- Alexey

On 10/10/2019 1:46 PM, Sverre Moe wrote:
> It should be possible to provide localized strings to the Windows installer
> with jpackage.
>
> WiX supports building localized installers through the use of language
> files that include localized strings.
> https://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/make_installer_localizable.html
>
> There are three localization resources for Windows in jpackage.
> Though there is only one String in those three localization files,
> "message.install.dir.exist", all in English and there are more Strings in
> English in the main.wxs file that are not localized.
> MsiInstallerStrings_en.wxl
> MsiInstallerStrings_ja.wxl
> MsiInstallerStrings_zh_CN.wxl
>
> These could be customized by providing an application_en.wxl or
> application_es.wxl, or any other language to the resource directory.
> Perhaps also allow for further customization by providing an
> application.wxs to the resource directory to use instead of the main.wxs.
>
> /Sverre


From mandy.chung at oracle.com  Thu Oct 10 21:28:13 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 10 Oct 2019 14:28:13 -0700
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <8daaa4b6-4b86-ec77-0a29-79bfacf7c4f4@azul.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
 <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
 <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>
 <fbec6c6d-2324-ec0d-9440-ed42fa7d4304@azul.com>
 <1231b609-87c1-a500-5c8a-f9c144d632c3@oracle.com>
 <8daaa4b6-4b86-ec77-0a29-79bfacf7c4f4@azul.com>
Message-ID: <02b9e306-9d72-810d-feec-2255b3d691b3@oracle.com>

On 10/10/19 9:54 AM, Anton Kozlov wrote:
> Updated review is:
>
> http://cr.openjdk.java.net/~akozlov/8231584/webrev.04/

Nit:

  112         try {
  113             loader = new TestClassLoader();
  114         } catch (MalformedURLException e) {
  115             throw new RuntimeException(e);
  116         }

Since the method throws Exception, this try-catch block is not needed.

The start year of the copyright in the new test files should be 2019.
Otherwise, looks good.

Is there anyone sponsoring this patch for you?  If not, I can do that.

thanks
Mandy


From philipp.kunz at paratix.ch  Fri Oct 11 06:11:24 2019
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Fri, 11 Oct 2019 08:11:24 +0200
Subject: Jar manifest and EOF
Message-ID: <9930f76c594c2feee98d6be5db73265536f9861a.camel@paratix.ch>

Hi,

The Jar File Specification [1] states that,

> If the last character of the file is an EOF character (code 26), the
EOF is treated as whitespace. Two newlines are appended (one for
editors that don't put a newline at the end of the last line, and one
so that the grammar doesn't have to special-case the last entry, which
may not have a blank line after it).

But I can't see that this is actually the case. See the attached simple
test that indicates that this statement is not implemented.

See also potentially remotely related bugs [2] and [3] which both refer
in my opinion to EOF as the end of the byte stream as opposed to the
EOF character 26.

After nobody has fixed this point inside of many years I tend to assume
that it is not at all necessary or useful. However, I cannot understand
the intention behind it or how that statement got there in the first
place and hence might not be aware of the full context.

Considering the activity about the last line of a manifest not
terminated by a line break resulting in that line ignored unexpectedly 
(see [3] through [14]) I doubt that it is promising to attempt to
implement the EOF according to the specs.

Instead I'd rather like to propose to update the specification by
removing the quoted statement.

I'm not sure if the specification [1] has changed since 13 or where the
most up to date one is.

Regards,
Philipp



[1] 
https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files

EOF-related:
[2] https://bugs.openjdk.java.net/browse/JDK-7148584
[3] https://bugs.openjdk.java.net/browse/JDK-4639129

Last line break required or missing related:
[4] https://bugs.openjdk.java.net/browse/JDK-4274235
[5] https://bugs.openjdk.java.net/browse/JDK-4894998
[6] https://bugs.openjdk.java.net/browse/JDK-4333854
[7] https://bugs.openjdk.java.net/browse/JDK-6594305
[8] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html
[9] https://bugs.openjdk.java.net/browse/JDK-4489716
[10] https://bugs.openjdk.java.net/browse/JDK-4639129
[11] https://bugs.openjdk.java.net/browse/JDK-4625822
[12] 
https://stackoverflow.com/questions/21859417/header-must-be-terminated-by-a-line-break-eclipse-manifest-mf
[13] https://bugs.eclipse.org/bugs/show_bug.cgi?id=377249
[14] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4274235

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20191011-manifest-eof.patch
Type: text/x-patch
Size: 1994 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20191011/fad01cb0/20191011-manifest-eof.patch>

From akozlov at azul.com  Fri Oct 11 09:35:18 2019
From: akozlov at azul.com (Anton Kozlov)
Date: Fri, 11 Oct 2019 12:35:18 +0300
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <02b9e306-9d72-810d-feec-2255b3d691b3@oracle.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
 <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
 <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>
 <fbec6c6d-2324-ec0d-9440-ed42fa7d4304@azul.com>
 <1231b609-87c1-a500-5c8a-f9c144d632c3@oracle.com>
 <8daaa4b6-4b86-ec77-0a29-79bfacf7c4f4@azul.com>
 <02b9e306-9d72-810d-feec-2255b3d691b3@oracle.com>
Message-ID: <228cd94c-3d2b-8f45-3f32-ee3b3c32ee61@azul.com>


On 11.10.2019 00:28, Mandy Chung wrote:
> Since the method throws Exception, this try-catch block is not needed.
> 
> The start year of the copyright in the new test files should be 2019.

Thanks! I preserved Amazon's copyright year as 2018, as I derived the file from JDK-8194653 initially ([1])

[1]: https://bugs.openjdk.java.net/secure/attachment/79869/JDK-8194653-Deadlock-involving-FileSystems.patch

> Otherwise, looks good.
> Is there anyone sponsoring this patch for you?  If not, I can do that.

Not yet. It would be great if you sponsor the patch.

Updated webrev: http://cr.openjdk.java.net/~akozlov/8231584/webrev.05/

Thanks,
Anton


From OGATAK at jp.ibm.com  Fri Oct 11 10:07:53 2019
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Fri, 11 Oct 2019 19:07:53 +0900
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <e712ff32-2e4c-d4fb-031b-17665e840fd7@oracle.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <d178e194-0a05-b0fe-865f-f930d560bf4f@oracle.com>
 <e712ff32-2e4c-d4fb-031b-17665e840fd7@oracle.com>
Message-ID: <OFCE648696.10EF03A7-ON49258490.00375BB1-49258490.0037A7C1@notes.na.collabserv.com>

Hi Mandy,

Thank you for review.

I'll keep the constructor package-private, as the change will be 
non-trivial when I fix the code based on the Peter's comment.

Regards,
Ogata

Mandy Chung <mandy.chung at oracle.com> wrote on 2019/10/09 04:24:35:

> From: Mandy Chung <mandy.chung at oracle.com>
> To: Claes Redestad <claes.redestad at oracle.com>, Kazunori Ogata 
<OGATAK at jp.ibm.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 2019/10/09 04:24
> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of 
> Method.copy() and leafCopy()
> 
> 
> 
> On 10/8/19 6:31 AM, Claes Redestad wrote:
> > Hi,
> >
> > webrev.02 looks good to me.
> >
> 
> webrev.02 looks fine to me as well.
> 
> > I think the performance results makes sense since avoiding a volatile
> > store (and the potentially expensive store barriers this involves)
> > should be the main benefit. Adding a branch to avoid storing null 
would
> > help partially, but not hot Methods.
> >
> > Pre-existing issue, but it's somewhat weird that we have two 
assignments
> > outside the package-private constructor: adding root and 
methodAccessor
> > to the constructor would make more immediate sense to me, since we do
> > the same thing at the only two callsites:
> >
> >         Method res = new Method(clazz, name, parameterTypes, 
returnType,
> >                 exceptionTypes, modifiers, slot, signature,
> >                 annotations, parameterAnnotations, annotationDefault);
> >         res.root = root;
> >         res.methodAccessor = methodAccessor;
> >
> > ->
> >
> >         Method res = new Method(clazz, name, parameterTypes, 
returnType,
> >                 exceptionTypes, modifiers, slot, signature,
> >                 annotations, parameterAnnotations, annotationDefault,
> >                 root, methodAccessor);
> >
> > This package-private constructor could also be made private. My guess 
is
> > there was some time when this was used from outside Method and 
changing
> > it was deemed unsavory..
> 
> The parameters of the Method constructor are the content from a 
> ClassFile to represent a method whereas root and methodAccessor fields 
> are not part of it. The current implementation allocates a Method 
> instance and sets the fields individually instead of calling the 
> constructor probably due to bootstrapping.
> 
> I suggest to keep it as it is.  OTOH making the constructor private is 
fine.
> 
> Mandy
> 



From OGATAK at jp.ibm.com  Fri Oct 11 10:17:26 2019
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Fri, 11 Oct 2019 19:17:26 +0900
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <14b28640-cd16-c672-c4bb-754116e882da@gmail.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <14b28640-cd16-c672-c4bb-754116e882da@gmail.com>
Message-ID: <OF700BE5C9.50229F68-ON49258490.0037CB9A-49258490.00388773@notes.na.collabserv.com>

Hi Peter,

Thank you for the comment and suggestion of the fix.

I tried to pick up your change w.r.t. methodAccessor:
https://cr.openjdk.java.net/~ogatak/8229871/webrev.04/


Regarding micro benchmark, my original motivation of this change is to 
improve performance of Class.getMethods(), which calls Method.copy() for 
each declared method to create a copy of Method[].

I measured my simple microbench: 
https://cr.openjdk.java.net/~ogatak/8229871/GetMethodsBench.java

Base code: Elapsed time = 4808 ms
webrev.01: Elapsed time = 4536 ms  (+   6%)
webrev.02: Elapsed time = 2331 ms  (+106%)
webrev.04: Elapsed time = 3746 ms  (+ 28%)

I'll measure larger benchmark and try to think if we can reduce the 
overhead of memory barrier.


Regards,
Ogata


Peter Levart <peter.levart at gmail.com> wrote on 2019/10/09 16:44:13:

> From: Peter Levart <peter.levart at gmail.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, core-libs-dev at openjdk.java.net
> Date: 2019/10/09 16:44
> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of 
> Method.copy() and leafCopy()
> 
> Hi Ogata,
> 
> May I just add that volatile field ensured that MethodAccessor object 
was 
> correctly published. DelegatingMethodAccessortImpl is not safe to be 
> published via data race because it contains plain `delegate` field 
> initialized in the constructor. In addition, the object that is first 
> assigned to that field is NativeMethodAccessorImpl which has plain 
> `parent` field. You can get NPE when invoking the Method.invoke from 
> multuiple threads if Method.methodAccessor is not volatile.
> 
> In addition, It would be nice to have two microbenchmarks exercising:
> a) Method copy performance
> b) Method invocation performance
> 
> Regards, Peter
> 
> P.S. When exploring the possibility of an alternative MethodAccessor 
> implementation (using MethodHandle(s)):
> 
> 
http://cr.openjdk.java.net/~plevart/jdk-dev/6824466_MHReflectionAccessors/
> webrev.00.2/
> 
> ...I found out that it was possible to re-arrange the play between 
> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and generated 
> MethodAccessor in such a way that the DelegatingMethodAccessortImpl 
> becomes safe to be published via data race. This allowed for 
> Method.methodAccessor field to become plain field. In addition this 
field 
> can be made @Stable which further optimizes access to MethodAccessor 
> instance when Method instance can be constant-folded, which showed in 
> special microbenchmarks.
> 
> So perhaps you could try to use above implementation (just changes to 
> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and part of 
> Reflection factory but without MH* stuff) and measure it against current 

> and your implementation (which as shown above has a data-race flaw).

> On 10/8/19 12:23 PM, Kazunori Ogata wrote:
> Hi all,
> 
> I posted two changes and got reply that performance evaluation is 
needed. 
> I found that making Method.methodAccessor non-volatile (webrev.02) is 
> better than avoid copying methodAccessor value when it is null 
> (webrev.01), as shown below.
> 
> So I'd like to ask review of the former change.  I updated weberv using 
> the latest code base (though there was no difference from webrev.02):
> 
> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.03/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
> 
> 
> For this performance evaluation, I calculated 75 percentile of 9 runs of 

> SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers.  I 
> bound a JVM to a NUMA node and set the number of GC threads to the same 
as 
> the number of physical cores.  These tuning reduced run-to-run 
fluctuation 
> on POWER (as usual...).
> 
> SPECjbb2015:
>   webrev.02:  critical jOPS +1.6%, max jOPS +0.2%
>   webrev.01:  critical jOPS +0.4%, max jOPS +0.2%
> 
> 
> For DaCapo, some benchmark still improved performance and some degraded, 

> but the geometric mean of all benchmarks were small:
>   weberv.02: +0.3%
>   weberv.01: +0.2%
> 
> The difference of improvement/degradation between the two changes in 
each 
> benchmark were less than 0.8%.
> 
> The range of improvement/degradation in each benchmark were:
>   webrev.02: between +2.4% and -1.0%
>   webrev.01: between +1.6% and -1.8%
> 
> 
> So I think webrev.02 (i.e., making methodAccessor non-volatile) is a 
good 
> change, since it improved SPECjbb critical jOPS by 1.6%.
> 
> 
> Regards,
> Ogata
> 
> 
> Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39:
> 

> From: Kazunori Ogata/Japan/IBM
> To: Mandy Chung <mandy.chung at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 2019/08/27 15:41
> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() and 

> leafCopy()

> 
> Hi Mandy,
> 
> Let me post interim results of the performance evaluation, though I'm 
> still measuring benchmarks and analyzing them.
> 
> For SPECjbb2015, skipping storing null (webrev.01) was faster than 

> making 

> methodAccessor non-volatile (webrev.02).  The improvements of each of 

> the 

> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%, 
> respectively.  This is only an average of six runs.
> 
> For DaCapo, the results were mixed.  In some benchmark, both of the 
> changes degraded performance.  In some others, webrev.01 was better, but 


> 

> weberv.02 was better in some others.
> 
> I'll continue evaluation, but it is helpful if you could give me some 
> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015.
> 
> Regards,
> Ogata
> 
> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41:
> 

> From: Kazunori Ogata/Japan/IBM
> To: Mandy Chung <mandy.chung at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 2019/08/21 20:02
> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() 

> and leafCopy()

> 
> Hi Mandy,
> 
> Thank you for reviewing the webrev.  I updated it to add a space after 

> 

> "if" and also put four spaces for indentation (it was three).
> 
> http://cr.openjdk.java.net/~ogatak/8229871/webrev.01/
> 
> Thank you so much for checking the history of fieldAccessor.  I was 
> surprised that fieldAccessor was made non-volatile in JDK5, but 
> methodAccessor was left as volatile for 15 years after that...
> 
> I agree we need benchmark data.  My simple micro benchmark that 

> repeats 

> invoking Class.getMethods() improved performance by 70% when it made 

> non-

> volatile (as shown in the following webrev).  I'll try to run larger 
> benchmarks, such as SPECjbb2015, to see real impact.
> 
> http://cr.openjdk.java.net/~ogatak/8229871/webrev.02/
> 
> Regards,
> Ogata
> 
> Mandy Chung <mandy.chung at oracle.com> wrote on 2019/08/21 01:21:42:
> 

> From: Mandy Chung <mandy.chung at oracle.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 2019/08/21 01:21
> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of 
> Method.copy() and leafCopy()
> 
> Hi Ogata,
> 
> The patch looks okay.  Nit: please add a space between if and (.
> 
> About volatile methodAccessor field, I checked the history.  Both 
> fieldAccessor and methodAccessor were started as volatile and the 
> fieldAccessor declaration was updated due to JDK-5044412.   As you 
> observe, I think the methodAccessor field could be made 

> non-volatile. 

> OTOH that might impact when it's inflated to spin bytecode for this 
> method invocation.  I don't know how importance to keep its volatile 

> vs 

> non-volatile in practice without doing benchmarking/real application 

> 

> testing.
> 
> Mandy
> 
> On 8/19/19 2:51 AM, Kazunori Ogata wrote:

> Hi,
> 
> May I have review for "JDK-8229871: Imporve performance of 

> Method.copy()

> and leafCopy()"?
> 
> Method.copy() and leafCopy() creates a copy of a Method object 

> with

> sharing MethodAccessor object. Since the methodAccessor field is a
> volatile variable, copying this field needs memory fence to ensure 

> the

> field is visible to all threads on the weak memory platforms such 

> as POWER

> and ARM.
> 
> When the methodAccessor of the root object is null (i.e., not 

> initialized

> yet), we do not need to copy the null value because this field of 

> the

> copied object has been initialized to null in the constructor. We 

> can

> reduce overhead of the memory fence only when the root's 

> methodAccessor is

> non-null. This change improved performance by 5.8% using a micro 

> benchmark

> that repeatedly invokes Class.getMethods().
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
> 
> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.00/
> 
> 
> By the way, why Method.methodAccessor is volatile, while
> Field.fieldAccessor and Field.overrideFieldAccessor are not 

> volatile?  I

> know the use of volatile reduces probability of creating 

> duplicated method

> accessor, but the chance still exists.  I couldn't find the 

> difference

> between Method and Field classes to make Method.methodAccessor 

> volatile.

> If we can make it non-volatile, it is more preferable than a quick 

> hack

> above.
> 
> 
> Regards,
> Ogata
> 

> 
> 

> 
> 



From Roger.Riggs at oracle.com  Fri Oct 11 14:38:32 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 11 Oct 2019 10:38:32 -0400
Subject: RFR [14] 8231297: java/lang/ProcessBuilder/Basic.java test fails
 intermittently
Message-ID: <0b949c3f-c896-5d4e-9de4-9a417dd2c2b5@oracle.com>

Please review this addition to a test to add diagnostic output.
There have been intermittent failures of ProcessBuilder/Basic.java that 
indicate
some output is being received from the child.? There should be none.
The additional output will be added to the log file along with the failure.

Jira Issue for the diagnostics:
 ?https://bugs.openjdk.java.net/browse/JDK-8232135

Base issue:
8231297 java/lang/ProcessBuilder/Basic.java test fails intermittently [1]

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-basic-intermittent-8231297-1/

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

Thanks, Roger

From sgehwolf at redhat.com  Fri Oct 11 14:54:57 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 11 Oct 2019 16:54:57 +0200
Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not
 close resources when Exception occurs.
In-Reply-To: <CAJwKKmYO7GXWLRczueYcgDMD1h4-19WSLnme5V374CrouBFodg@mail.gmail.com>
References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com>
 <e604fecd80da0f7bbd247861df7f6c4ae4ce2d8f.camel@redhat.com>
 <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com>
 <CAJwKKmYO7GXWLRczueYcgDMD1h4-19WSLnme5V374CrouBFodg@mail.gmail.com>
Message-ID: <71d543639ca7396711a8c04e78aa10ce5823c43f.camel@redhat.com>

On Fri, 2019-10-11 at 16:47 +0200, Mario Torre wrote:
> Hi Severin,
> 
> The patch looks good to me.

Thanks for the review, Mario!

Cheers,
Severin

> On Fri, Sep 27, 2019 at 10:38 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > Hi!
> > 
> > I'd appreciate a review of this one. Thanks in advance! See below.
> > 
> > On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote:
> > > On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Please review this 8u backport. The OpenJDK 11u patch does not apply
> > > > cleanly after path-reshuffeling due to a) test and code for jaxp are
> > > > split in JDK 8 b) Some rejects in comments - copyright and last
> > > > modified date. I've omitted rejected comments. I can manually add them
> > > > if that's preferred. See below.
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213734
> > > > webrevs:
> > > >   jdk:  http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/
> > > >   jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/
> > > > 
> > > > Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on
> > > >          Windows without the fix fails and passes with it.
> > > > 
> > > > Thanks to Simon Tooke who helped testing this patch on Windows.
> > > > 
> > > > Rejects:
> > > > $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej
> > > > --- XMLEntityManager.java
> > > > +++ XMLEntityManager.java
> > > > @@ -1,5 +1,5 @@
> > > >  /*
> > > > - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved.
> > > > + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved.
> > > >   */
> > > >  /*
> > > >   * Licensed to the Apache Software Foundation (ASF) under one or more
> > > > @@ -89,7 +89,7 @@
> > > >   * @author K.Venugopal SUN Microsystems
> > > >   * @author Neeraj Bajaj SUN Microsystems
> > > >   * @author Sunitha Reddy SUN Microsystems
> > > > - * @LastModified: Oct 2017
> > > > + * @LastModified: Nov 2018
> > > >   */
> > > >  public class XMLEntityManager implements XMLComponent, XMLEntityResolver {
> > > > 
> > > 
> > > Gentle reminder.
> > 
> > Anyone? It's been a month :(
> > 
> > FWIW, I've updated XMLEntityManager to include the copyright update
> > upper bound to 2018. The @LastModified lines don't exist in JDK 8u, so
> > I've omitted that. Latest webrevs:
> > 
> > webrevs:
> >    jdk:  http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/
> >    jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/02/webrev/
> > 
> > Thanks,
> > Severin
> > 
> 
> 


From Roger.Riggs at oracle.com  Fri Oct 11 15:12:37 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 11 Oct 2019 11:12:37 -0400
Subject: RFR 8231427 (test) Warning cleanup in tests of
 java.io.Serializable
In-Reply-To: <7d7389b0-b060-5e7f-4f0f-1f98b9cef872@oracle.com>
References: <63539469-c100-20c7-f22c-cac31265d03b@oracle.com>
 <7d7389b0-b060-5e7f-4f0f-1f98b9cef872@oracle.com>
Message-ID: <7394812a-fb69-0d6f-e021-f63bb721c167@oracle.com>

Hi Joe,

Updated with comments added for the reasons of the 
@SuppressWarnings("serial").

http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-3/

Thanks, Roger


On 9/27/19 2:45 PM, Joe Darcy wrote:
> Hi Roger,
>
> Generally looks fine. Adding some comments about why the 
> @SuppressWarnings annotations were being applied might help future 
> readers of the code.
>
> Cheers,
>
> -Joe
>
> On 9/27/2019 10:02 AM, Roger Riggs wrote:
>> Please review cleanup of tests in java/io/Serializable. There are 
>> warnings for mis-use of
>> serialization methods and fields; some are intentional as they are 
>> the focus of the tests.
>> The test code had quite a few warnings about raw types, deprecated 
>> methods, and
>> missing serialVersionUIDs, and deprecated methods, etc.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8231427
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-2/
>>
>> Thanks, Roger
>>


From Roger.Riggs at oracle.com  Fri Oct 11 15:23:24 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 11 Oct 2019 11:23:24 -0400
Subject: RFR: 8231717: Improve performance of EBCDIC charset decoding for
 COMPACT_STRINGS
In-Reply-To: <OF908CECEE.B2E8E12F-ON0025848F.0044A719-8025848F.0044EA31@notes.na.collabserv.com>
References: <OF271EDAF2.0E0A5D70-ON00258486.005D4D4A-80258487.002CF1AE@notes.na.collabserv.com>
 <0a7fa6e4-ae88-d9f1-125b-87be4a46f3f2@oracle.com>
 <OFF86C04D9.19E3A423-ON00258487.005B69C6-80258487.005CEC67@notes.na.collabserv.com>
 <c68f70b8-9f91-6e1d-877c-2213267a736b@oracle.com>
 <OFF4307A00.ACF6CA51-ON00258489.004798BF-80258489.0047F1F0@notes.na.collabserv.com>
 <f4773775-7958-4527-154c-d16e9a8432d9@oracle.com>
 <4e84313c-b700-4c5f-0391-70f663df3d9f@oracle.com>
 <OF1DA09D26.EC6FF1D1-ON0025848C.004F4636-8025848C.004FA3AE@notes.na.collabserv.com>
 <4009de21-61a9-7fd3-ef36-cc2a85cf71a2@oracle.com>
 <OF27010847.17D92AA7-ON0025848C.005707C7-8025848C.00572EC8@notes.na.collabserv.com>
 <e7ba1cc7-1ec0-4f7b-28a3-985a0c477637@oracle.com>
 <OF908CECEE.B2E8E12F-ON0025848F.0044A719-8025848F.0044EA31@notes.na.collabserv.com>
Message-ID: <7a416b07-afda-8776-c4a6-3a4f9551e3cc@oracle.com>

Pushed.

https://hg.openjdk.java.net/jdk/jdk/rev/3968bf3673c5

Many thanks Andrew!

On 10/10/19 8:32 AM, Andrew Leonard wrote:
> Hi Roger,
> I've updated the webrev here : 
> http://cr.openjdk.java.net/~aleonard/8231717/webrev.02/
> Thanks
> Andrew
>

From lance.andersen at oracle.com  Fri Oct 11 16:39:15 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 11 Oct 2019 12:39:15 -0400
Subject: RFR [14] 8231297: java/lang/ProcessBuilder/Basic.java test fails
 intermittently
In-Reply-To: <0b949c3f-c896-5d4e-9de4-9a417dd2c2b5@oracle.com>
References: <0b949c3f-c896-5d4e-9de4-9a417dd2c2b5@oracle.com>
Message-ID: <ED60D70D-881B-4DAF-A4E1-53469F02D632@oracle.com>

+1
> On Oct 11, 2019, at 10:38 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review this addition to a test to add diagnostic output.
> There have been intermittent failures of ProcessBuilder/Basic.java that indicate
> some output is being received from the child.  There should be none.
> The additional output will be added to the log file along with the failure.
> 
> Jira Issue for the diagnostics:
>  https://bugs.openjdk.java.net/browse/JDK-8232135
> 
> Base issue:
> 8231297 java/lang/ProcessBuilder/Basic.java test fails intermittently [1]
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-basic-intermittent-8231297-1/
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8231297
> 
> Thanks, Roger

 <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  Fri Oct 11 16:43:07 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 11 Oct 2019 12:43:07 -0400
Subject: RFR 8231427 (test) Warning cleanup in tests of
 java.io.Serializable
In-Reply-To: <7394812a-fb69-0d6f-e021-f63bb721c167@oracle.com>
References: <63539469-c100-20c7-f22c-cac31265d03b@oracle.com>
 <7d7389b0-b060-5e7f-4f0f-1f98b9cef872@oracle.com>
 <7394812a-fb69-0d6f-e021-f63bb721c167@oracle.com>
Message-ID: <13E439FE-568D-4CBD-A104-D78956235A7B@oracle.com>

Updates look good to me :-)

> On Oct 11, 2019, at 11:12 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Hi Joe,
> 
> Updated with comments added for the reasons of the @SuppressWarnings("serial").
> 
> http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-3/
> 
> Thanks, Roger
> 
> 
> On 9/27/19 2:45 PM, Joe Darcy wrote:
>> Hi Roger,
>> 
>> Generally looks fine. Adding some comments about why the @SuppressWarnings annotations were being applied might help future readers of the code.
>> 
>> Cheers,
>> 
>> -Joe
>> 
>> On 9/27/2019 10:02 AM, Roger Riggs wrote:
>>> Please review cleanup of tests in java/io/Serializable. There are warnings for mis-use of
>>> serialization methods and fields; some are intentional as they are the focus of the tests.
>>> The test code had quite a few warnings about raw types, deprecated methods, and
>>> missing serialVersionUIDs, and deprecated methods, etc.
>>> 
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8231427
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-2/
>>> 
>>> Thanks, Roger
>>> 
> 

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




From joe.darcy at oracle.com  Fri Oct 11 16:47:02 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 11 Oct 2019 09:47:02 -0700
Subject: RFR 8231427 (test) Warning cleanup in tests of
 java.io.Serializable
In-Reply-To: <7394812a-fb69-0d6f-e021-f63bb721c167@oracle.com>
References: <63539469-c100-20c7-f22c-cac31265d03b@oracle.com>
 <7d7389b0-b060-5e7f-4f0f-1f98b9cef872@oracle.com>
 <7394812a-fb69-0d6f-e021-f63bb721c167@oracle.com>
Message-ID: <5128bd64-da55-97fe-e69f-0654fba60366@oracle.com>

Looks good Roger; thanks,

-Joe

On 10/11/2019 8:12 AM, Roger Riggs wrote:
> Hi Joe,
>
> Updated with comments added for the reasons of the 
> @SuppressWarnings("serial").
>
> http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-3/
>
> Thanks, Roger
>
>
> On 9/27/19 2:45 PM, Joe Darcy wrote:
>> Hi Roger,
>>
>> Generally looks fine. Adding some comments about why the 
>> @SuppressWarnings annotations were being applied might help future 
>> readers of the code.
>>
>> Cheers,
>>
>> -Joe
>>
>> On 9/27/2019 10:02 AM, Roger Riggs wrote:
>>> Please review cleanup of tests in java/io/Serializable. There are 
>>> warnings for mis-use of
>>> serialization methods and fields; some are intentional as they are 
>>> the focus of the tests.
>>> The test code had quite a few warnings about raw types, deprecated 
>>> methods, and
>>> missing serialVersionUIDs, and deprecated methods, etc.
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8231427
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-2/
>>>
>>> Thanks, Roger
>>>
>

From Roger.Riggs at oracle.com  Fri Oct 11 17:35:58 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 11 Oct 2019 13:35:58 -0400
Subject: [14] RFR: 8225435: Upgrade IANA Language Subtag Registry to the
 latest for JDK14
In-Reply-To: <b86c7fa1-5c81-4d2f-3a4d-d6978216ceeb@oracle.com>
References: <b86c7fa1-5c81-4d2f-3a4d-d6978216ceeb@oracle.com>
Message-ID: <4368cb37-5b09-6cfa-b6c1-3d2ab6ff9044@oracle.com>

Hi Naoto,

Looks fine,

Roger


On 10/9/19 6:45 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8225435
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8225435/webrev.00/
>
> The change is to upgrade the data file to the latest (dated 
> 2019-09-16). A relevant test case is modified accordingly.
>
> Naoto


From Roger.Riggs at oracle.com  Fri Oct 11 17:41:47 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 11 Oct 2019 13:41:47 -0400
Subject: [14] RFR 8212749: DecimalFormat.setGroupingSize(int) allows
 setting negative grouping size, 8231984: Clarify semantics of
 DecimalFormat.getGroupingSize(0)
In-Reply-To: <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
 <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
Message-ID: <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>

Hi Naoto,

The javadoc/spec comments look fine.

Code comments at DecimalFormat:4035 give some latitute for the value to be
out of range and since getGroupingSize returns the groupingSize byte
it would be cleaner if the value was always in the valid range
regardless of the isGroupingUsed boolean.

Can there be code in the readObject method to correct out of range
values, perhaps to the default = 3?

Thanks, Roger



On 10/9/19 1:47 PM, naoto.sato at oracle.com wrote:
> I revised the fix, incorporating the clarification of the value zero 
> as the grouping size, which has separate JIRA issue and CSR as follows:
>
> https://bugs.openjdk.java.net/browse/JDK-8231984
> https://bugs.openjdk.java.net/browse/JDK-8232012
>
> The merged changeset is as follows:
>
> http://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.00/
>
> Please review.
>
> Naoto
>
> On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
>> Hi Roger,
>>
>> Thank you for the review. In fact, Joe commented about the validity 
>> of zero on the CSR, so I will need to modify the method description 
>> such as:
>>
>> diff -r 9576895d0f9a 
>> src/java.base/share/classes/java/text/DecimalFormat.java
>> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
>> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
>> @@ -2770,10 +2770,13 @@
>> ????? /**
>> ?????? * Set the grouping size. Grouping size is the number of digits 
>> between
>> ?????? * grouping separators in the integer portion of a number.? For 
>> example,
>> -???? * in the number "123,456.78", the grouping size is 3.
>> -???? * <br>
>> +???? * in the number "123,456.78", the grouping size is 3. Grouping 
>> size of
>> +???? * zero designates that grouping is not used, which provides the 
>> same
>> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
>> +???? * setGroupingUsed(false)}.
>> +???? * <p>
>> ?????? * The value passed in is converted to a byte, which may lose 
>> information.
>> -???? * Invalid value, i.e., negative or greater than
>> +???? * Values that are negative or greater than
>> ?????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will throw an
>> ?????? * {@code IllegalArgumentException}.
>> ?????? *
>>
>> I will file a follow-on CSR and merge changesets.
>>
>> Naoto
>>
>> On 10/8/19 6:59 AM, Roger Riggs wrote:
>>> Hi Naoto,
>>>
>>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".
>>>
>>> Otherwise looks fine. No need for another webrev.
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>>
>>>> The proposed CSR and changeset are located at:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>>
>>>> Naoto
>>>


From neugens at redhat.com  Fri Oct 11 14:47:25 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 11 Oct 2019 16:47:25 +0200
Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close
 resources when Exception occurs.
In-Reply-To: <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com>
References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com>
 <e604fecd80da0f7bbd247861df7f6c4ae4ce2d8f.camel@redhat.com>
 <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com>
Message-ID: <CAJwKKmYO7GXWLRczueYcgDMD1h4-19WSLnme5V374CrouBFodg@mail.gmail.com>

Hi Severin,

The patch looks good to me.

Cheers,
Mario

On Fri, Sep 27, 2019 at 10:38 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi!
>
> I'd appreciate a review of this one. Thanks in advance! See below.
>
> On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote:
> > On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote:
> > > Hi,
> > >
> > > Please review this 8u backport. The OpenJDK 11u patch does not apply
> > > cleanly after path-reshuffeling due to a) test and code for jaxp are
> > > split in JDK 8 b) Some rejects in comments - copyright and last
> > > modified date. I've omitted rejected comments. I can manually add them
> > > if that's preferred. See below.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213734
> > > webrevs:
> > >   jdk:  http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/
> > >   jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/
> > >
> > > Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on
> > >          Windows without the fix fails and passes with it.
> > >
> > > Thanks to Simon Tooke who helped testing this patch on Windows.
> > >
> > > Rejects:
> > > $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej
> > > --- XMLEntityManager.java
> > > +++ XMLEntityManager.java
> > > @@ -1,5 +1,5 @@
> > >  /*
> > > - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved.
> > > + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved.
> > >   */
> > >  /*
> > >   * Licensed to the Apache Software Foundation (ASF) under one or more
> > > @@ -89,7 +89,7 @@
> > >   * @author K.Venugopal SUN Microsystems
> > >   * @author Neeraj Bajaj SUN Microsystems
> > >   * @author Sunitha Reddy SUN Microsystems
> > > - * @LastModified: Oct 2017
> > > + * @LastModified: Nov 2018
> > >   */
> > >  public class XMLEntityManager implements XMLComponent, XMLEntityResolver {
> > >
> >
> > Gentle reminder.
>
> Anyone? It's been a month :(
>
> FWIW, I've updated XMLEntityManager to include the copyright update
> upper bound to 2018. The @LastModified lines don't exist in JDK 8u, so
> I've omitted that. Latest webrevs:
>
> webrevs:
>    jdk:  http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/
>    jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/02/webrev/
>
> Thanks,
> Severin
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From rachu.vmpp at gmail.com  Fri Oct 11 01:16:57 2019
From: rachu.vmpp at gmail.com (Rachu Vmpp)
Date: Fri, 11 Oct 2019 06:46:57 +0530
Subject: Apache Phoenix with OpenJDK
Message-ID: <CANyQWqaxcN7qZZ-mviOeeHVK7tpxnJXvbbrM08K-5miYJT21ow@mail.gmail.com>

Dear Fellas,

Is openJDK 11 compatible with Apache Phoenix?  I could  see some
PhoenixDialect unresolvable name error.

Can somebody help?

From ecki at zusammenkunft.net  Fri Oct 11 18:32:23 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 11 Oct 2019 18:32:23 +0000
Subject: Apache Phoenix with OpenJDK
In-Reply-To: <CANyQWqaxcN7qZZ-mviOeeHVK7tpxnJXvbbrM08K-5miYJT21ow@mail.gmail.com>
References: <CANyQWqaxcN7qZZ-mviOeeHVK7tpxnJXvbbrM08K-5miYJT21ow@mail.gmail.com>
Message-ID: <DB7PR08MB330740A67BE1E2F1F4427E77FF970@DB7PR08MB3307.eurprd08.prod.outlook.com>

Hello,

If you can?t find the needed information on the Project Website it is probably best to contact the project on the user mailing list.

https://phoenix.apache.org/mailing_list.html

You might want to give more information like which component is failing, what are the exact error logs and what are the versions of the associated products (like HBase).

Gruss
Bernd


--
http://bernd.eckenfels.net

________________________________
Von: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> im Auftrag von Rachu Vmpp <rachu.vmpp at gmail.com>
Gesendet: Freitag, Oktober 11, 2019 8:15 PM
An: core-libs-dev at openjdk.java.net
Betreff: Apache Phoenix with OpenJDK

Dear Fellas,

Is openJDK 11 compatible with Apache Phoenix? I could see some
PhoenixDialect unresolvable name error.

Can somebody help?

From andy.herrick at oracle.com  Fri Oct 11 18:53:43 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 11 Oct 2019 14:53:43 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
Message-ID: <fb6bb1bb-443d-e3c8-1d17-0ef7fe430c32@oracle.com>

Please review? changes for [1] which is the implementation bug for JEP-343.

The webrev at [2] is the total cumulative webrev of changes for the 
jpackage tool, currently in the JDK-8200758-branch branch of the open 
sandbox repository.

The webrev at [3] shows the changes since EA-06 (Build 13-jpackage+1-49 
) up to the current point.

The latest EA (Build 14-jpackage+1-49 ) is posted at [4].

Please send feedback to core-libs-dev at openjdk.java.net


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

[2] http://cr.openjdk.java.net/~herrick/jpackage/webrev.08/

[3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-08/

[4] http://jdk.java.net/jpackage/


/Andy


From naoto.sato at oracle.com  Fri Oct 11 20:15:48 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 11 Oct 2019 13:15:48 -0700
Subject: [14] RFR 8212749: DecimalFormat.setGroupingSize(int) allows
 setting negative grouping size, 8231984: Clarify semantics of
 DecimalFormat.getGroupingSize(0)
In-Reply-To: <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
 <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
 <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>
Message-ID: <33618d5c-7696-f3ba-2f78-590b0802504e@oracle.com>

Thanks, Roger. Modified readObject() accordingly:

https://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.01/

Naoto

On 10/11/19 10:41 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> The javadoc/spec comments look fine.
> 
> Code comments at DecimalFormat:4035 give some latitute for the value to be
> out of range and since getGroupingSize returns the groupingSize byte
> it would be cleaner if the value was always in the valid range
> regardless of the isGroupingUsed boolean.
> 
> Can there be code in the readObject method to correct out of range
> values, perhaps to the default = 3?
> 
> Thanks, Roger
> 
> 
> 
> On 10/9/19 1:47 PM, naoto.sato at oracle.com wrote:
>> I revised the fix, incorporating the clarification of the value zero 
>> as the grouping size, which has separate JIRA issue and CSR as follows:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8231984
>> https://bugs.openjdk.java.net/browse/JDK-8232012
>>
>> The merged changeset is as follows:
>>
>> http://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.00/
>>
>> Please review.
>>
>> Naoto
>>
>> On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
>>> Hi Roger,
>>>
>>> Thank you for the review. In fact, Joe commented about the validity 
>>> of zero on the CSR, so I will need to modify the method description 
>>> such as:
>>>
>>> diff -r 9576895d0f9a 
>>> src/java.base/share/classes/java/text/DecimalFormat.java
>>> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
>>> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
>>> @@ -2770,10 +2770,13 @@
>>> ????? /**
>>> ?????? * Set the grouping size. Grouping size is the number of digits 
>>> between
>>> ?????? * grouping separators in the integer portion of a number.? For 
>>> example,
>>> -???? * in the number "123,456.78", the grouping size is 3.
>>> -???? * <br>
>>> +???? * in the number "123,456.78", the grouping size is 3. Grouping 
>>> size of
>>> +???? * zero designates that grouping is not used, which provides the 
>>> same
>>> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
>>> +???? * setGroupingUsed(false)}.
>>> +???? * <p>
>>> ?????? * The value passed in is converted to a byte, which may lose 
>>> information.
>>> -???? * Invalid value, i.e., negative or greater than
>>> +???? * Values that are negative or greater than
>>> ?????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will throw an
>>> ?????? * {@code IllegalArgumentException}.
>>> ?????? *
>>>
>>> I will file a follow-on CSR and merge changesets.
>>>
>>> Naoto
>>>
>>> On 10/8/19 6:59 AM, Roger Riggs wrote:
>>>> Hi Naoto,
>>>>
>>>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".
>>>>
>>>> Otherwise looks fine. No need for another webrev.
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix to the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>>>
>>>>> The proposed CSR and changeset are located at:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>>>
>>>>> Naoto
>>>>
> 

From mandy.chung at oracle.com  Fri Oct 11 21:51:42 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 11 Oct 2019 14:51:42 -0700
Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and
 System.loadLibrary call
In-Reply-To: <228cd94c-3d2b-8f45-3f32-ee3b3c32ee61@azul.com>
References: <eb1f751f-2b6f-2bc1-ec7a-bb8155be7934@azul.com>
 <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com>
 <01ddb598-ee57-29f7-707a-059370843505@azul.com>
 <d7ba1087-cec7-73a5-8fbf-25c559a47f1d@oracle.com>
 <748a595c-ad8e-a6b2-7416-284a260f664d@azul.com>
 <b8652395-6311-9a1f-a5de-c333ed76da96@oracle.com>
 <fbec6c6d-2324-ec0d-9440-ed42fa7d4304@azul.com>
 <1231b609-87c1-a500-5c8a-f9c144d632c3@oracle.com>
 <8daaa4b6-4b86-ec77-0a29-79bfacf7c4f4@azul.com>
 <02b9e306-9d72-810d-feec-2255b3d691b3@oracle.com>
 <228cd94c-3d2b-8f45-3f32-ee3b3c32ee61@azul.com>
Message-ID: <aec99128-3cb3-135a-0875-4e45a3d76bc1@oracle.com>



On 10/11/19 2:35 AM, Anton Kozlov wrote:
> On 11.10.2019 00:28, Mandy Chung wrote:
>> Since the method throws Exception, this try-catch block is not needed.
>>
>> The start year of the copyright in the new test files should be 2019.
> Thanks! I preserved Amazon's copyright year as 2018, as I derived the file from JDK-8194653 initially ([1])
>
> [1]: https://bugs.openjdk.java.net/secure/attachment/79869/JDK-8194653-Deadlock-involving-FileSystems.patch

Ah, I see.
>> Otherwise, looks good.
>> Is there anyone sponsoring this patch for you?  If not, I can do that.
> Not yet. It would be great if you sponsor the patch.
>
> Updated webrev: http://cr.openjdk.java.net/~akozlov/8231584/webrev.05/
>
>

Pushed.

Mandy

From alexander.matveev at oracle.com  Sat Oct 12 03:34:34 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 11 Oct 2019 20:34:34 -0700
Subject: RFR: JDK-8231857: App and Application folder icons are not aligned
 correctly
Message-ID: <7c78f242-dda0-f6fc-92a3-3967a63350cb@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Not sure what problem was, but after moving hidden items at same Y 
value as non-hidden icons issue was resolved. Also, had to adjust Y 
value to align icons with background image. Now it works properly when 
hidden files enabled or disabled in Finder.

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

[2] http://cr.openjdk.java.net/~almatvee/8231857/webrev.00/

Thanks,
Alexander

From richard.d.evans at oracle.com  Sat Oct 12 11:48:13 2019
From: richard.d.evans at oracle.com (Richard Evans)
Date: Sat, 12 Oct 2019 12:48:13 +0100
Subject: jdk 14 jpackage preview feedback
Message-ID: <e29f3d0d-b7fe-03d3-9b04-0a9926c7be00@oracle.com>

Hi

I'm trying out jpackage from Build 14-jpackage+1-49.

I'm successfully creating an rpm for Fedora and it installs fine. 
However the erase fails with:

xdg-icon-resource: the icon size must be specified with --size
Try 'xdg-icon-resource --help' for more information.
error: %preun(edq-0.27-1.x86_64) scriptlet failed, exit status 1
error: edq-0.27-1.x86_64: erase failed

When I look in the /usr/share/icons/hicolor/ directory I see my icon 
under "0x0" so it looks like a size should be specified when the package 
is installed.? Do I need to add a size to the file associations 
properties file?

Thanks

Richard

-- 

Oracle <http://www.oracle.com>
Richard Evans | Product Architect
Phone: +441223228408 <tel:+441223228408> | Mobile: +447973839664 
<tel:+447973839664> | Video: richard.d.evans at oracle.com 
<sip:richard.d.evans at oracle.com>
Oracle Product Development
Park House Castle Park | Cambridge | CB3 0DU | United Kingdom

ORACLE Corporation UK Ltd is a company incorporated in England & Wales | 
Company Reg. No. 1782505 | Reg. office: Oracle Parkway, Thames Valley 
Park, Reading RG6 1RA
Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to 
developing practices and products that help protect the environment


From andy.herrick at oracle.com  Sat Oct 12 13:10:35 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Sat, 12 Oct 2019 09:10:35 -0400
Subject: RFR: JDK-8231857: App and Application folder icons are not
 aligned correctly
In-Reply-To: <7c78f242-dda0-f6fc-92a3-3967a63350cb@oracle.com>
References: <7c78f242-dda0-f6fc-92a3-3967a63350cb@oracle.com>
Message-ID: <2f7eed43-f6cf-7411-03e5-592229b99036@oracle.com>

looks ok.

/Andy


On 10/11/2019 11:34 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Not sure what problem was, but after moving hidden items at same Y 
> value as non-hidden icons issue was resolved. Also, had to adjust Y 
> value to align icons with background image. Now it works properly when 
> hidden files enabled or disabled in Finder.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231857
>
> [2] http://cr.openjdk.java.net/~almatvee/8231857/webrev.00/
>
> Thanks,
> Alexander

From alexey.semenyuk at oracle.com  Sat Oct 12 14:18:06 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Sat, 12 Oct 2019 10:18:06 -0400
Subject: RFR: JDK-8231857: App and Application folder icons are not
 aligned correctly
In-Reply-To: <7c78f242-dda0-f6fc-92a3-3967a63350cb@oracle.com>
References: <7c78f242-dda0-f6fc-92a3-3967a63350cb@oracle.com>
Message-ID: <4fc0f6c2-aedd-be85-d510-cc597d93e29d@oracle.com>

Looks good.

- Alexey

On 10/11/2019 11:34 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Not sure what problem was, but after moving hidden items at same Y 
> value as non-hidden icons issue was resolved. Also, had to adjust Y 
> value to align icons with background image. Now it works properly when 
> hidden files enabled or disabled in Finder.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231857
>
> [2] http://cr.openjdk.java.net/~almatvee/8231857/webrev.00/
>
> Thanks,
> Alexander


From amaembo at gmail.com  Sun Oct 13 09:51:44 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 13 Oct 2019 16:51:44 +0700
Subject: RFR(s): 8176894 Provide specialized implementation for default
 methods putIfAbsent, computeIfAbsent, computeIfPresent, compute,
 merge in TreeMap
Message-ID: <CAE+3fjasoCGcEj-nFqsYbnEcFoc1hWVgu-LAJGffo=8_PWSZ6Q@mail.gmail.com>

Hello!

Please review the updated patch (no sponsorship is necessary; review only):
https://cr.openjdk.java.net/~tvaleev/webrev/8176894/r3/
https://bugs.openjdk.java.net/browse/JDK-8176894

The difference from the previous version [1] is minimal: I just
noticed that the specification for computeIfAbsent should say
"mapping" instead of "remapping", so I fixed the spec. No changes in
code/tests.

Also please review the associated CSR:
https://bugs.openjdk.java.net/browse/JDK-8227666
I updated it, according to Joe Darcy's comments.

An additional explanation and background is copied below from my
original e-mail [2] for your convenience:

The patch was originally submitted by Sergey Kuksenko in March 2017 and
reviewed by some people:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046825.html
The latest patch submitted by Sergey is here:
http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.01/

I asked Sergey why it was abandoned. Seems there were no particular reason
and Sergey asked if I could pick up this work. I will be happy to finish it.

Here's the list of differences between the latest Sergey patch and my patch:
- A bug is fixed in putIfAbsent implementation. TreeMap.java, lines 576 and
596:  `|| oldValue == null` condition added (the null value should be
overwritten no matter what)
- A testcase is added to cover this problem (InPlaceOpsCollisions.java,
also checks HashMap and LinkedHashMap). Not sure if it's the best place for
such test though. Probably a separate file would be better?
- TreeMap.merge() implementation is added.
- TreeMap is added to the FunctionalCMEs.java test (btw this file copyright
says that it's a subject to Classpath exception which is probably wrong?)
- Simple microbenchmark is added: TreeMapUpdate.java

My quick benchmarking shows that optimized version is indeed faster for the
most of the tests and no regression is observed for put() method. Here's
raw results of jdk13-ea+26 and jdk13-ea+26+patch if anybody is interested.
http://cr.openjdk.java.net/~tvaleev/jmh/JDK-8176894/

With best regards,
Tagir Valeev.

[1] https://cr.openjdk.java.net/~tvaleev/webrev/8176894/r2/
[2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061309.html

From weijun.wang at oracle.com  Mon Oct 14 01:41:56 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 14 Oct 2019 09:41:56 +0800
Subject: Jar manifest and EOF
In-Reply-To: <9930f76c594c2feee98d6be5db73265536f9861a.camel@paratix.ch>
References: <9930f76c594c2feee98d6be5db73265536f9861a.camel@paratix.ch>
Message-ID: <7BF64E28-35AA-40A5-9093-0BF086BB51C1@oracle.com>

Hi Philipp,

Although I also think this feature might be useless, I feel hesitated to just remove it. How about implement it and let it stay useless? I assume this will not break any existing test or app if no one is actually using the character. Hopefully it's easy to implement.

On the other hand, if there is really a EOF char at the end, there will be a behavior change. If that EOF is at the end an attribute line, that line is ignored now, and it should be visible after the change and this looks like a good thing. If that EOF is after a newline, it will be useless anyway.

Also, my understanding is that hash/signature in a signed jar file are calculated on raw bytes and old signed jars can still be verified. We should take care to use the original raw bytes and not the result of Manifest::write, but I think your previous fixes in this area had already handled this correctly.

Just my $0.02.

Thanks,
Max

> On Oct 11, 2019, at 2:11 PM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
> 
> Hi,
> 
> The Jar File Specification [1] states that,
> 
>> If the last character of the file is an EOF character (code 26), the
> EOF is treated as whitespace. Two newlines are appended (one for
> editors that don't put a newline at the end of the last line, and one
> so that the grammar doesn't have to special-case the last entry, which
> may not have a blank line after it).
> 
> But I can't see that this is actually the case. See the attached simple
> test that indicates that this statement is not implemented.
> 
> See also potentially remotely related bugs [2] and [3] which both refer
> in my opinion to EOF as the end of the byte stream as opposed to the
> EOF character 26.
> 
> After nobody has fixed this point inside of many years I tend to assume
> that it is not at all necessary or useful. However, I cannot understand
> the intention behind it or how that statement got there in the first
> place and hence might not be aware of the full context.
> 
> Considering the activity about the last line of a manifest not
> terminated by a line break resulting in that line ignored unexpectedly 
> (see [3] through [14]) I doubt that it is promising to attempt to
> implement the EOF according to the specs.
> 
> Instead I'd rather like to propose to update the specification by
> removing the quoted statement.
> 
> I'm not sure if the specification [1] has changed since 13 or where the
> most up to date one is.
> 
> Regards,
> Philipp
> 
> 
> 
> [1] 
> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files
> 
> EOF-related:
> [2] https://bugs.openjdk.java.net/browse/JDK-7148584
> [3] https://bugs.openjdk.java.net/browse/JDK-4639129
> 
> Last line break required or missing related:
> [4] https://bugs.openjdk.java.net/browse/JDK-4274235
> [5] https://bugs.openjdk.java.net/browse/JDK-4894998
> [6] https://bugs.openjdk.java.net/browse/JDK-4333854
> [7] https://bugs.openjdk.java.net/browse/JDK-6594305
> [8] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html
> [9] https://bugs.openjdk.java.net/browse/JDK-4489716
> [10] https://bugs.openjdk.java.net/browse/JDK-4639129
> [11] https://bugs.openjdk.java.net/browse/JDK-4625822
> [12] 
> https://stackoverflow.com/questions/21859417/header-must-be-terminated-by-a-line-break-eclipse-manifest-mf
> [13] https://bugs.eclipse.org/bugs/show_bug.cgi?id=377249
> [14] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4274235
> 
> <20191011-manifest-eof.patch>


From goetz.lindenmaier at sap.com  Mon Oct 14 13:46:56 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 14 Oct 2019 13:46:56 +0000
Subject: RFR (L, final): 8218626: Add detailed message to
 NullPointerException describing what is null.
In-Reply-To: <20191002154045.380207158@eggemoggin.niobe.net>
References: <AM6PR02MB53475B0ECD6B83130AAF445BECB60@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB5347DB97B73443C3CF13438CEC8F0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <20191001152833.988974338@eggemoggin.niobe.net>
 <AM6PR02MB53472419205F89652DCB11D0EC9C0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <20191002154045.380207158@eggemoggin.niobe.net>
Message-ID: <AM6PR02MB5347686EA2E60C4A906A8FF9EC900@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi everybody, 

JEP 358 is targeted to jdk14. 
If there are no objections, I'll push this change tomorrow or 
on Wednesday.
I'll do one final pass of jdk/submit before pushing.

The final webrev:
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/21/

Best regards,
  Goetz.

> -----Original Message-----
> From: mark.reinhold at oracle.com <mark.reinhold at oracle.com>
> Sent: Donnerstag, 3. Oktober 2019 00:41
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: hotspot-runtime-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: RFR (L, final): 8218626: Add detailed message to
> NullPointerException describing what is null.
> 
> 2019/10/2 5:45:10 -0700, goetz.lindenmaier at sap.com:
> > thanks for looking at my change! Can I add you as reviewer?
> 
> Sure.
> 
> >> This is very nice work!  I especially appreciate the thorough tests.
> >
> > Thanks!  But adapting the many tests to changed messages is
> > quite cumbersome :) Thanks for supplying the patch right away!
> 
> Nothing that a little Emacs-fu can?t handle.
> 
> >> ...
> >>
> >> I also noticed that the generated messages use single quotes (?'?) to
> >> quote the names of fields, etc., rather than double quotes (?"?).
> >
> > I'm fine with this, but I think hotspot uses "'" for citing code
> > quite consistently. E.g., have a look at
> >
> http://hg.openjdk.java.net/jdk/jdk/file/b25362cec8ce/src/hotspot/share/inter
> preter/linkResolver.cpp
> > This can easily be changed.  I could do a separate change
> > for hotspot and change all uses of ' in exceptions to ". What
> > do you think?
> 
> I think that?d be a fine clean-up task, for later.
> 
> - Mark

From takiguc at linux.vnet.ibm.com  Mon Oct 14 15:53:59 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 15 Oct 2019 00:53:59 +0900
Subject: RFR: 8232161  Unexpected 1-way trip conversion entries on MS950
 charset
Message-ID: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/

I have a concern about 1-way trip conversion entries (4 entries) on 
MS950 charset.
The detail information is in JDK-8232161 [1]

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

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From mandy.chung at oracle.com  Mon Oct 14 22:34:48 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 14 Oct 2019 15:34:48 -0700
Subject: Review Request JDK-8173975: Lookup::in should not allow target class
 be primitive or array class
Message-ID: <0eca5816-68d6-33a7-9d34-7c9a78d0810a@oracle.com>

MethodHandles::lookup produces a Lookup object on the caller class. The 
original intention for a Lookup object whose lookup class is always a 
non-array and non-primitive class.

MethodHandles::privateLookupIn and Lookup::in are the two other ways 
that can produce a new Lookup object and they should disallow the new 
lookup class be a primitive or array class.

This patch proposes to make Lookup::in consistent with 
MethodHandles::privateLookupIn to throw IAE if the target class is an 
array type or primitive type.


CSR: https://bugs.openjdk.java.net/browse/JDK-8232227
webrev:
http://cr.openjdk.java.net/~mchung/jdk14/8173975/webrev.00/

thanks
Mandy

From joe.darcy at oracle.com  Tue Oct 15 00:32:57 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 14 Oct 2019 17:32:57 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
Message-ID: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>

Hello,

Expanding the serialization review to include the java.util.concurrent 
package, please review the proposed changes:

 ??? JDK-8232230: Suppress warnings on non-serializable non-transient 
instance fields in java.util.concurrent
 ??? http://cr.openjdk.java.net/~darcy/8232230.0/

Terminology added by? JDK-8231913: "Discuss serializability of 
collections" used where appropriate.

Thanks,

-Joe


From huaming.li at oracle.com  Tue Oct 15 02:03:12 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 15 Oct 2019 10:03:12 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
Message-ID: <9c362028-6992-4933-3081-7da7975fa410@oracle.com>

Hi,

The test is failing more frequently, could some help to review it?

Thank you

-Hamlin

On 2019/9/4 11:11 AM, Hamlin Li wrote:
> some background & comment: in most of failures, the 
> "test.timeout.factor" is 10.0 or 8.0, so in the test code this factor 
> should be considered in rmi operations such unexporting an object.
>
> Thank you
>
> -Hamlin
>
> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>> Hi,
>>
>> Would you please review the following patch?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>
>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>
>>
>> Thank you
>>
>> -Hamlin
>>

From huaming.li at oracle.com  Tue Oct 15 02:03:43 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 15 Oct 2019 10:03:43 +0800
Subject: RFR of JDK-8134599: Improve the code coverage for ThreadLocal
In-Reply-To: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com>
References: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com>
Message-ID: <cfea0a07-d378-5415-11c7-1140e43e97b2@oracle.com>

Could some help to review it?

Thank you

-Hamlin

On 2019/9/4 3:16 PM, Hamlin Li wrote:
> Would you please review the following patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8209824
>
> webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/
>
>
> Thank you
>
> -Hamlin
>

From weijun.wang at oracle.com  Tue Oct 15 02:20:34 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 15 Oct 2019 10:20:34 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
Message-ID: <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>

+SeanC

The wait might unnecessarily increase the test time. Maybe you can do something like this:

   int timeout = 10;
   while (timeout > 0) {
      sleep(one second);
      verifyPortFree && return;
      timeout--;
   }
   throw new Exception(still not freed);

And Sean, back in JDK-8016728 you said "Let's extend it to 1000ms and see how test behaves". So what do you think?

Thanks,
Max

> On Oct 15, 2019, at 10:03 AM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> Hi,
> 
> The test is failing more frequently, could some help to review it?
> 
> Thank you
> 
> -Hamlin
> 
> On 2019/9/4 11:11 AM, Hamlin Li wrote:
>> some background & comment: in most of failures, the "test.timeout.factor" is 10.0 or 8.0, so in the test code this factor should be considered in rmi operations such unexporting an object.
>> 
>> Thank you
>> 
>> -Hamlin
>> 
>> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>>> Hi,
>>> 
>>> Would you please review the following patch?
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>> 
>>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>> 
>>> 
>>> Thank you
>>> 
>>> -Hamlin
>>> 


From david.holmes at oracle.com  Tue Oct 15 02:29:23 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Oct 2019 12:29:23 +1000
Subject: RFR of JDK-8134599: Improve the code coverage for ThreadLocal
In-Reply-To: <cfea0a07-d378-5415-11c7-1140e43e97b2@oracle.com>
References: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com>
 <cfea0a07-d378-5415-11c7-1140e43e97b2@oracle.com>
Message-ID: <8bc32685-4b4f-320c-d147-7f55d50b1134@oracle.com>

Hi Hamlin,

On 15/10/2019 12:03 pm, Hamlin Li wrote:
> Could some help to review it?

Basic test seems okay but a few minor suggestions:

1. Please add a public summary to the bug report to convey the same 
information as:

27  * @summary per latest JDK code coverage report, 2 methods 
replaceStaleEntry
   28  *          and prevIndex in ThreadLocal.ThreadLocalMap is not touched
   29  *          by any JDK regression tests, this is to trigger the 
code path.

2. In that comment s/is not/are not/

3. Please add a brief comment to the code explaining how the test 
exercises the previously untested methods.

No need to see an updated webrev for the above.

Thanks,
David

> Thank you
> 
> -Hamlin
> 
> On 2019/9/4 3:16 PM, Hamlin Li wrote:
>> Would you please review the following patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8209824
>>
>> webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/
>>
>>
>> Thank you
>>
>> -Hamlin
>>

From joe.darcy at oracle.com  Tue Oct 15 02:43:37 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 14 Oct 2019 19:43:37 -0700
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
Message-ID: <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>

Hello,

Structurally, I'd prefer an approach that doesn't increase the minimum 
time needed to run the test.

Any timeout-like value used within the test code should be sensitive to 
the jtreg timeout factor, as done in the webrev.

Thanks,

-Joe

On 10/14/2019 7:20 PM, Weijun Wang wrote:
> +SeanC
>
> The wait might unnecessarily increase the test time. Maybe you can do something like this:
>
>     int timeout = 10;
>     while (timeout > 0) {
>        sleep(one second);
>        verifyPortFree && return;
>        timeout--;
>     }
>     throw new Exception(still not freed);
>
> And Sean, back in JDK-8016728 you said "Let's extend it to 1000ms and see how test behaves". So what do you think?
>
> Thanks,
> Max
>
>> On Oct 15, 2019, at 10:03 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>> Hi,
>>
>> The test is failing more frequently, could some help to review it?
>>
>> Thank you
>>
>> -Hamlin
>>
>> On 2019/9/4 11:11 AM, Hamlin Li wrote:
>>> some background & comment: in most of failures, the "test.timeout.factor" is 10.0 or 8.0, so in the test code this factor should be considered in rmi operations such unexporting an object.
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>>>> Hi,
>>>>
>>>> Would you please review the following patch?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>>>
>>>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>>>
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>

From huaming.li at oracle.com  Tue Oct 15 03:04:10 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 15 Oct 2019 11:04:10 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
Message-ID: <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>

Thanks for reviewing, I updated change at: 
http://cr.openjdk.java.net/~mli/8134599/webrev.01/

it does not increase minimum time time and consider timeout factor at 
the same time.

Thank you

-Hamlin

On 2019/10/15 10:43 AM, Joe Darcy wrote:
> Hello,
>
> Structurally, I'd prefer an approach that doesn't increase the minimum 
> time needed to run the test.
>
> Any timeout-like value used within the test code should be sensitive 
> to the jtreg timeout factor, as done in the webrev.
>
> Thanks,
>
> -Joe
>
> On 10/14/2019 7:20 PM, Weijun Wang wrote:
>> +SeanC
>>
>> The wait might unnecessarily increase the test time. Maybe you can do 
>> something like this:
>>
>> ??? int timeout = 10;
>> ??? while (timeout > 0) {
>> ?????? sleep(one second);
>> ?????? verifyPortFree && return;
>> ?????? timeout--;
>> ??? }
>> ??? throw new Exception(still not freed);
>>
>> And Sean, back in JDK-8016728 you said "Let's extend it to 1000ms and 
>> see how test behaves". So what do you think?
>>
>> Thanks,
>> Max
>>
>>> On Oct 15, 2019, at 10:03 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> The test is failing more frequently, could some help to review it?
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>> On 2019/9/4 11:11 AM, Hamlin Li wrote:
>>>> some background & comment: in most of failures, the 
>>>> "test.timeout.factor" is 10.0 or 8.0, so in the test code this 
>>>> factor should be considered in rmi operations such unexporting an 
>>>> object.
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>
>>>> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>>>>> Hi,
>>>>>
>>>>> Would you please review the following patch?
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> -Hamlin
>>>>>

From huaming.li at oracle.com  Tue Oct 15 03:07:31 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 15 Oct 2019 11:07:31 +0800
Subject: RFR of JDK-8209824: Improve the code coverage for ThreadLocal
In-Reply-To: <8bc32685-4b4f-320c-d147-7f55d50b1134@oracle.com>
References: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com>
 <cfea0a07-d378-5415-11c7-1140e43e97b2@oracle.com>
 <8bc32685-4b4f-320c-d147-7f55d50b1134@oracle.com>
Message-ID: <98de4d51-4443-ce24-93f2-d62c4080cbe1@oracle.com>

Thank you for reviewing David. I will update/push the change as you 
suggested.

BTW, sorry for the wrong bug number in email subject, it should be 8209824.

Thank you

-Hamlin

On 2019/10/15 10:29 AM, David Holmes wrote:
> Hi Hamlin,
>
> On 15/10/2019 12:03 pm, Hamlin Li wrote:
>> Could some help to review it?
>
> Basic test seems okay but a few minor suggestions:
>
> 1. Please add a public summary to the bug report to convey the same 
> information as:
>
> 27? * @summary per latest JDK code coverage report, 2 methods 
> replaceStaleEntry
> ? 28? *????????? and prevIndex in ThreadLocal.ThreadLocalMap is not 
> touched
> ? 29? *????????? by any JDK regression tests, this is to trigger the 
> code path.
>
> 2. In that comment s/is not/are not/
>
> 3. Please add a brief comment to the code explaining how the test 
> exercises the previously untested methods.
>
> No need to see an updated webrev for the above.
>
> Thanks,
> David
>
>> Thank you
>>
>> -Hamlin
>>
>> On 2019/9/4 3:16 PM, Hamlin Li wrote:
>>> Would you please review the following patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8209824
>>>
>>> webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/
>>>
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>

From amy.lu at oracle.com  Tue Oct 15 05:05:11 2019
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 15 Oct 2019 13:05:11 +0800
Subject: [JDK 14] RFR 8232195: Enable BigInteger tests: DivisionOverflow,
 SymmetricRangeTests and StringConstructorOverflow
Message-ID: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>

test/jdk/java/math/BigInteger/DivisionOverflow.java
test/jdk/java/math/BigInteger/StringConstructorOverflow.java
test/jdk/java/math/BigInteger/SymmetricRangeTests.java

These tests require huge memory and need to run with -Xmx8g
They are skipped or tagged with @ignore and not actually run in standard 
testing by jtreg.

Please review the patch to enable them by:
* Adding @requires os.maxMemory > 8g
* Put them into exclusiveAccess.dirs (so they won't run concurrently) to 
reduce the risk of impact other test.

Tested on all platforms with small (<8g) or large memory machines.

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


Thanks,
Amy

From joe.darcy at oracle.com  Tue Oct 15 05:12:00 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 14 Oct 2019 22:12:00 -0700
Subject: JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable
 non-transient instance fields in java.rmi
Message-ID: <0b7159ec-05f7-79fb-b557-dedb7f1d4fb0@oracle.com>

Hello,

Please review the changes for serial review now extending to the 
java.rmi module:

 ??? JDK-8232234: Suppress warnings on non-serializable non-transient 
instance fields in java.rmi
 ??? http://cr.openjdk.java.net/~darcy/8232234.0/

Patch below.

For src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java, 
the absence of no-arg constructor prevents the Externalizable class from 
being deserialized (de-externalized?), but as it hasn't seemed to cause 
problems in the 16 years since the file was last modified, I didn't 
think it was worthwhile to add a constructor at this point.

Thanks,

-Joe

--- 
old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
2019-10-14 21:49:08.305824614 -0700
+++ 
new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
2019-10-14 21:49:08.117824614 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1997, 2019, 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
@@ -107,6 +107,7 @@
 ???? /**
 ????? * @serial the group's monitor
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? private ActivationMonitor monitor;

 ???? /**
--- 
old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
2019-10-14 21:49:08.845824614 -0700
+++ 
new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
2019-10-14 21:49:08.641824614 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1997, 2019, 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
@@ -49,6 +49,7 @@
 ???? /**
 ????? * @serial The group's activation system.
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? private ActivationSystem system;

 ???? /**
--- 
old/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
2019-10-14 21:49:09.333824614 -0700
+++ 
new/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
2019-10-14 21:49:09.133824614 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2019, 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
@@ -189,12 +189,14 @@
 ???? /**
 ????? * @serial client-side socket factory (if any)
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? private RMIClientSocketFactory csf = null;

 ???? /**
 ????? * @serial server-side socket factory (if any) to use when
 ????? * exporting object
 ????? */
+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? private RMIServerSocketFactory ssf = null;

 ???? /* indicate compatibility with JDK 1.1.x version of class */
--- 
old/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
2019-10-14 21:49:09.837824614 -0700
+++ 
new/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
2019-10-14 21:49:09.645824614 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1997, 2003, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1997, 2019, 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
@@ -38,6 +38,7 @@
 ? *
 ? * @author Ann Wollrath
 ? */
+ at SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
 ?public class ActivatableServerRef extends UnicastServerRef2 {

 ???? private static final long serialVersionUID = 2002967993223003793L;
--- old/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
2019-10-14 21:49:10.413824614 -0700
+++ new/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
2019-10-14 21:49:10.173824614 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1997, 2019, 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
@@ -145,9 +145,11 @@
 ???? private static boolean debugExec;

 ???? /** maps activation id to its respective group id */
+??? @SuppressWarnings("serial") // Conditionally serializable
 ???? private Map<ActivationID,ActivationGroupID> idTable =
 ???????? new ConcurrentHashMap<>();
 ???? /** maps group id to its GroupEntry groups */
+??? @SuppressWarnings("serial") // Conditionally serializable
 ???? private Map<ActivationGroupID,GroupEntry> groupTable =
 ???????? new ConcurrentHashMap<>();

@@ -297,6 +299,7 @@

 ???????? private static final String NAME = 
ActivationSystem.class.getName();
 ???????? private static final long serialVersionUID = 4877330021609408794L;
+??????? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???????? private ActivationSystem systemStub = null;

 ???????? SystemRegistryImpl(int port,
@@ -498,6 +501,7 @@
 ????? * with RegistryImpl.checkAccess().
 ????? * The kind of access is retained for an exception if one is thrown.
 ????? */
+??? @SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
 ???? static class SameHostOnlyServerRef extends UnicastServerRef {
 ???????? private static final long serialVersionUID = 1234L;
 ???????? private String accessKind;????? // an exception message
@@ -873,7 +877,9 @@
 ???????? ActivationGroupDesc desc = null;
 ???????? ActivationGroupID groupID = null;
 ???????? long incarnation = 0;
+??????? @SuppressWarnings("serial") // Conditionally serializable
 ???????? Map<ActivationID,ObjectEntry> objects = new HashMap<>();
+??????? @SuppressWarnings("serial") // Conditionally serializable
 ???????? Set<ActivationID> restartSet = new HashSet<>();

 ???????? transient ActivationInstantiator group = null;
--- 
old/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
2019-10-14 21:49:11.057824614 -0700
+++ 
new/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
2019-10-14 21:49:10.841824614 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights 
reserved.
 ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ? *
 ? * This code is free software; you can redistribute it and/or modify it
@@ -69,6 +69,7 @@
 ???????? new Hashtable<>();
 ???? private boolean groupInactive = false;
 ???? private final ActivationGroupID groupID;
+??? @SuppressWarnings("serial")? // Conditionally serializable
 ???? private final List<ActivationID> lockedIDs = new ArrayList<>();

 ???? /**
--- old/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
2019-10-14 21:49:11.701824614 -0700
+++ new/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
2019-10-14 21:49:11.445824614 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2019, 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
@@ -67,6 +67,7 @@
Boolean.getBoolean("sun.rmi.client.logCalls")));
 ???? private static final long serialVersionUID = 8258372400816541186L;

+??? @SuppressWarnings("serial") // Not statically typed as Serializable
 ???? protected LiveRef ref;

 ???? /**


From martinrb at google.com  Tue Oct 15 05:28:13 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 14 Oct 2019 22:28:13 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
Message-ID: <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>

Hi Joe,

I'm surprised there were so few changes.

Why are some of the Condition's marked // Conditionally serializable
and others // Not statically typed as Serializable
?
---
(I don't recall us ever testing serializability of Conditions)
---
ThreadPoolExecutor.Worker already has
        /**
         * This class will never be serialized, but we provide a
         * serialVersionUID to suppress a javac warning.
         */
        private static final long serialVersionUID = 6138294804551838833L;

Perhaps that should be replaced with a class-level suppression?


On Mon, Oct 14, 2019 at 5:33 PM Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> Expanding the serialization review to include the java.util.concurrent
> package, please review the proposed changes:
>
>      JDK-8232230: Suppress warnings on non-serializable non-transient
> instance fields in java.util.concurrent
>      http://cr.openjdk.java.net/~darcy/8232230.0/
>
> Terminology added by  JDK-8231913: "Discuss serializability of
> collections" used where appropriate.
>
> Thanks,
>
> -Joe
>
>

From joe.darcy at oracle.com  Tue Oct 15 05:46:28 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 14 Oct 2019 22:46:28 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
Message-ID: <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>

Hi Martin,

On 10/14/2019 10:28 PM, Martin Buchholz wrote:
> Hi Joe,
>
> I'm surprised there were so few changes.


The changes in question allow the java.util.concurrent package to pass 
cleanly through the current version of my checks. Perhaps a strong 
version of the checks in the future will flag more issues of possible 
concern ;-)


>
> Why are some of the Condition's marked // Conditionally serializable

Summarizing the discussion leading up to the changes for JDK-8231913, 
"Conditionally serializable" describes collections that are serializable 
iff their contents are serializable. The changes made for

8231202: Suppress warnings on non-serializable non-transient instance 
fields in serializable classes 
http://hg.openjdk.java.net/jdk/jdk/rev/e036ee8bae56

use this terminology in the comments added for many collection types, 
including Vector, TreeMap, and multiple implementation classes in 
java.util.Collections. I tried to follow the same pattern in 
java.util.concurrent where appropriate.

The other comment is a broader statement acknowledging the cause of the 
warning, a non-serializable type as an instance field in a serializable 
class (in the absence of serialPersistentFields, etc.).

> and others // Not statically typed as Serializable
> ?
> ---
> (I don't recall us ever testing serializability of Conditions)
> ---
> ThreadPoolExecutor.Worker already has
> ? ? ? ? /**
> ? ? ? ? ?* This class will never be serialized, but we provide a
> ? ? ? ? ?* serialVersionUID to suppress a javac warning.
> ? ? ? ? ?*/
> ? ? ? ? private static final long serialVersionUID = 6138294804551838833L;
>
> Perhaps that should be replaced with a class-level suppression?

That would be fine with me if that is the preferred option for the JSR 
166-alpha maintainers. However, it would be stronger in that case if in 
addition to the @SuppressWarning("serial") at the class level, 
readObject and writeObject methods that unconditionally threw exceptions 
were added.

For the logistics of getting this change back, would you push the change 
to the java.util.concurrent upstream and then sync it down or should I 
push to jdk/jdk?

Thanks,

-Joe

>
>
> On Mon, Oct 14, 2019 at 5:33 PM Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hello,
>
>     Expanding the serialization review to include the
>     java.util.concurrent
>     package, please review the proposed changes:
>
>     ???? JDK-8232230: Suppress warnings on non-serializable non-transient
>     instance fields in java.util.concurrent
>     http://cr.openjdk.java.net/~darcy/8232230.0/
>
>     Terminology added by? JDK-8231913: "Discuss serializability of
>     collections" used where appropriate.
>
>     Thanks,
>
>     -Joe
>

From weijun.wang at oracle.com  Tue Oct 15 06:44:51 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 15 Oct 2019 14:44:51 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
 <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
Message-ID: <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>

I am OK with the change that makes this test more robust.

However, I am not an expert in RMI and don't know why the port cannot be released. If verifyPortFree(PORT) on line 60 can always succeed right after TestLibrary.getUnusedRandomPort() tries to create a ServerSocket at PORT and close it, this means the OS underneath spends no time in freeing the port. Is UnicastRemoteObject.unexportObject() also doing something similar? I see that the ServerSocket inside is closed on TCPTransport.java:280. Is it reliably called?

Even after this bug is resolved, I'd suggest add some logging and rerun this test unchanged multiple times to see what really happened.

--Max


> On Oct 15, 2019, at 11:04 AM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> Thanks for reviewing, I updated change at: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
> 
> it does not increase minimum time time and consider timeout factor at the same time.
> 
> Thank you
> 
> -Hamlin
> 
> On 2019/10/15 10:43 AM, Joe Darcy wrote:
>> Hello,
>> 
>> Structurally, I'd prefer an approach that doesn't increase the minimum time needed to run the test.
>> 
>> Any timeout-like value used within the test code should be sensitive to the jtreg timeout factor, as done in the webrev.
>> 
>> Thanks,
>> 
>> -Joe
>> 
>> On 10/14/2019 7:20 PM, Weijun Wang wrote:
>>> +SeanC
>>> 
>>> The wait might unnecessarily increase the test time. Maybe you can do something like this:
>>> 
>>>     int timeout = 10;
>>>     while (timeout > 0) {
>>>        sleep(one second);
>>>        verifyPortFree && return;
>>>        timeout--;
>>>     }
>>>     throw new Exception(still not freed);
>>> 
>>> And Sean, back in JDK-8016728 you said "Let's extend it to 1000ms and see how test behaves". So what do you think?
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> On Oct 15, 2019, at 10:03 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> The test is failing more frequently, could some help to review it?
>>>> 
>>>> Thank you
>>>> 
>>>> -Hamlin
>>>> 
>>>> On 2019/9/4 11:11 AM, Hamlin Li wrote:
>>>>> some background & comment: in most of failures, the "test.timeout.factor" is 10.0 or 8.0, so in the test code this factor should be considered in rmi operations such unexporting an object.
>>>>> 
>>>>> Thank you
>>>>> 
>>>>> -Hamlin
>>>>> 
>>>>> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Would you please review the following patch?
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>>>>> 
>>>>>> 
>>>>>> Thank you
>>>>>> 
>>>>>> -Hamlin
>>>>>> 


From sean.coffey at oracle.com  Tue Oct 15 09:19:45 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 15 Oct 2019 10:19:45 +0100
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
Message-ID: <1c0c9532-02bf-1a6d-baeb-8eac50e0311b@oracle.com>

Quite a while since I touched this one! The nature of the test is a bit 
flaky given
that we're assuming no other process will use the chosen port. I'm not sure
if a concrete solution is possible. One other option is to have this 
test run
in non-concurrent mode by editing test/jdk/TEST.ROOT --> 
exclusiveAccess.dirs=

The while loop approach may help but won't protect against cases where a
long running process has attached to the port number we're interested in.

regards,
Sean.

On 15/10/2019 03:20, Weijun Wang wrote:
> +SeanC
>
> The wait might unnecessarily increase the test time. Maybe you can do something like this:
>
>     int timeout = 10;
>     while (timeout > 0) {
>        sleep(one second);
>        verifyPortFree && return;
>        timeout--;
>     }
>     throw new Exception(still not freed);
>
> And Sean, back in JDK-8016728 you said "Let's extend it to 1000ms and see how test behaves". So what do you think?
>
> Thanks,
> Max
>
>> On Oct 15, 2019, at 10:03 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>> Hi,
>>
>> The test is failing more frequently, could some help to review it?
>>
>> Thank you
>>
>> -Hamlin
>>
>> On 2019/9/4 11:11 AM, Hamlin Li wrote:
>>> some background & comment: in most of failures, the "test.timeout.factor" is 10.0 or 8.0, so in the test code this factor should be considered in rmi operations such unexporting an object.
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>>>> Hi,
>>>>
>>>> Would you please review the following patch?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>>>
>>>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>>>
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>

From Alan.Bateman at oracle.com  Tue Oct 15 09:26:20 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Oct 2019 10:26:20 +0100
Subject: Review Request JDK-8173975: Lookup::in should not allow target
 class be primitive or array class
In-Reply-To: <0eca5816-68d6-33a7-9d34-7c9a78d0810a@oracle.com>
References: <0eca5816-68d6-33a7-9d34-7c9a78d0810a@oracle.com>
Message-ID: <22120ed2-3b60-5c9f-0e2c-5be6daae4670@oracle.com>

On 14/10/2019 23:34, Mandy Chung wrote:
> MethodHandles::lookup produces a Lookup object on the caller class. 
> The original intention for a Lookup object whose lookup class is 
> always a non-array and non-primitive class.
>
> MethodHandles::privateLookupIn and Lookup::in are the two other ways 
> that can produce a new Lookup object and they should disallow the new 
> lookup class be a primitive or array class.
>
> This patch proposes to make Lookup::in consistent with 
> MethodHandles::privateLookupIn to throw IAE if the target class is an 
> array type or primitive type.
>
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232227
> webrev:
> http://cr.openjdk.java.net/~mchung/jdk14/8173975/webrev.00/
This change looks good and I've added myself as Reviewer to the CSR.

-Alan

From huaming.li at oracle.com  Tue Oct 15 09:44:04 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 15 Oct 2019 17:44:04 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
 <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
 <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>
Message-ID: <3fbb7fc3-141e-cadf-2479-4c4183e17624@oracle.com>


On 2019/10/15 2:44 PM, Weijun Wang wrote:
> I am OK with the change that makes this test more robust.
Thanks Max.
>
> However, I am not an expert in RMI and don't know why the port cannot be released. If verifyPortFree(PORT) on line 60 can always succeed right after TestLibrary.getUnusedRandomPort() tries to create a ServerSocket at PORT and close it, this means the OS underneath spends no time in freeing the port.

No, the port is not freed here, it's only freed by unexportObject.

But the original code is a little bit faulty at verifyPortInUse, it 
should be as below, I have also updated the webrev in place: 
http://cr.openjdk.java.net/~mli/8134599/webrev.01/

@@ -101,6 +112,7 @@
 ???? private static void verifyPortInUse(int port) throws IOException {
 ???????? try {
 ???????????? verifyPortFree(port);
+??????????? throw new RuntimeException("port is not in use: " + port);

> Is UnicastRemoteObject.unexportObject() also doing something similar? I see that the ServerSocket inside is closed on TCPTransport.java:280. Is it reliably called?

In my understanding, it's not a sync operation, it's async, that means 
when unexportObject returns, it just triggers the port release, does not 
mean it already released the port.

>
> Even after this bug is resolved, I'd suggest add some logging and rerun this test unchanged multiple times to see what really happened.

Unfortunately, most of time this kind of issue is not easy to reproduce 
by running it multiple times. In my point of view, current logging is 
sufficient for diagnosing.

Thank you

-Hamlin

>
> --Max
>
>
>> On Oct 15, 2019, at 11:04 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>> Thanks for reviewing, I updated change at: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>
>> it does not increase minimum time time and consider timeout factor at the same time.
>>
>> Thank you
>>
>> -Hamlin
>>

From weijun.wang at oracle.com  Tue Oct 15 11:50:34 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 15 Oct 2019 19:50:34 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <3fbb7fc3-141e-cadf-2479-4c4183e17624@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
 <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
 <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>
 <3fbb7fc3-141e-cadf-2479-4c4183e17624@oracle.com>
Message-ID: <BE7E98B0-67AE-4132-99C5-62843E0B52AA@oracle.com>



> On Oct 15, 2019, at 5:44 PM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> 
> On 2019/10/15 2:44 PM, Weijun Wang wrote:
>> I am OK with the change that makes this test more robust.
> Thanks Max.
>> 
>> However, I am not an expert in RMI and don't know why the port cannot be released. If verifyPortFree(PORT) on line 60 can always succeed right after TestLibrary.getUnusedRandomPort() tries to create a ServerSocket at PORT and close it, this means the OS underneath spends no time in freeing the port.
> 
> No, the port is not freed here, it's only freed by unexportObject.

I meant the auto close inside getUnusedRandomPort().

> 
> But the original code is a little bit faulty at verifyPortInUse, it should be as below, I have also updated the webrev in place: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
> 
> @@ -101,6 +112,7 @@
>      private static void verifyPortInUse(int port) throws IOException {
>          try {
>              verifyPortFree(port);
> +            throw new RuntimeException("port is not in use: " + port);
> 
>> Is UnicastRemoteObject.unexportObject() also doing something similar? I see that the ServerSocket inside is closed on TCPTransport.java:280. Is it reliably called?
> 
> In my understanding, it's not a sync operation, it's async, that means when unexportObject returns, it just triggers the port release, does not mean it already released the port.

Ah.... 

> 
>> 
>> Even after this bug is resolved, I'd suggest add some logging and rerun this test unchanged multiple times to see what really happened.
> 
> Unfortunately, most of time this kind of issue is not easy to reproduce by running it multiple times. In my point of view, current logging is sufficient for diagnosing.

I see some logging calls inside source code. Maybe you can set a logging config file to let it show more?

--Max

> 
> Thank you
> 
> -Hamlin
> 
>> 
>> --Max
>> 
>> 
>>> On Oct 15, 2019, at 11:04 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>> 
>>> Thanks for reviewing, I updated change at: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>> 
>>> it does not increase minimum time time and consider timeout factor at the same time.
>>> 
>>> Thank you
>>> 
>>> -Hamlin
>>> 


From andy.herrick at oracle.com  Tue Oct 15 11:58:35 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 15 Oct 2019 07:58:35 -0400
Subject: RFR: JDK-8231604: Expand junit test added with JDK-8230920
Message-ID: <da655c9e-9b73-60fb-6b62-968cbbf49898@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

Simple junit test addition to cover add-launchers in AppInfoFile.

/Andy

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

[2] http://cr.openjdk.java.net/~herrick/8231604/webrev.01/


From alexey.semenyuk at oracle.com  Tue Oct 15 12:44:26 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 15 Oct 2019 08:44:26 -0400
Subject: RFR: JDK-8231604: Expand junit test added with JDK-8230920
In-Reply-To: <da655c9e-9b73-60fb-6b62-968cbbf49898@oracle.com>
References: <da655c9e-9b73-60fb-6b62-968cbbf49898@oracle.com>
Message-ID: <dec04e6b-71e4-f004-30ed-fbf7f5d98ae7@oracle.com>

Andy,

The test seems to assume particular order of launcher names. Is this 
what we have in jpackage?
I'd rather check the result of AppImageFile.getAddLauncherNames() call 
in the test is a list of two elements and names of launchers are 
contained in the list.

- Alexey

On 10/15/2019 7:58 AM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Simple junit test addition to cover add-launchers in AppInfoFile.
>
> /Andy
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231604
>
> [2] http://cr.openjdk.java.net/~herrick/8231604/webrev.01/
>


From andy.herrick at oracle.com  Tue Oct 15 12:50:47 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 15 Oct 2019 08:50:47 -0400
Subject: RFR: JDK-8231604: Expand junit test added with JDK-8230920
In-Reply-To: <dec04e6b-71e4-f004-30ed-fbf7f5d98ae7@oracle.com>
References: <da655c9e-9b73-60fb-6b62-968cbbf49898@oracle.com>
 <dec04e6b-71e4-f004-30ed-fbf7f5d98ae7@oracle.com>
Message-ID: <900f7aa5-681a-ee0a-987f-688744b91a48@oracle.com>

yes - although the list is ordered (in the order they are added) there 
is nothing requiring this, we could change that in future, so I will 
modify as you say to assert there are two elements and that contain the 
two given names..

/Andy

On 10/15/2019 8:44 AM, Alexey Semenyuk wrote:
> Andy,
>
> The test seems to assume particular order of launcher names. Is this 
> what we have in jpackage?
> I'd rather check the result of AppImageFile.getAddLauncherNames() call 
> in the test is a list of two elements and names of launchers are 
> contained in the list.
>
> - Alexey
>
> On 10/15/2019 7:58 AM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> Simple junit test addition to cover add-launchers in AppInfoFile.
>>
>> /Andy
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231604
>>
>> [2] http://cr.openjdk.java.net/~herrick/8231604/webrev.01/
>>
>

From andy.herrick at oracle.com  Tue Oct 15 13:17:11 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 15 Oct 2019 09:17:11 -0400
Subject: RFR: JDK-8231604: Expand junit test added with JDK-8230920
In-Reply-To: <900f7aa5-681a-ee0a-987f-688744b91a48@oracle.com>
References: <da655c9e-9b73-60fb-6b62-968cbbf49898@oracle.com>
 <dec04e6b-71e4-f004-30ed-fbf7f5d98ae7@oracle.com>
 <900f7aa5-681a-ee0a-987f-688744b91a48@oracle.com>
Message-ID: <0eba7fda-f57e-7c2a-ffa3-f544c9f636b6@oracle.com>

revised webrev.02: [3] to accommodate this feedback.

[3] http://cr.openjdk.java.net/~herrick/8231604/webrev.02/

/Andy


On 10/15/2019 8:50 AM, Andy Herrick wrote:
> yes - although the list is ordered (in the order they are added) there 
> is nothing requiring this, we could change that in future, so I will 
> modify as you say to assert there are two elements and that contain 
> the two given names..
>
> /Andy
>
> On 10/15/2019 8:44 AM, Alexey Semenyuk wrote:
>> Andy,
>>
>> The test seems to assume particular order of launcher names. Is this 
>> what we have in jpackage?
>> I'd rather check the result of AppImageFile.getAddLauncherNames() 
>> call in the test is a list of two elements and names of launchers are 
>> contained in the list.
>>
>> - Alexey
>>
>> On 10/15/2019 7:58 AM, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> Simple junit test addition to cover add-launchers in AppInfoFile.
>>>
>>> /Andy
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231604
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8231604/webrev.01/
>>>
>>

From alexey.semenyuk at oracle.com  Tue Oct 15 13:26:51 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 15 Oct 2019 09:26:51 -0400
Subject: RFR: JDK-8231604: Expand junit test added with JDK-8230920
In-Reply-To: <0eba7fda-f57e-7c2a-ffa3-f544c9f636b6@oracle.com>
References: <da655c9e-9b73-60fb-6b62-968cbbf49898@oracle.com>
 <dec04e6b-71e4-f004-30ed-fbf7f5d98ae7@oracle.com>
 <900f7aa5-681a-ee0a-987f-688744b91a48@oracle.com>
 <0eba7fda-f57e-7c2a-ffa3-f544c9f636b6@oracle.com>
Message-ID: <fd203066-a6f9-5c79-4de4-c470e4ca9581@oracle.com>

Looks good.

- Alexey

On 10/15/2019 9:17 AM, Andy Herrick wrote:
> revised webrev.02: [3] to accommodate this feedback.
>
> [3] http://cr.openjdk.java.net/~herrick/8231604/webrev.02/
>
> /Andy
>
>
> On 10/15/2019 8:50 AM, Andy Herrick wrote:
>> yes - although the list is ordered (in the order they are added) 
>> there is nothing requiring this, we could change that in future, so I 
>> will modify as you say to assert there are two elements and that 
>> contain the two given names..
>>
>> /Andy
>>
>> On 10/15/2019 8:44 AM, Alexey Semenyuk wrote:
>>> Andy,
>>>
>>> The test seems to assume particular order of launcher names. Is this 
>>> what we have in jpackage?
>>> I'd rather check the result of AppImageFile.getAddLauncherNames() 
>>> call in the test is a list of two elements and names of launchers 
>>> are contained in the list.
>>>
>>> - Alexey
>>>
>>> On 10/15/2019 7:58 AM, Andy Herrick wrote:
>>>> Please review the jpackage fix for bug [1] at [2].
>>>>
>>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>>> repository (jpackage).
>>>>
>>>> Simple junit test addition to cover add-launchers in AppInfoFile.
>>>>
>>>> /Andy
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8231604
>>>>
>>>> [2] http://cr.openjdk.java.net/~herrick/8231604/webrev.01/
>>>>
>>>


From Alan.Bateman at oracle.com  Tue Oct 15 13:46:41 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Oct 2019 14:46:41 +0100
Subject: RFR of JDK-8134599: Improve the code coverage for ThreadLocal
In-Reply-To: <cfea0a07-d378-5415-11c7-1140e43e97b2@oracle.com>
References: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com>
 <cfea0a07-d378-5415-11c7-1140e43e97b2@oracle.com>
Message-ID: <e04387a2-9a44-6e3f-7046-4900de7bb8ca@oracle.com>

On 15/10/2019 03:03, Hamlin Li wrote:
> Could some help to review it?
I haven't studied the test but one thing that seems to be missing is 
@modules java.base/java.lang:+open to allow the test access TL 
internals. This will be needed once java.base is fully encapsulated.

-Alan

From Roger.Riggs at oracle.com  Tue Oct 15 14:29:14 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Oct 2019 10:29:14 -0400
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <1c0c9532-02bf-1a6d-baeb-8eac50e0311b@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <1c0c9532-02bf-1a6d-baeb-8eac50e0311b@oracle.com>
Message-ID: <6af6ea0d-c5cf-377c-8080-23dae4e8cada@oracle.com>

Hi,

1. Replace the creation of the Registry with 
TestLibrary.crateRegistryOnEphemeralPort
and call TestLibrary.getRegistryPort to get the port number.

The intent of the test is still satisified without the timing/port 
allocation issues.

2. Another approach to testing if the port is in use would be to
assume its still active and do a registry.lookup("xxx").

The response be NotBoundException if the registry is still alive
or will be a RemoteException indicating the port is closed.

If some other application has grabbed the port, some other exception 
RemoteException cause will be thrown.

$.02, Roger


On 10/15/19 5:19 AM, Se?n Coffey wrote:
> Quite a while since I touched this one! The nature of the test is a 
> bit flaky given
> that we're assuming no other process will use the chosen port. I'm not 
> sure
> if a concrete solution is possible. One other option is to have this 
> test run
> in non-concurrent mode by editing test/jdk/TEST.ROOT --> 
> exclusiveAccess.dirs=
>
> The while loop approach may help but won't protect against cases where a
> long running process has attached to the port number we're interested in.
>
> regards,
> Sean.
>
> On 15/10/2019 03:20, Weijun Wang wrote:
>> +SeanC
>>
>> The wait might unnecessarily increase the test time. Maybe you can do 
>> something like this:
>>
>> ??? int timeout = 10;
>> ??? while (timeout > 0) {
>> ?????? sleep(one second);
>> ?????? verifyPortFree && return;
>> ?????? timeout--;
>> ??? }
>> ??? throw new Exception(still not freed);
>>
>> And Sean, back in JDK-8016728 you said "Let's extend it to 1000ms and 
>> see how test behaves". So what do you think?
>>
>> Thanks,
>> Max
>>
>>> On Oct 15, 2019, at 10:03 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> The test is failing more frequently, could some help to review it?
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>> On 2019/9/4 11:11 AM, Hamlin Li wrote:
>>>> some background & comment: in most of failures, the 
>>>> "test.timeout.factor" is 10.0 or 8.0, so in the test code this 
>>>> factor should be considered in rmi operations such unexporting an 
>>>> object.
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>
>>>> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>>>>> Hi,
>>>>>
>>>>> Would you please review the following patch?
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> -Hamlin
>>>>>


From martinrb at google.com  Tue Oct 15 15:02:15 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Oct 2019 08:02:15 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
Message-ID: <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>

On Mon, Oct 14, 2019 at 10:48 PM Joe Darcy <joe.darcy at oracle.com> wrote:

> Hi Martin,
> On 10/14/2019 10:28 PM, Martin Buchholz wrote:
>
> Hi Joe,
>
> I'm surprised there were so few changes.
>
>
> The changes in question allow the java.util.concurrent package to pass
> cleanly through the current version of my checks. Perhaps a strong version
> of the checks in the future will flag more issues of possible concern ;-)
>
>
>
> Why are some of the Condition's marked // Conditionally serializable
>
> Summarizing the discussion leading up to the changes for JDK-8231913, "Conditionally
> serializable" describes collections that are serializable iff their
> contents are serializable. The changes made for
>
> 8231202: Suppress warnings on non-serializable non-transient instance
> fields in serializable classes
> http://hg.openjdk.java.net/jdk/jdk/rev/e036ee8bae56
>
> use this terminology in the comments added for many collection types,
> including Vector, TreeMap, and multiple implementation classes in
> java.util.Collections. I tried to follow the same pattern in
> java.util.concurrent where appropriate.
>
The Condition field in ArrayBlockingQueue plays exactly the same role as in
e.g. LinkedBlockingQueue, so should have exactly the same treatment.
---
All Condition implementations in OpenJDK are Serializable.
In fact, we could promote all of those private Condition fields to
ConditionObject, making their Serializability clear, and then elide the
need for suppression.

private final ConditionObject notEmpty = (ConditionObject)
takeLock.newCondition();

(Why won't Java let me declare those fields private final Condition &
Serializable ?)

but now we're drifting into actual user-meaningful development...  We
promise that ReentrantLock is serializable, but we don't seem to have any
such promise for Conditions returned from ReentrantLock.newCondition(), and
we probably should.  Users are implicitly relying on the Serializability of
Condition in the same way we are.

---

Joe, go ahead and commit this to openjdk head when review is done.  We'll
incorporate.

From Roger.Riggs at oracle.com  Tue Oct 15 15:28:32 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Oct 2019 11:28:32 -0400
Subject: JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable
 non-transient instance fields in java.rmi
In-Reply-To: <0b7159ec-05f7-79fb-b557-dedb7f1d4fb0@oracle.com>
References: <0b7159ec-05f7-79fb-b557-dedb7f1d4fb0@oracle.com>
Message-ID: <3ac01aec-0aa6-e71a-3f90-cd70ed603b88@oracle.com>

Hi Joe,

In the case of UnicastRef, I think the warning on LiveRef ref is too 
aggresive.
Since UnicastRef inherits Externalizable and has writeExternal and 
readExternal
methods there is no static indication of which fields of the class are 
serialized or in what form.
All of the logic for what and how the fields are serialized is in the 
code of those methods.

What's the rationale for requiring developers to suppress warning on 
fields that
are not known to be serialized/externalized.

Roger


On 10/15/19 1:12 AM, Joe Darcy wrote:
> Hello,
>
> Please review the changes for serial review now extending to the 
> java.rmi module:
>
> ??? JDK-8232234: Suppress warnings on non-serializable non-transient 
> instance fields in java.rmi
> ??? http://cr.openjdk.java.net/~darcy/8232234.0/
>
> Patch below.
>
> For 
> src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java, 
> the absence of no-arg constructor prevents the Externalizable class 
> from being deserialized (de-externalized?), but as it hasn't seemed to 
> cause problems in the 16 years since the file was last modified, I 
> didn't think it was worthwhile to add a constructor at this point.
>
> Thanks,
>
> -Joe
>
> --- 
> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
> 2019-10-14 21:49:08.305824614 -0700
> +++ 
> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
> 2019-10-14 21:49:08.117824614 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1997, 2019, 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
> @@ -107,6 +107,7 @@
> ???? /**
> ????? * @serial the group's monitor
> ????? */
> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
> ???? private ActivationMonitor monitor;
>
> ???? /**
> --- 
> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
> 2019-10-14 21:49:08.845824614 -0700
> +++ 
> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
> 2019-10-14 21:49:08.641824614 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1997, 2019, 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
> @@ -49,6 +49,7 @@
> ???? /**
> ????? * @serial The group's activation system.
> ????? */
> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
> ???? private ActivationSystem system;
>
> ???? /**
> --- 
> old/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
> 2019-10-14 21:49:09.333824614 -0700
> +++ 
> new/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
> 2019-10-14 21:49:09.133824614 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2019, 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
> @@ -189,12 +189,14 @@
> ???? /**
> ????? * @serial client-side socket factory (if any)
> ????? */
> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
> ???? private RMIClientSocketFactory csf = null;
>
> ???? /**
> ????? * @serial server-side socket factory (if any) to use when
> ????? * exporting object
> ????? */
> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
> ???? private RMIServerSocketFactory ssf = null;
>
> ???? /* indicate compatibility with JDK 1.1.x version of class */
> --- 
> old/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
> 2019-10-14 21:49:09.837824614 -0700
> +++ 
> new/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
> 2019-10-14 21:49:09.645824614 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 1997, 2003, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1997, 2019, 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
> @@ -38,6 +38,7 @@
> ? *
> ? * @author Ann Wollrath
> ? */
> + at SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
> ?public class ActivatableServerRef extends UnicastServerRef2 {
>
> ???? private static final long serialVersionUID = 2002967993223003793L;
> --- old/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
> 2019-10-14 21:49:10.413824614 -0700
> +++ new/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
> 2019-10-14 21:49:10.173824614 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1997, 2019, 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
> @@ -145,9 +145,11 @@
> ???? private static boolean debugExec;
>
> ???? /** maps activation id to its respective group id */
> +??? @SuppressWarnings("serial") // Conditionally serializable
> ???? private Map<ActivationID,ActivationGroupID> idTable =
> ???????? new ConcurrentHashMap<>();
> ???? /** maps group id to its GroupEntry groups */
> +??? @SuppressWarnings("serial") // Conditionally serializable
> ???? private Map<ActivationGroupID,GroupEntry> groupTable =
> ???????? new ConcurrentHashMap<>();
>
> @@ -297,6 +299,7 @@
>
> ???????? private static final String NAME = 
> ActivationSystem.class.getName();
> ???????? private static final long serialVersionUID = 
> 4877330021609408794L;
> +??????? @SuppressWarnings("serial") // Not statically typed as 
> Serializable
> ???????? private ActivationSystem systemStub = null;
>
> ???????? SystemRegistryImpl(int port,
> @@ -498,6 +501,7 @@
> ????? * with RegistryImpl.checkAccess().
> ????? * The kind of access is retained for an exception if one is thrown.
> ????? */
> +??? @SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
> ???? static class SameHostOnlyServerRef extends UnicastServerRef {
> ???????? private static final long serialVersionUID = 1234L;
> ???????? private String accessKind;????? // an exception message
> @@ -873,7 +877,9 @@
> ???????? ActivationGroupDesc desc = null;
> ???????? ActivationGroupID groupID = null;
> ???????? long incarnation = 0;
> +??????? @SuppressWarnings("serial") // Conditionally serializable
> ???????? Map<ActivationID,ObjectEntry> objects = new HashMap<>();
> +??????? @SuppressWarnings("serial") // Conditionally serializable
> ???????? Set<ActivationID> restartSet = new HashSet<>();
>
> ???????? transient ActivationInstantiator group = null;
> --- 
> old/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
> 2019-10-14 21:49:11.057824614 -0700
> +++ 
> new/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
> 2019-10-14 21:49:10.841824614 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -69,6 +69,7 @@
> ???????? new Hashtable<>();
> ???? private boolean groupInactive = false;
> ???? private final ActivationGroupID groupID;
> +??? @SuppressWarnings("serial")? // Conditionally serializable
> ???? private final List<ActivationID> lockedIDs = new ArrayList<>();
>
> ???? /**
> --- old/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
> 2019-10-14 21:49:11.701824614 -0700
> +++ new/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
> 2019-10-14 21:49:11.445824614 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2019, 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
> @@ -67,6 +67,7 @@
> Boolean.getBoolean("sun.rmi.client.logCalls")));
> ???? private static final long serialVersionUID = 8258372400816541186L;
>
> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
> ???? protected LiveRef ref;
>
> ???? /**
>


From brian.burkhalter at oracle.com  Tue Oct 15 15:33:42 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 15 Oct 2019 08:33:42 -0700
Subject: [JDK 14] RFR 8232195: Enable BigInteger tests: DivisionOverflow, 
 SymmetricRangeTests and StringConstructorOverflow
In-Reply-To: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>
References: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>
Message-ID: <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>

Hi Amy,

This looks OK. It looks like DivisionOverflow was already being run however.

Also, the navigation in your webrev is broken: is your script current?

Thanks,

Brian

> On Oct 14, 2019, at 10:05 PM, Amy Lu <amy.lu at oracle.com> wrote:
> 
> test/jdk/java/math/BigInteger/DivisionOverflow.java
> test/jdk/java/math/BigInteger/StringConstructorOverflow.java
> test/jdk/java/math/BigInteger/SymmetricRangeTests.java
> 
> These tests require huge memory and need to run with -Xmx8g
> They are skipped or tagged with @ignore and not actually run in standard testing by jtreg.
> 
> Please review the patch to enable them by:
> * Adding @requires os.maxMemory > 8g
> * Put them into exclusiveAccess.dirs (so they won't run concurrently) to reduce the risk of impact other test.
> 
> Tested on all platforms with small (<8g) or large memory machines.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8232195 <https://bugs.openjdk.java.net/browse/JDK-8232195>
> webrev: http://cr.openjdk.java.net/~amlu/8232195/webrev.00/ <http://cr.openjdk.java.net/~amlu/8232195/webrev.00/>

From Roger.Riggs at oracle.com  Tue Oct 15 15:55:25 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Oct 2019 11:55:25 -0400
Subject: [14] RFR 8212749: DecimalFormat.setGroupingSize(int) allows
 setting negative grouping size, 8231984: Clarify semantics of
 DecimalFormat.getGroupingSize(0)
In-Reply-To: <33618d5c-7696-f3ba-2f78-590b0802504e@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
 <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
 <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>
 <33618d5c-7696-f3ba-2f78-590b0802504e@oracle.com>
Message-ID: <b4470f69-df8b-fbdb-a66c-1e5a8b8a50b8@oracle.com>

Looks good.

Thanks,? Roger

On 10/11/19 4:15 PM, naoto.sato at oracle.com wrote:
> Thanks, Roger. Modified readObject() accordingly:
>
> https://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.01/
>
> Naoto
>
> On 10/11/19 10:41 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> The javadoc/spec comments look fine.
>>
>> Code comments at DecimalFormat:4035 give some latitute for the value 
>> to be
>> out of range and since getGroupingSize returns the groupingSize byte
>> it would be cleaner if the value was always in the valid range
>> regardless of the isGroupingUsed boolean.
>>
>> Can there be code in the readObject method to correct out of range
>> values, perhaps to the default = 3?
>>
>> Thanks, Roger
>>
>>
>>
>> On 10/9/19 1:47 PM, naoto.sato at oracle.com wrote:
>>> I revised the fix, incorporating the clarification of the value zero 
>>> as the grouping size, which has separate JIRA issue and CSR as follows:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8231984
>>> https://bugs.openjdk.java.net/browse/JDK-8232012
>>>
>>> The merged changeset is as follows:
>>>
>>> http://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.00/
>>>
>>> Please review.
>>>
>>> Naoto
>>>
>>> On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for the review. In fact, Joe commented about the validity 
>>>> of zero on the CSR, so I will need to modify the method description 
>>>> such as:
>>>>
>>>> diff -r 9576895d0f9a 
>>>> src/java.base/share/classes/java/text/DecimalFormat.java
>>>> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
>>>> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
>>>> @@ -2770,10 +2770,13 @@
>>>> ????? /**
>>>> ?????? * Set the grouping size. Grouping size is the number of 
>>>> digits between
>>>> ?????? * grouping separators in the integer portion of a number.? 
>>>> For example,
>>>> -???? * in the number "123,456.78", the grouping size is 3.
>>>> -???? * <br>
>>>> +???? * in the number "123,456.78", the grouping size is 3. 
>>>> Grouping size of
>>>> +???? * zero designates that grouping is not used, which provides 
>>>> the same
>>>> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
>>>> +???? * setGroupingUsed(false)}.
>>>> +???? * <p>
>>>> ?????? * The value passed in is converted to a byte, which may lose 
>>>> information.
>>>> -???? * Invalid value, i.e., negative or greater than
>>>> +???? * Values that are negative or greater than
>>>> ?????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will 
>>>> throw an
>>>> ?????? * {@code IllegalArgumentException}.
>>>> ?????? *
>>>>
>>>> I will file a follow-on CSR and merge changesets.
>>>>
>>>> Naoto
>>>>
>>>> On 10/8/19 6:59 AM, Roger Riggs wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that 
>>>>> are".
>>>>>
>>>>> Otherwise looks fine. No need for another webrev.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix to the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>>>>
>>>>>> The proposed CSR and changeset are located at:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>>>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>>>>
>>>>>> Naoto
>>>>>
>>


From andy.herrick at oracle.com  Tue Oct 15 16:12:44 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 15 Oct 2019 12:12:44 -0400
Subject: RFR: JDK-8231912: Use https for URLs in help and error messages
Message-ID: <3c0e7fbb-9149-8fba-1122-ec84f46e6db1@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

This change modifies an number of urls used, mostly just changing http 
to https.

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

[2] https://cr.openjdk.java.net/~herrick/8231912/webrev.02/

/Andy


From kevin.rushforth at oracle.com  Tue Oct 15 16:15:23 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 15 Oct 2019 09:15:23 -0700
Subject: RFR: JDK-8231912: Use https for URLs in help and error messages
In-Reply-To: <3c0e7fbb-9149-8fba-1122-ec84f46e6db1@oracle.com>
References: <3c0e7fbb-9149-8fba-1122-ec84f46e6db1@oracle.com>
Message-ID: <a46c814c-ef04-6067-d711-e513a4f3a2dd@oracle.com>

Looks good.

-- Kevin


On 10/15/2019 9:12 AM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This change modifies an number of urls used, mostly just changing http 
> to https.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231912
>
> [2] https://cr.openjdk.java.net/~herrick/8231912/webrev.02/
>
> /Andy
>


From alexey.semenyuk at oracle.com  Tue Oct 15 17:28:44 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 15 Oct 2019 13:28:44 -0400
Subject: RFR: JDK-8231912: Use https for URLs in help and error messages
In-Reply-To: <3c0e7fbb-9149-8fba-1122-ec84f46e6db1@oracle.com>
References: <3c0e7fbb-9149-8fba-1122-ec84f46e6db1@oracle.com>
Message-ID: <00bc5636-3cdd-0538-6ea1-c8267ef243b3@oracle.com>

Looks good.

- Alexey

On 10/15/2019 12:12 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This change modifies an number of urls used, mostly just changing http 
> to https.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231912
>
> [2] https://cr.openjdk.java.net/~herrick/8231912/webrev.02/
>
> /Andy
>


From joe.darcy at oracle.com  Tue Oct 15 17:35:40 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 15 Oct 2019 10:35:40 -0700
Subject: JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable
 non-transient instance fields in java.rmi
In-Reply-To: <3ac01aec-0aa6-e71a-3f90-cd70ed603b88@oracle.com>
References: <0b7159ec-05f7-79fb-b557-dedb7f1d4fb0@oracle.com>
 <3ac01aec-0aa6-e71a-3f90-cd70ed603b88@oracle.com>
Message-ID: <ad36a5dc-9956-f7f4-095a-b434f6414641@oracle.com>

Hi Roger,

In rough statistics, there are well over 1,000 serializable classes in 
the JDK. There are closer to a dozen classes that are also 
externalizable (java.io.Externalizable extends java.io.Serializable ).

As such, the new checks have had much more tuning against 
serializable-but-not-externalizable classes compared to externalizable ones.

With any analysis, there is a balance between reporting false positives 
(as in this case due to {read, write}External) with false negatives (not 
reporting on a situation of actual concern).

It would be a small matter of programming to guard the field 
serializability checks with a " ... && notExternalizable()" clause. That 
would eliminate the warning in cases like LiveRef, at the risk of not 
reporting on possible logic errors or omissions.

Clearly the case for these checks is less strong for externalizable than 
serializable-but-not-externalizable ones. On balance, do you think these 
checks should be skipped for externalizable classes?

Cheers,

-Joe

On 10/15/2019 8:28 AM, Roger Riggs wrote:
> Hi Joe,
>
> In the case of UnicastRef, I think the warning on LiveRef ref is too 
> aggresive.
> Since UnicastRef inherits Externalizable and has writeExternal and 
> readExternal
> methods there is no static indication of which fields of the class are 
> serialized or in what form.
> All of the logic for what and how the fields are serialized is in the 
> code of those methods.
>
> What's the rationale for requiring developers to suppress warning on 
> fields that
> are not known to be serialized/externalized.
>
> Roger
>
>
> On 10/15/19 1:12 AM, Joe Darcy wrote:
>> Hello,
>>
>> Please review the changes for serial review now extending to the 
>> java.rmi module:
>>
>> ??? JDK-8232234: Suppress warnings on non-serializable non-transient 
>> instance fields in java.rmi
>> http://cr.openjdk.java.net/~darcy/8232234.0/
>>
>> Patch below.
>>
>> For 
>> src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java, 
>> the absence of no-arg constructor prevents the Externalizable class 
>> from being deserialized (de-externalized?), but as it hasn't seemed 
>> to cause problems in the 16 years since the file was last modified, I 
>> didn't think it was worthwhile to add a constructor at this point.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- 
>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>> 2019-10-14 21:49:08.305824614 -0700
>> +++ 
>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>> 2019-10-14 21:49:08.117824614 -0700
>> @@ -1,5 +1,5 @@
>> ?/*
>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1997, 2019, 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
>> @@ -107,6 +107,7 @@
>> ???? /**
>> ????? * @serial the group's monitor
>> ????? */
>> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
>> ???? private ActivationMonitor monitor;
>>
>> ???? /**
>> --- 
>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>> 2019-10-14 21:49:08.845824614 -0700
>> +++ 
>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>> 2019-10-14 21:49:08.641824614 -0700
>> @@ -1,5 +1,5 @@
>> ?/*
>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1997, 2019, 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
>> @@ -49,6 +49,7 @@
>> ???? /**
>> ????? * @serial The group's activation system.
>> ????? */
>> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
>> ???? private ActivationSystem system;
>>
>> ???? /**
>> --- 
>> old/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>> 2019-10-14 21:49:09.333824614 -0700
>> +++ 
>> new/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>> 2019-10-14 21:49:09.133824614 -0700
>> @@ -1,5 +1,5 @@
>> ?/*
>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1996, 2019, 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
>> @@ -189,12 +189,14 @@
>> ???? /**
>> ????? * @serial client-side socket factory (if any)
>> ????? */
>> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
>> ???? private RMIClientSocketFactory csf = null;
>>
>> ???? /**
>> ????? * @serial server-side socket factory (if any) to use when
>> ????? * exporting object
>> ????? */
>> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
>> ???? private RMIServerSocketFactory ssf = null;
>>
>> ???? /* indicate compatibility with JDK 1.1.x version of class */
>> --- 
>> old/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>> 2019-10-14 21:49:09.837824614 -0700
>> +++ 
>> new/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>> 2019-10-14 21:49:09.645824614 -0700
>> @@ -1,5 +1,5 @@
>> ?/*
>> - * Copyright (c) 1997, 2003, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1997, 2019, 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
>> @@ -38,6 +38,7 @@
>> ? *
>> ? * @author Ann Wollrath
>> ? */
>> + at SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
>> ?public class ActivatableServerRef extends UnicastServerRef2 {
>>
>> ???? private static final long serialVersionUID = 2002967993223003793L;
>> --- old/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>> 2019-10-14 21:49:10.413824614 -0700
>> +++ new/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>> 2019-10-14 21:49:10.173824614 -0700
>> @@ -1,5 +1,5 @@
>> ?/*
>> - * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1997, 2019, 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
>> @@ -145,9 +145,11 @@
>> ???? private static boolean debugExec;
>>
>> ???? /** maps activation id to its respective group id */
>> +??? @SuppressWarnings("serial") // Conditionally serializable
>> ???? private Map<ActivationID,ActivationGroupID> idTable =
>> ???????? new ConcurrentHashMap<>();
>> ???? /** maps group id to its GroupEntry groups */
>> +??? @SuppressWarnings("serial") // Conditionally serializable
>> ???? private Map<ActivationGroupID,GroupEntry> groupTable =
>> ???????? new ConcurrentHashMap<>();
>>
>> @@ -297,6 +299,7 @@
>>
>> ???????? private static final String NAME = 
>> ActivationSystem.class.getName();
>> ???????? private static final long serialVersionUID = 
>> 4877330021609408794L;
>> +??????? @SuppressWarnings("serial") // Not statically typed as 
>> Serializable
>> ???????? private ActivationSystem systemStub = null;
>>
>> ???????? SystemRegistryImpl(int port,
>> @@ -498,6 +501,7 @@
>> ????? * with RegistryImpl.checkAccess().
>> ????? * The kind of access is retained for an exception if one is 
>> thrown.
>> ????? */
>> +??? @SuppressWarnings("serial") // Externalizable class w/o no-arg 
>> c'tor
>> ???? static class SameHostOnlyServerRef extends UnicastServerRef {
>> ???????? private static final long serialVersionUID = 1234L;
>> ???????? private String accessKind;????? // an exception message
>> @@ -873,7 +877,9 @@
>> ???????? ActivationGroupDesc desc = null;
>> ???????? ActivationGroupID groupID = null;
>> ???????? long incarnation = 0;
>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>> ???????? Map<ActivationID,ObjectEntry> objects = new HashMap<>();
>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>> ???????? Set<ActivationID> restartSet = new HashSet<>();
>>
>> ???????? transient ActivationInstantiator group = null;
>> --- 
>> old/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>> 2019-10-14 21:49:11.057824614 -0700
>> +++ 
>> new/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>> 2019-10-14 21:49:10.841824614 -0700
>> @@ -1,5 +1,5 @@
>> ?/*
>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All 
>> rights reserved.
>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> ? *
>> ? * This code is free software; you can redistribute it and/or modify it
>> @@ -69,6 +69,7 @@
>> ???????? new Hashtable<>();
>> ???? private boolean groupInactive = false;
>> ???? private final ActivationGroupID groupID;
>> +??? @SuppressWarnings("serial")? // Conditionally serializable
>> ???? private final List<ActivationID> lockedIDs = new ArrayList<>();
>>
>> ???? /**
>> --- old/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>> 2019-10-14 21:49:11.701824614 -0700
>> +++ new/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>> 2019-10-14 21:49:11.445824614 -0700
>> @@ -1,5 +1,5 @@
>> ?/*
>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1996, 2019, 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
>> @@ -67,6 +67,7 @@
>> Boolean.getBoolean("sun.rmi.client.logCalls")));
>> ???? private static final long serialVersionUID = 8258372400816541186L;
>>
>> +??? @SuppressWarnings("serial") // Not statically typed as Serializable
>> ???? protected LiveRef ref;
>>
>> ???? /**
>>
>

From joe.darcy at oracle.com  Tue Oct 15 18:21:55 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 15 Oct 2019 11:21:55 -0700
Subject: JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable
 non-transient instance fields in java.rmi
In-Reply-To: <ad36a5dc-9956-f7f4-095a-b434f6414641@oracle.com>
References: <0b7159ec-05f7-79fb-b557-dedb7f1d4fb0@oracle.com>
 <3ac01aec-0aa6-e71a-3f90-cd70ed603b88@oracle.com>
 <ad36a5dc-9956-f7f4-095a-b434f6414641@oracle.com>
Message-ID: <1ac3db72-024d-2cf8-368e-f44ae2f8f5f4@oracle.com>

PS Updated webrev omitting changes to UnicastRef

 ??? http://cr.openjdk.java.net/~darcy/8232234.1/

Cheers,

-Joe

On 10/15/2019 10:35 AM, Joe Darcy wrote:
> Hi Roger,
>
> In rough statistics, there are well over 1,000 serializable classes in 
> the JDK. There are closer to a dozen classes that are also 
> externalizable (java.io.Externalizable extends java.io.Serializable ).
>
> As such, the new checks have had much more tuning against 
> serializable-but-not-externalizable classes compared to externalizable 
> ones.
>
> With any analysis, there is a balance between reporting false 
> positives (as in this case due to {read, write}External) with false 
> negatives (not reporting on a situation of actual concern).
>
> It would be a small matter of programming to guard the field 
> serializability checks with a " ... && notExternalizable()" clause. 
> That would eliminate the warning in cases like LiveRef, at the risk of 
> not reporting on possible logic errors or omissions.
>
> Clearly the case for these checks is less strong for externalizable 
> than serializable-but-not-externalizable ones. On balance, do you 
> think these checks should be skipped for externalizable classes?
>
> Cheers,
>
> -Joe
>
> On 10/15/2019 8:28 AM, Roger Riggs wrote:
>> Hi Joe,
>>
>> In the case of UnicastRef, I think the warning on LiveRef ref is too 
>> aggresive.
>> Since UnicastRef inherits Externalizable and has writeExternal and 
>> readExternal
>> methods there is no static indication of which fields of the class 
>> are serialized or in what form.
>> All of the logic for what and how the fields are serialized is in the 
>> code of those methods.
>>
>> What's the rationale for requiring developers to suppress warning on 
>> fields that
>> are not known to be serialized/externalized.
>>
>> Roger
>>
>>
>> On 10/15/19 1:12 AM, Joe Darcy wrote:
>>> Hello,
>>>
>>> Please review the changes for serial review now extending to the 
>>> java.rmi module:
>>>
>>> ??? JDK-8232234: Suppress warnings on non-serializable non-transient 
>>> instance fields in java.rmi
>>> http://cr.openjdk.java.net/~darcy/8232234.0/
>>>
>>> Patch below.
>>>
>>> For 
>>> src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java, 
>>> the absence of no-arg constructor prevents the Externalizable class 
>>> from being deserialized (de-externalized?), but as it hasn't seemed 
>>> to cause problems in the 16 years since the file was last modified, 
>>> I didn't think it was worthwhile to add a constructor at this point.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> --- 
>>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>>> 2019-10-14 21:49:08.305824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>>> 2019-10-14 21:49:08.117824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -107,6 +107,7 @@
>>> ???? /**
>>> ????? * @serial the group's monitor
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private ActivationMonitor monitor;
>>>
>>> ???? /**
>>> --- 
>>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>>> 2019-10-14 21:49:08.845824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>>> 2019-10-14 21:49:08.641824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -49,6 +49,7 @@
>>> ???? /**
>>> ????? * @serial The group's activation system.
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private ActivationSystem system;
>>>
>>> ???? /**
>>> --- 
>>> old/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>>> 2019-10-14 21:49:09.333824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>>> 2019-10-14 21:49:09.133824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1996, 2019, 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
>>> @@ -189,12 +189,14 @@
>>> ???? /**
>>> ????? * @serial client-side socket factory (if any)
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private RMIClientSocketFactory csf = null;
>>>
>>> ???? /**
>>> ????? * @serial server-side socket factory (if any) to use when
>>> ????? * exporting object
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private RMIServerSocketFactory ssf = null;
>>>
>>> ???? /* indicate compatibility with JDK 1.1.x version of class */
>>> --- 
>>> old/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>>> 2019-10-14 21:49:09.837824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>>> 2019-10-14 21:49:09.645824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2003, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -38,6 +38,7 @@
>>> ? *
>>> ? * @author Ann Wollrath
>>> ? */
>>> + at SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
>>> ?public class ActivatableServerRef extends UnicastServerRef2 {
>>>
>>> ???? private static final long serialVersionUID = 2002967993223003793L;
>>> --- old/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>>> 2019-10-14 21:49:10.413824614 -0700
>>> +++ new/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>>> 2019-10-14 21:49:10.173824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -145,9 +145,11 @@
>>> ???? private static boolean debugExec;
>>>
>>> ???? /** maps activation id to its respective group id */
>>> +??? @SuppressWarnings("serial") // Conditionally serializable
>>> ???? private Map<ActivationID,ActivationGroupID> idTable =
>>> ???????? new ConcurrentHashMap<>();
>>> ???? /** maps group id to its GroupEntry groups */
>>> +??? @SuppressWarnings("serial") // Conditionally serializable
>>> ???? private Map<ActivationGroupID,GroupEntry> groupTable =
>>> ???????? new ConcurrentHashMap<>();
>>>
>>> @@ -297,6 +299,7 @@
>>>
>>> ???????? private static final String NAME = 
>>> ActivationSystem.class.getName();
>>> ???????? private static final long serialVersionUID = 
>>> 4877330021609408794L;
>>> +??????? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???????? private ActivationSystem systemStub = null;
>>>
>>> ???????? SystemRegistryImpl(int port,
>>> @@ -498,6 +501,7 @@
>>> ????? * with RegistryImpl.checkAccess().
>>> ????? * The kind of access is retained for an exception if one is 
>>> thrown.
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Externalizable class w/o no-arg 
>>> c'tor
>>> ???? static class SameHostOnlyServerRef extends UnicastServerRef {
>>> ???????? private static final long serialVersionUID = 1234L;
>>> ???????? private String accessKind;????? // an exception message
>>> @@ -873,7 +877,9 @@
>>> ???????? ActivationGroupDesc desc = null;
>>> ???????? ActivationGroupID groupID = null;
>>> ???????? long incarnation = 0;
>>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>>> ???????? Map<ActivationID,ObjectEntry> objects = new HashMap<>();
>>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>>> ???????? Set<ActivationID> restartSet = new HashSet<>();
>>>
>>> ???????? transient ActivationInstantiator group = null;
>>> --- 
>>> old/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>>> 2019-10-14 21:49:11.057824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>>> 2019-10-14 21:49:10.841824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> ? *
>>> ? * This code is free software; you can redistribute it and/or 
>>> modify it
>>> @@ -69,6 +69,7 @@
>>> ???????? new Hashtable<>();
>>> ???? private boolean groupInactive = false;
>>> ???? private final ActivationGroupID groupID;
>>> +??? @SuppressWarnings("serial")? // Conditionally serializable
>>> ???? private final List<ActivationID> lockedIDs = new ArrayList<>();
>>>
>>> ???? /**
>>> --- old/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>>> 2019-10-14 21:49:11.701824614 -0700
>>> +++ new/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>>> 2019-10-14 21:49:11.445824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1996, 2019, 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
>>> @@ -67,6 +67,7 @@
>>> Boolean.getBoolean("sun.rmi.client.logCalls")));
>>> ???? private static final long serialVersionUID = 8258372400816541186L;
>>>
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? protected LiveRef ref;
>>>
>>> ???? /**
>>>
>>

From alexey.semenyuk at oracle.com  Tue Oct 15 18:48:25 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 15 Oct 2019 14:48:25 -0400
Subject: RFR: JDK-8231862: Decouple DesktopIntegration and LinuxPackageBundler
 classes
In-Reply-To: <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
References: <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
Message-ID: <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

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

[2] http://cr.openjdk.java.net/~asemenyuk/8231862/webrev.00/


From alexey.semenyuk at oracle.com  Tue Oct 15 19:13:23 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 15 Oct 2019 15:13:23 -0400
Subject: RFR: JDK-8232279: Improve test helpers #2
In-Reply-To: <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>
References: <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>
Message-ID: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

Additionally migrated some tests that used the old test helpers to use 
the new test helpers.

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8232279/webrev.00/


From Roger.Riggs at oracle.com  Tue Oct 15 19:18:05 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Oct 2019 15:18:05 -0400
Subject: JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable
 non-transient instance fields in java.rmi
In-Reply-To: <ad36a5dc-9956-f7f4-095a-b434f6414641@oracle.com>
References: <0b7159ec-05f7-79fb-b557-dedb7f1d4fb0@oracle.com>
 <3ac01aec-0aa6-e71a-3f90-cd70ed603b88@oracle.com>
 <ad36a5dc-9956-f7f4-095a-b434f6414641@oracle.com>
Message-ID: <dfeb1504-e48e-1f86-b371-35804677f956@oracle.com>

Hi Joe,

I would omit the checks on Externalizable classes since there is no direct
connection between the fields of the class and the serialized form.
With Serializable classes it is specified that serialization will be 
explicitly
examining the fields of the class.

Roger



On 10/15/19 1:35 PM, Joe Darcy wrote:
> Hi Roger,
>
> In rough statistics, there are well over 1,000 serializable classes in 
> the JDK. There are closer to a dozen classes that are also 
> externalizable (java.io.Externalizable extends java.io.Serializable ).
>
> As such, the new checks have had much more tuning against 
> serializable-but-not-externalizable classes compared to externalizable 
> ones.
>
> With any analysis, there is a balance between reporting false 
> positives (as in this case due to {read, write}External) with false 
> negatives (not reporting on a situation of actual concern).
>
> It would be a small matter of programming to guard the field 
> serializability checks with a " ... && notExternalizable()" clause. 
> That would eliminate the warning in cases like LiveRef, at the risk of 
> not reporting on possible logic errors or omissions.
>
> Clearly the case for these checks is less strong for externalizable 
> than serializable-but-not-externalizable ones. On balance, do you 
> think these checks should be skipped for externalizable classes?
>
> Cheers,
>
> -Joe
>
> On 10/15/2019 8:28 AM, Roger Riggs wrote:
>> Hi Joe,
>>
>> In the case of UnicastRef, I think the warning on LiveRef ref is too 
>> aggresive.
>> Since UnicastRef inherits Externalizable and has writeExternal and 
>> readExternal
>> methods there is no static indication of which fields of the class 
>> are serialized or in what form.
>> All of the logic for what and how the fields are serialized is in the 
>> code of those methods.
>>
>> What's the rationale for requiring developers to suppress warning on 
>> fields that
>> are not known to be serialized/externalized.
>>
>> Roger
>>
>>
>> On 10/15/19 1:12 AM, Joe Darcy wrote:
>>> Hello,
>>>
>>> Please review the changes for serial review now extending to the 
>>> java.rmi module:
>>>
>>> ??? JDK-8232234: Suppress warnings on non-serializable non-transient 
>>> instance fields in java.rmi
>>> http://cr.openjdk.java.net/~darcy/8232234.0/
>>>
>>> Patch below.
>>>
>>> For 
>>> src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java, 
>>> the absence of no-arg constructor prevents the Externalizable class 
>>> from being deserialized (de-externalized?), but as it hasn't seemed 
>>> to cause problems in the 16 years since the file was last modified, 
>>> I didn't think it was worthwhile to add a constructor at this point.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> --- 
>>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>>> 2019-10-14 21:49:08.305824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>>> 2019-10-14 21:49:08.117824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -107,6 +107,7 @@
>>> ???? /**
>>> ????? * @serial the group's monitor
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private ActivationMonitor monitor;
>>>
>>> ???? /**
>>> --- 
>>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>>> 2019-10-14 21:49:08.845824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>>> 2019-10-14 21:49:08.641824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -49,6 +49,7 @@
>>> ???? /**
>>> ????? * @serial The group's activation system.
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private ActivationSystem system;
>>>
>>> ???? /**
>>> --- 
>>> old/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>>> 2019-10-14 21:49:09.333824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>>> 2019-10-14 21:49:09.133824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1996, 2019, 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
>>> @@ -189,12 +189,14 @@
>>> ???? /**
>>> ????? * @serial client-side socket factory (if any)
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private RMIClientSocketFactory csf = null;
>>>
>>> ???? /**
>>> ????? * @serial server-side socket factory (if any) to use when
>>> ????? * exporting object
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? private RMIServerSocketFactory ssf = null;
>>>
>>> ???? /* indicate compatibility with JDK 1.1.x version of class */
>>> --- 
>>> old/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>>> 2019-10-14 21:49:09.837824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>>> 2019-10-14 21:49:09.645824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2003, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -38,6 +38,7 @@
>>> ? *
>>> ? * @author Ann Wollrath
>>> ? */
>>> + at SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
>>> ?public class ActivatableServerRef extends UnicastServerRef2 {
>>>
>>> ???? private static final long serialVersionUID = 2002967993223003793L;
>>> --- old/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>>> 2019-10-14 21:49:10.413824614 -0700
>>> +++ new/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>>> 2019-10-14 21:49:10.173824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, 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
>>> @@ -145,9 +145,11 @@
>>> ???? private static boolean debugExec;
>>>
>>> ???? /** maps activation id to its respective group id */
>>> +??? @SuppressWarnings("serial") // Conditionally serializable
>>> ???? private Map<ActivationID,ActivationGroupID> idTable =
>>> ???????? new ConcurrentHashMap<>();
>>> ???? /** maps group id to its GroupEntry groups */
>>> +??? @SuppressWarnings("serial") // Conditionally serializable
>>> ???? private Map<ActivationGroupID,GroupEntry> groupTable =
>>> ???????? new ConcurrentHashMap<>();
>>>
>>> @@ -297,6 +299,7 @@
>>>
>>> ???????? private static final String NAME = 
>>> ActivationSystem.class.getName();
>>> ???????? private static final long serialVersionUID = 
>>> 4877330021609408794L;
>>> +??????? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???????? private ActivationSystem systemStub = null;
>>>
>>> ???????? SystemRegistryImpl(int port,
>>> @@ -498,6 +501,7 @@
>>> ????? * with RegistryImpl.checkAccess().
>>> ????? * The kind of access is retained for an exception if one is 
>>> thrown.
>>> ????? */
>>> +??? @SuppressWarnings("serial") // Externalizable class w/o no-arg 
>>> c'tor
>>> ???? static class SameHostOnlyServerRef extends UnicastServerRef {
>>> ???????? private static final long serialVersionUID = 1234L;
>>> ???????? private String accessKind;????? // an exception message
>>> @@ -873,7 +877,9 @@
>>> ???????? ActivationGroupDesc desc = null;
>>> ???????? ActivationGroupID groupID = null;
>>> ???????? long incarnation = 0;
>>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>>> ???????? Map<ActivationID,ObjectEntry> objects = new HashMap<>();
>>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>>> ???????? Set<ActivationID> restartSet = new HashSet<>();
>>>
>>> ???????? transient ActivationInstantiator group = null;
>>> --- 
>>> old/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>>> 2019-10-14 21:49:11.057824614 -0700
>>> +++ 
>>> new/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>>> 2019-10-14 21:49:10.841824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> ? *
>>> ? * This code is free software; you can redistribute it and/or 
>>> modify it
>>> @@ -69,6 +69,7 @@
>>> ???????? new Hashtable<>();
>>> ???? private boolean groupInactive = false;
>>> ???? private final ActivationGroupID groupID;
>>> +??? @SuppressWarnings("serial")? // Conditionally serializable
>>> ???? private final List<ActivationID> lockedIDs = new ArrayList<>();
>>>
>>> ???? /**
>>> --- old/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>>> 2019-10-14 21:49:11.701824614 -0700
>>> +++ new/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>>> 2019-10-14 21:49:11.445824614 -0700
>>> @@ -1,5 +1,5 @@
>>> ?/*
>>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>>> rights reserved.
>>> + * Copyright (c) 1996, 2019, 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
>>> @@ -67,6 +67,7 @@
>>> Boolean.getBoolean("sun.rmi.client.logCalls")));
>>> ???? private static final long serialVersionUID = 8258372400816541186L;
>>>
>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> ???? protected LiveRef ref;
>>>
>>> ???? /**
>>>
>>


From andy.herrick at oracle.com  Tue Oct 15 19:27:41 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 15 Oct 2019 15:27:41 -0400
Subject: RFR: JDK-8231862: Decouple DesktopIntegration and
 LinuxPackageBundler classes
In-Reply-To: <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>
References: <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
 <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>
Message-ID: <0321e3a8-59d4-0c70-bd9f-2cf7e1d4cb7b@oracle.com>

A long overdue change.? Looks good as far as I can see.

Thanks

/Andy

On 10/15/2019 2:48 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231862
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8231862/webrev.00/
>

From Roger.Riggs at oracle.com  Tue Oct 15 19:29:34 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Oct 2019 15:29:34 -0400
Subject: JDK 14 RFR of JDK-8232234: Suppress warnings on non-serializable
 non-transient instance fields in java.rmi
In-Reply-To: <1ac3db72-024d-2cf8-368e-f44ae2f8f5f4@oracle.com>
References: <0b7159ec-05f7-79fb-b557-dedb7f1d4fb0@oracle.com>
 <3ac01aec-0aa6-e71a-3f90-cd70ed603b88@oracle.com>
 <ad36a5dc-9956-f7f4-095a-b434f6414641@oracle.com>
 <1ac3db72-024d-2cf8-368e-f44ae2f8f5f4@oracle.com>
Message-ID: <30d7fbfb-85c6-15af-44d7-57efc6e1e50a@oracle.com>

Hi Joe,

These look fine as is.

Thanks, Roger

p.s.

As a separate issue, there might be some cleanup possible using other 
techniques
since these implementation classes are not expected to be serialized except
in the case of RMI that explicitly replaces the reference to a "Remote"
with a remote stub instead.


On 10/15/19 2:21 PM, Joe Darcy wrote:
> PS Updated webrev omitting changes to UnicastRef
>
> ??? http://cr.openjdk.java.net/~darcy/8232234.1/
>
> Cheers,
>
> -Joe
>
> On 10/15/2019 10:35 AM, Joe Darcy wrote:
>> Hi Roger,
>>
>> In rough statistics, there are well over 1,000 serializable classes 
>> in the JDK. There are closer to a dozen classes that are also 
>> externalizable (java.io.Externalizable extends java.io.Serializable ).
>>
>> As such, the new checks have had much more tuning against 
>> serializable-but-not-externalizable classes compared to 
>> externalizable ones.
>>
>> With any analysis, there is a balance between reporting false 
>> positives (as in this case due to {read, write}External) with false 
>> negatives (not reporting on a situation of actual concern).
>>
>> It would be a small matter of programming to guard the field 
>> serializability checks with a " ... && notExternalizable()" clause. 
>> That would eliminate the warning in cases like LiveRef, at the risk 
>> of not reporting on possible logic errors or omissions.
>>
>> Clearly the case for these checks is less strong for externalizable 
>> than serializable-but-not-externalizable ones. On balance, do you 
>> think these checks should be skipped for externalizable classes?
>>
>> Cheers,
>>
>> -Joe
>>
>> On 10/15/2019 8:28 AM, Roger Riggs wrote:
>>> Hi Joe,
>>>
>>> In the case of UnicastRef, I think the warning on LiveRef ref is too 
>>> aggresive.
>>> Since UnicastRef inherits Externalizable and has writeExternal and 
>>> readExternal
>>> methods there is no static indication of which fields of the class 
>>> are serialized or in what form.
>>> All of the logic for what and how the fields are serialized is in 
>>> the code of those methods.
>>>
>>> What's the rationale for requiring developers to suppress warning on 
>>> fields that
>>> are not known to be serialized/externalized.
>>>
>>> Roger
>>>
>>>
>>> On 10/15/19 1:12 AM, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> Please review the changes for serial review now extending to the 
>>>> java.rmi module:
>>>>
>>>> ??? JDK-8232234: Suppress warnings on non-serializable 
>>>> non-transient instance fields in java.rmi
>>>> http://cr.openjdk.java.net/~darcy/8232234.0/
>>>>
>>>> Patch below.
>>>>
>>>> For 
>>>> src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java, 
>>>> the absence of no-arg constructor prevents the Externalizable class 
>>>> from being deserialized (de-externalized?), but as it hasn't seemed 
>>>> to cause problems in the 16 years since the file was last modified, 
>>>> I didn't think it was worthwhile to add a constructor at this point.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> --- 
>>>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>>>> 2019-10-14 21:49:08.305824614 -0700
>>>> +++ 
>>>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java 
>>>> 2019-10-14 21:49:08.117824614 -0700
>>>> @@ -1,5 +1,5 @@
>>>> ?/*
>>>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 1997, 2019, 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
>>>> @@ -107,6 +107,7 @@
>>>> ???? /**
>>>> ????? * @serial the group's monitor
>>>> ????? */
>>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>>> Serializable
>>>> ???? private ActivationMonitor monitor;
>>>>
>>>> ???? /**
>>>> --- 
>>>> old/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>>>> 2019-10-14 21:49:08.845824614 -0700
>>>> +++ 
>>>> new/src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java 
>>>> 2019-10-14 21:49:08.641824614 -0700
>>>> @@ -1,5 +1,5 @@
>>>> ?/*
>>>> - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 1997, 2019, 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
>>>> @@ -49,6 +49,7 @@
>>>> ???? /**
>>>> ????? * @serial The group's activation system.
>>>> ????? */
>>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>>> Serializable
>>>> ???? private ActivationSystem system;
>>>>
>>>> ???? /**
>>>> --- 
>>>> old/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>>>> 2019-10-14 21:49:09.333824614 -0700
>>>> +++ 
>>>> new/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java 
>>>> 2019-10-14 21:49:09.133824614 -0700
>>>> @@ -1,5 +1,5 @@
>>>> ?/*
>>>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 1996, 2019, 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
>>>> @@ -189,12 +189,14 @@
>>>> ???? /**
>>>> ????? * @serial client-side socket factory (if any)
>>>> ????? */
>>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>>> Serializable
>>>> ???? private RMIClientSocketFactory csf = null;
>>>>
>>>> ???? /**
>>>> ????? * @serial server-side socket factory (if any) to use when
>>>> ????? * exporting object
>>>> ????? */
>>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>>> Serializable
>>>> ???? private RMIServerSocketFactory ssf = null;
>>>>
>>>> ???? /* indicate compatibility with JDK 1.1.x version of class */
>>>> --- 
>>>> old/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>>>> 2019-10-14 21:49:09.837824614 -0700
>>>> +++ 
>>>> new/src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java 
>>>> 2019-10-14 21:49:09.645824614 -0700
>>>> @@ -1,5 +1,5 @@
>>>> ?/*
>>>> - * Copyright (c) 1997, 2003, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 1997, 2019, 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
>>>> @@ -38,6 +38,7 @@
>>>> ? *
>>>> ? * @author Ann Wollrath
>>>> ? */
>>>> + at SuppressWarnings("serial") // Externalizable class w/o no-arg c'tor
>>>> ?public class ActivatableServerRef extends UnicastServerRef2 {
>>>>
>>>> ???? private static final long serialVersionUID = 
>>>> 2002967993223003793L;
>>>> --- old/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>>>> 2019-10-14 21:49:10.413824614 -0700
>>>> +++ new/src/java.rmi/share/classes/sun/rmi/server/Activation.java 
>>>> 2019-10-14 21:49:10.173824614 -0700
>>>> @@ -1,5 +1,5 @@
>>>> ?/*
>>>> - * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 1997, 2019, 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
>>>> @@ -145,9 +145,11 @@
>>>> ???? private static boolean debugExec;
>>>>
>>>> ???? /** maps activation id to its respective group id */
>>>> +??? @SuppressWarnings("serial") // Conditionally serializable
>>>> ???? private Map<ActivationID,ActivationGroupID> idTable =
>>>> ???????? new ConcurrentHashMap<>();
>>>> ???? /** maps group id to its GroupEntry groups */
>>>> +??? @SuppressWarnings("serial") // Conditionally serializable
>>>> ???? private Map<ActivationGroupID,GroupEntry> groupTable =
>>>> ???????? new ConcurrentHashMap<>();
>>>>
>>>> @@ -297,6 +299,7 @@
>>>>
>>>> ???????? private static final String NAME = 
>>>> ActivationSystem.class.getName();
>>>> ???????? private static final long serialVersionUID = 
>>>> 4877330021609408794L;
>>>> +??????? @SuppressWarnings("serial") // Not statically typed as 
>>>> Serializable
>>>> ???????? private ActivationSystem systemStub = null;
>>>>
>>>> ???????? SystemRegistryImpl(int port,
>>>> @@ -498,6 +501,7 @@
>>>> ????? * with RegistryImpl.checkAccess().
>>>> ????? * The kind of access is retained for an exception if one is 
>>>> thrown.
>>>> ????? */
>>>> +??? @SuppressWarnings("serial") // Externalizable class w/o no-arg 
>>>> c'tor
>>>> ???? static class SameHostOnlyServerRef extends UnicastServerRef {
>>>> ???????? private static final long serialVersionUID = 1234L;
>>>> ???????? private String accessKind;????? // an exception message
>>>> @@ -873,7 +877,9 @@
>>>> ???????? ActivationGroupDesc desc = null;
>>>> ???????? ActivationGroupID groupID = null;
>>>> ???????? long incarnation = 0;
>>>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>>>> ???????? Map<ActivationID,ObjectEntry> objects = new HashMap<>();
>>>> +??????? @SuppressWarnings("serial") // Conditionally serializable
>>>> ???????? Set<ActivationID> restartSet = new HashSet<>();
>>>>
>>>> ???????? transient ActivationInstantiator group = null;
>>>> --- 
>>>> old/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>>>> 2019-10-14 21:49:11.057824614 -0700
>>>> +++ 
>>>> new/src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java 
>>>> 2019-10-14 21:49:10.841824614 -0700
>>>> @@ -1,5 +1,5 @@
>>>> ?/*
>>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>> ? *
>>>> ? * This code is free software; you can redistribute it and/or 
>>>> modify it
>>>> @@ -69,6 +69,7 @@
>>>> ???????? new Hashtable<>();
>>>> ???? private boolean groupInactive = false;
>>>> ???? private final ActivationGroupID groupID;
>>>> +??? @SuppressWarnings("serial")? // Conditionally serializable
>>>> ???? private final List<ActivationID> lockedIDs = new ArrayList<>();
>>>>
>>>> ???? /**
>>>> --- old/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>>>> 2019-10-14 21:49:11.701824614 -0700
>>>> +++ new/src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java 
>>>> 2019-10-14 21:49:11.445824614 -0700
>>>> @@ -1,5 +1,5 @@
>>>> ?/*
>>>> - * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 1996, 2019, 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
>>>> @@ -67,6 +67,7 @@
>>>> Boolean.getBoolean("sun.rmi.client.logCalls")));
>>>> ???? private static final long serialVersionUID = 
>>>> 8258372400816541186L;
>>>>
>>>> +??? @SuppressWarnings("serial") // Not statically typed as 
>>>> Serializable
>>>> ???? protected LiveRef ref;
>>>>
>>>> ???? /**
>>>>
>>>


From andy.herrick at oracle.com  Tue Oct 15 19:55:25 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 15 Oct 2019 15:55:25 -0400
Subject: RFR: JDK-8232279: Improve test helpers #2
In-Reply-To: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
References: <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>
 <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
Message-ID: <571dceac-6954-b0a5-9982-c97b38e96b3d@oracle.com>

This looks good.

/Andy

On 10/15/2019 3:13 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally migrated some tests that used the old test helpers to use 
> the new test helpers.
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232279
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8232279/webrev.00/
>

From alexander.matveev at oracle.com  Tue Oct 15 21:57:53 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 15 Oct 2019 14:57:53 -0700
Subject: RFR: JDK-8231862: Decouple DesktopIntegration and
 LinuxPackageBundler classes
In-Reply-To: <0321e3a8-59d4-0c70-bd9f-2cf7e1d4cb7b@oracle.com>
References: <1f86c31d-c8c3-96c0-d375-0847f8dcdfe0@oracle.com>
 <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>
 <0321e3a8-59d4-0c70-bd9f-2cf7e1d4cb7b@oracle.com>
Message-ID: <e292f1f2-4039-b393-3893-f8979bf8554c@oracle.com>

Looks good.

On 10/15/2019 12:27 PM, Andy Herrick wrote:
> A long overdue change.? Looks good as far as I can see.
>
> Thanks
>
> /Andy
>
> On 10/15/2019 2:48 PM, Alexey Semenyuk wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231862
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8231862/webrev.00/
>>


From alexander.matveev at oracle.com  Tue Oct 15 22:14:38 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 15 Oct 2019 15:14:38 -0700
Subject: RFR: JDK-8232279: Improve test helpers #2
In-Reply-To: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
References: <ad3f650b-d25b-7517-36f6-8d2b64a1ace9@oracle.com>
 <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
Message-ID: <86151de8-43b1-9539-7363-0a2707c6c301@oracle.com>

Looks good.

On 10/15/2019 12:13 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally migrated some tests that used the old test helpers to use 
> the new test helpers.
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232279
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8232279/webrev.00/
>


From galileo.sartor at gmail.com  Tue Oct 15 16:58:28 2019
From: galileo.sartor at gmail.com (Galileo Sartor)
Date: Tue, 15 Oct 2019 18:58:28 +0200
Subject: jpackage deb: copyright not set in DEBIAN folder
Message-ID: <ebf3ec1826def0e115b067d85e5e29fdc07153d9.camel@gmail.com>

Hi.
If I add the copyright template in the resource-dir folder
the file is correctly setup with the proper data and copied in
/opt/<appname>/share/doc/
It is not copied in DEBIAN/ in the deb package, so the app
store/installers will not be able to determine the correct license.
Is there some option to copy over this file or should this happen
automatically?

Thanks,
Galileo Sartor


From huaming.li at oracle.com  Wed Oct 16 01:02:55 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 16 Oct 2019 09:02:55 +0800
Subject: RFR of JDK-8134599: Improve the code coverage for ThreadLocal
In-Reply-To: <e04387a2-9a44-6e3f-7046-4900de7bb8ca@oracle.com>
References: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com>
 <cfea0a07-d378-5415-11c7-1140e43e97b2@oracle.com>
 <e04387a2-9a44-6e3f-7046-4900de7bb8ca@oracle.com>
Message-ID: <ece7e7fb-f7c0-11c2-f60b-b4b1673ca596@oracle.com>

Thanks Alan, I will add the @modules.

Please let me know your further comments, I haven't push the code yet.

Thank you

-Hamlin

On 2019/10/15 9:46 PM, Alan Bateman wrote:
> On 15/10/2019 03:03, Hamlin Li wrote:
>> Could some help to review it?
> I haven't studied the test but one thing that seems to be missing is 
> @modules java.base/java.lang:+open to allow the test access TL 
> internals. This will be needed once java.base is fully encapsulated.
>
> -Alan

From huaming.li at oracle.com  Wed Oct 16 01:17:44 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 16 Oct 2019 09:17:44 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <BE7E98B0-67AE-4132-99C5-62843E0B52AA@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
 <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
 <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>
 <3fbb7fc3-141e-cadf-2479-4c4183e17624@oracle.com>
 <BE7E98B0-67AE-4132-99C5-62843E0B52AA@oracle.com>
Message-ID: <f39b9b34-d1bd-d847-bc2c-5e5a7026216b@oracle.com>


On 2019/10/15 7:50 PM, Weijun Wang wrote:
>
>> On Oct 15, 2019, at 5:44 PM, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>>
>> On 2019/10/15 2:44 PM, Weijun Wang wrote:
>>> I am OK with the change that makes this test more robust.
>> Thanks Max.
>>> However, I am not an expert in RMI and don't know why the port cannot be released. If verifyPortFree(PORT) on line 60 can always succeed right after TestLibrary.getUnusedRandomPort() tries to create a ServerSocket at PORT and close it, this means the OS underneath spends no time in freeing the port.
>> No, the port is not freed here, it's only freed by unexportObject.
> I meant the auto close inside getUnusedRandomPort().

I think you misunderstood the 2 operations: socket.close and unexportObject.

As I mentioned below, unexportObject is an async operation, here "async" 
is in the RMI level: unexportObject => async close => socket.close => closed

>
>> But the original code is a little bit faulty at verifyPortInUse, it should be as below, I have also updated the webrev in place: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>
>> @@ -101,6 +112,7 @@
>>       private static void verifyPortInUse(int port) throws IOException {
>>           try {
>>               verifyPortFree(port);
>> +            throw new RuntimeException("port is not in use: " + port);
>>
>>> Is UnicastRemoteObject.unexportObject() also doing something similar? I see that the ServerSocket inside is closed on TCPTransport.java:280. Is it reliably called?
>> In my understanding, it's not a sync operation, it's async, that means when unexportObject returns, it just triggers the port release, does not mean it already released the port.
> Ah....
>
>>> Even after this bug is resolved, I'd suggest add some logging and rerun this test unchanged multiple times to see what really happened.
>> Unfortunately, most of time this kind of issue is not easy to reproduce by running it multiple times. In my point of view, current logging is sufficient for diagnosing.
> I see some logging calls inside source code. Maybe you can set a logging config file to let it show more?

I'm not sure I get your point, could you help to clarify?

Thank you

-Hamlin

>
> --Max
>
>> Thank you
>>
>> -Hamlin
>>
>>> --Max
>>>
>>>
>>>> On Oct 15, 2019, at 11:04 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>>>
>>>> Thanks for reviewing, I updated change at: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>>>
>>>> it does not increase minimum time time and consider timeout factor at the same time.
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>

From weijun.wang at oracle.com  Wed Oct 16 01:26:41 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 16 Oct 2019 09:26:41 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <f39b9b34-d1bd-d847-bc2c-5e5a7026216b@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
 <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
 <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>
 <3fbb7fc3-141e-cadf-2479-4c4183e17624@oracle.com>
 <BE7E98B0-67AE-4132-99C5-62843E0B52AA@oracle.com>
 <f39b9b34-d1bd-d847-bc2c-5e5a7026216b@oracle.com>
Message-ID: <5824D361-EBF9-4D75-97BB-A99752BC3429@oracle.com>



> On Oct 16, 2019, at 9:17 AM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> 
> On 2019/10/15 7:50 PM, Weijun Wang wrote:
>> 
>>> On Oct 15, 2019, at 5:44 PM, Hamlin Li <huaming.li at oracle.com> wrote:
>>> 
>>> 
>>> On 2019/10/15 2:44 PM, Weijun Wang wrote:
>>>> I am OK with the change that makes this test more robust.
>>> Thanks Max.
>>>> However, I am not an expert in RMI and don't know why the port cannot be released. If verifyPortFree(PORT) on line 60 can always succeed right after TestLibrary.getUnusedRandomPort() tries to create a ServerSocket at PORT and close it, this means the OS underneath spends no time in freeing the port.
>>> No, the port is not freed here, it's only freed by unexportObject.
>> I meant the auto close inside getUnusedRandomPort().
> 
> I think you misunderstood the 2 operations: socket.close and unexportObject.
> 
> As I mentioned below, unexportObject is an async operation, here "async" is in the RMI level: unexportObject => async close => socket.close => closed

Before you told me about the async mode, I was wondering maybe on some OS you cannot start listening on a port again *right after* closing a socket using this port. But from what happens in getUnusedRandomPort() this should not be true, and thus I suspected if socket is reliably closed. Now I understand this is because of the async mode.

> 
>> 
>>> But the original code is a little bit faulty at verifyPortInUse, it should be as below, I have also updated the webrev in place: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>> 
>>> @@ -101,6 +112,7 @@
>>>      private static void verifyPortInUse(int port) throws IOException {
>>>          try {
>>>              verifyPortFree(port);
>>> +            throw new RuntimeException("port is not in use: " + port);
>>> 
>>>> Is UnicastRemoteObject.unexportObject() also doing something similar? I see that the ServerSocket inside is closed on TCPTransport.java:280. Is it reliably called?
>>> In my understanding, it's not a sync operation, it's async, that means when unexportObject returns, it just triggers the port release, does not mean it already released the port.
>> Ah....
>> 
>>>> Even after this bug is resolved, I'd suggest add some logging and rerun this test unchanged multiple times to see what really happened.
>>> Unfortunately, most of time this kind of issue is not easy to reproduce by running it multiple times. In my point of view, current logging is sufficient for diagnosing.
>> I see some logging calls inside source code. Maybe you can set a logging config file to let it show more?
> 
> I'm not sure I get your point, could you help to clarify?

For example, in src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java, there is

if (DGCImpl.dgcLog.isLoggable(Log.VERBOSE)) {
    DGCImpl.dgcLog.log(Log.VERBOSE, "remove object " + oe);
}

So it looks it supports logging. Maybe you can provide a logging config file with -Djava.util.logging.config.file and see more info.

Thanks,
Max

> 
> Thank you
> 
> -Hamlin
> 
>> 
>> --Max
>> 
>>> Thank you
>>> 
>>> -Hamlin
>>> 
>>>> --Max
>>>> 
>>>> 
>>>>> On Oct 15, 2019, at 11:04 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>>>> 
>>>>> Thanks for reviewing, I updated change at: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>>>> 
>>>>> it does not increase minimum time time and consider timeout factor at the same time.
>>>>> 
>>>>> Thank you
>>>>> 
>>>>> -Hamlin


From joe.darcy at oracle.com  Wed Oct 16 01:31:40 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 15 Oct 2019 18:31:40 -0700
Subject: [JDK 14] RFR 8232195: Enable BigInteger tests: DivisionOverflow, 
 SymmetricRangeTests and StringConstructorOverflow
In-Reply-To: <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>
References: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>
 <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>
Message-ID: <f47fa9f9-c8a2-3e3b-c28d-8a484b854eaa@oracle.com>

Hello,

How long to the tests take to run when they actually run?

(It would be helpful to have a setting in jtreg that could indicate "its 
okay to run the slow tests" or "run the more extensive set of test 
vectors," but we haven't defined such a mechanism as of yet.)

Thanks,

-Joe

On 10/15/2019 8:33 AM, Brian Burkhalter wrote:
> Hi Amy,
>
> This looks OK. It looks like DivisionOverflow was already being run however.
>
> Also, the navigation in your webrev is broken: is your script current?
>
> Thanks,
>
> Brian
>
>> On Oct 14, 2019, at 10:05 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> test/jdk/java/math/BigInteger/DivisionOverflow.java
>> test/jdk/java/math/BigInteger/StringConstructorOverflow.java
>> test/jdk/java/math/BigInteger/SymmetricRangeTests.java
>>
>> These tests require huge memory and need to run with -Xmx8g
>> They are skipped or tagged with @ignore and not actually run in standard testing by jtreg.
>>
>> Please review the patch to enable them by:
>> * Adding @requires os.maxMemory > 8g
>> * Put them into exclusiveAccess.dirs (so they won't run concurrently) to reduce the risk of impact other test.
>>
>> Tested on all platforms with small (<8g) or large memory machines.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8232195 <https://bugs.openjdk.java.net/browse/JDK-8232195>
>> webrev: http://cr.openjdk.java.net/~amlu/8232195/webrev.00/ <http://cr.openjdk.java.net/~amlu/8232195/webrev.00/>

From huaming.li at oracle.com  Wed Oct 16 01:37:54 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 16 Oct 2019 09:37:54 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <5824D361-EBF9-4D75-97BB-A99752BC3429@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
 <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
 <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>
 <3fbb7fc3-141e-cadf-2479-4c4183e17624@oracle.com>
 <BE7E98B0-67AE-4132-99C5-62843E0B52AA@oracle.com>
 <f39b9b34-d1bd-d847-bc2c-5e5a7026216b@oracle.com>
 <5824D361-EBF9-4D75-97BB-A99752BC3429@oracle.com>
Message-ID: <08782355-42ef-6bf9-5bfc-21e634d8a8c5@oracle.com>


On 2019/10/16 9:26 AM, Weijun Wang wrote:

>>>>> Even after this bug is resolved, I'd suggest add some logging and rerun this test unchanged multiple times to see what really happened.
>>>> Unfortunately, most of time this kind of issue is not easy to reproduce by running it multiple times. In my point of view, current logging is sufficient for diagnosing.
>>> I see some logging calls inside source code. Maybe you can set a logging config file to let it show more?
>> I'm not sure I get your point, could you help to clarify?
> For example, in src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java, there is
>
> if (DGCImpl.dgcLog.isLoggable(Log.VERBOSE)) {
>      DGCImpl.dgcLog.log(Log.VERBOSE, "remove object " + oe);
> }
>
> So it looks it supports logging. Maybe you can provide a logging config file with -Djava.util.logging.config.file and see more info.

Good point, I think we can do further: add logging for not just this 
tests, but for other frequently failed rmi tests.

But as this is failing so frequently we need a quick fix or have to 
problemlist it first, so I just created a bug to track this enhancement: 
https://bugs.openjdk.java.net/browse/JDK-8232352, how do you think about it?

Thank you

-Hamlin

>
> Thanks,
> Max
>
>> Thank you
>>
>> -Hamlin
>>
>>> --Max
>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>
>>>>> --Max
>>>>>
>>>>>
>>>>>> On Oct 15, 2019, at 11:04 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>>>>>
>>>>>> Thanks for reviewing, I updated change at: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>>>>>
>>>>>> it does not increase minimum time time and consider timeout factor at the same time.
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> -Hamlin

From weijun.wang at oracle.com  Wed Oct 16 01:53:52 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 16 Oct 2019 09:53:52 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <08782355-42ef-6bf9-5bfc-21e634d8a8c5@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <d0faa77d-cda9-5151-665a-130f099a365b@oracle.com>
 <1cd9d478-ff76-9913-b653-b0bc139c56f6@oracle.com>
 <4257D373-B55A-415C-8E63-DD678E7E8068@oracle.com>
 <3fbb7fc3-141e-cadf-2479-4c4183e17624@oracle.com>
 <BE7E98B0-67AE-4132-99C5-62843E0B52AA@oracle.com>
 <f39b9b34-d1bd-d847-bc2c-5e5a7026216b@oracle.com>
 <5824D361-EBF9-4D75-97BB-A99752BC3429@oracle.com>
 <08782355-42ef-6bf9-5bfc-21e634d8a8c5@oracle.com>
Message-ID: <A816FDFA-E63D-4EAA-A975-DDBF9166B823@oracle.com>



> On Oct 16, 2019, at 9:37 AM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> 
> On 2019/10/16 9:26 AM, Weijun Wang wrote:
> 
>>>>>> Even after this bug is resolved, I'd suggest add some logging and rerun this test unchanged multiple times to see what really happened.
>>>>> Unfortunately, most of time this kind of issue is not easy to reproduce by running it multiple times. In my point of view, current logging is sufficient for diagnosing.
>>>> I see some logging calls inside source code. Maybe you can set a logging config file to let it show more?
>>> I'm not sure I get your point, could you help to clarify?
>> For example, in src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java, there is
>> 
>> if (DGCImpl.dgcLog.isLoggable(Log.VERBOSE)) {
>>     DGCImpl.dgcLog.log(Log.VERBOSE, "remove object " + oe);
>> }
>> 
>> So it looks it supports logging. Maybe you can provide a logging config file with -Djava.util.logging.config.file and see more info.
> 
> Good point, I think we can do further: add logging for not just this tests, but for other frequently failed rmi tests.
> 
> But as this is failing so frequently we need a quick fix or have to problemlist it first, so I just created a bug to track this enhancement: https://bugs.openjdk.java.net/browse/JDK-8232352, how do you think about it?

Not problem.

Thanks,
Max

> 
> Thank you
> 
> -Hamlin
> 
>> 
>> Thanks,
>> Max
>> 
>>> Thank you
>>> 
>>> -Hamlin
>>> 
>>>> --Max
>>>> 
>>>>> Thank you
>>>>> 
>>>>> -Hamlin
>>>>> 
>>>>>> --Max
>>>>>> 
>>>>>> 
>>>>>>> On Oct 15, 2019, at 11:04 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>>>>>> 
>>>>>>> Thanks for reviewing, I updated change at: http://cr.openjdk.java.net/~mli/8134599/webrev.01/
>>>>>>> 
>>>>>>> it does not increase minimum time time and consider timeout factor at the same time.
>>>>>>> 
>>>>>>> Thank you
>>>>>>> 
>>>>>>> -Hamlin


From huaming.li at oracle.com  Wed Oct 16 05:28:57 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 16 Oct 2019 13:28:57 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <6af6ea0d-c5cf-377c-8080-23dae4e8cada@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <1c0c9532-02bf-1a6d-baeb-8eac50e0311b@oracle.com>
 <6af6ea0d-c5cf-377c-8080-23dae4e8cada@oracle.com>
Message-ID: <4f137c57-8030-34a0-d363-f2a52afcd455@oracle.com>

Thanks Roger, sorry for that I missed your response. (most of time I 
focus on mail send to/cc me :) )

On 2019/10/15 10:29 PM, Roger Riggs wrote:
> Hi,
>
> 1. Replace the creation of the Registry with 
> TestLibrary.crateRegistryOnEphemeralPort
> and call TestLibrary.getRegistryPort to get the port number.
>
> The intent of the test is still satisified without the timing/port 
> allocation issues.

For this test, it failed only after unexportObject is called and port is 
not freed in time or occupied again by others.

So it would be fine to use crateRegistryOnEphemeralPort but will not 
help to resolve this issue.

>
> 2. Another approach to testing if the port is in use would be to
> assume its still active and do a registry.lookup("xxx").
>
> The response be NotBoundException if the registry is still alive
> or will be a RemoteException indicating the port is closed.
>
> If some other application has grabbed the port, some other exception 
> RemoteException cause will be thrown.

I'm not sure if RemoteException equals to the port has been closed by 
the registry.

Based on API doc, "|RemoteException 
<https://docs.oracle.com/en/java/javase/12/docs/api/java.rmi/java/rmi/RemoteException.html>|- 
if remote communication with the registry failed; if exception is 
a|ServerException|containing an|AccessException|, then the registry 
denies the caller access to perform this operation", in my 
understanding, a) "port is closed" and b) "others grab the port again" 
will cause RemoteException, but RemoteException does not mean it's in 
just one of the 2 situations a) and b).

Thank you

-Hamlin



From joe.darcy at oracle.com  Wed Oct 16 07:01:34 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 16 Oct 2019 00:01:34 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
 <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
Message-ID: <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>

Hi Martin,

On 10/15/2019 8:02 AM, Martin Buchholz wrote:
>
>
> On Mon, Oct 14, 2019 at 10:48 PM Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hi Martin,
>
>     On 10/14/2019 10:28 PM, Martin Buchholz wrote:
>>     Hi Joe,
>>
>>     I'm surprised there were so few changes.
>
>
>     The changes in question allow the java.util.concurrent package to
>     pass cleanly through the current version of my checks. Perhaps a
>     strong version of the checks in the future will flag more issues
>     of possible concern ;-)
>
>
>>
>>     Why are some of the Condition's marked // Conditionally serializable
>
>     Summarizing the discussion leading up to the changes for
>     JDK-8231913, "Conditionally serializable" describes collections
>     that are serializable iff their contents are serializable. The
>     changes made for
>
>     8231202: Suppress warnings on non-serializable non-transient
>     instance fields in serializable classes
>     http://hg.openjdk.java.net/jdk/jdk/rev/e036ee8bae56
>
>     use this terminology in the comments added for many collection
>     types, including Vector, TreeMap, and multiple implementation
>     classes in java.util.Collections. I tried to follow the same
>     pattern in java.util.concurrent where appropriate.
>
> The Condition field in ArrayBlockingQueue plays exactly the same role 
> as in e.g. LinkedBlockingQueue, so should have exactly the same treatment.


Changed the comments on the Condition-typed fields to

 ??? // Classes implementing Condition may be serializable.

Revised webrev at:

 ??? http://cr.openjdk.java.net/~darcy/8232230.1/

> ---
> All Condition implementations in OpenJDK are Serializable.
> In fact, we could promote all of those private Condition fields to 
> ConditionObject, making their Serializability clear, and then elide 
> the need for suppression.
>
> private final ConditionObject notEmpty = (ConditionObject) 
> takeLock.newCondition();
>
> (Why won't Java let me declare those fields private final Condition & 
> Serializable ?)
>
> but now we're drifting into actual user-meaningful development...? We 
> promise that ReentrantLock is serializable, but we don't seem to have 
> any such promise for Conditions returned 
> from?ReentrantLock.newCondition(), and we probably should.? Users are 
> implicitly relying on the Serializability of Condition in the same way 
> we are.


I've filed JDK-8232359: "Review type of fields in Serializable classes 
of java.util.concurrent" to track this potential future cleanup.


>
> ---
>
> Joe, go ahead and commit this to openjdk head when review is done.? 
> We'll incorporate.


Acknowledged; thanks,

-Joe


From christoph.langer at sap.com  Wed Oct 16 07:21:09 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 16 Oct 2019 07:21:09 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <1c8e1fe6-46ec-99b8-54f0-49070d461311@oracle.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <1c8e1fe6-46ec-99b8-54f0-49070d461311@oracle.com>
Message-ID: <AM6PR02MB48016CC043D0475DDE8171758A920@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi,

this item is really on  the edge between core-libs and hotspot. So I'm including both lists now.

The canonicalize() method is implemented in libjava, for both Unix and Windows. For Unix, it is used from hotspot, libjava (the file system implementations) and libinstrument. But for Windows, canonicalize isn't actually used at all by libjava any more after JDK-8190737 [0] since the WinNTFileSystem implementation uses wcanonicalize now.

Maybe this calls out for some further refactoring. One could move canonicalize completely into hotspot and use it from there. That would appear sensible to me but I don't know how the policy is for exporting methods from hotspot and consuming them in libjava. Alternatively, they could be kept at libjava but one has to know/keep in mind, that it is not used by the Windows java classlib implementation. If you say that it's the right way to go to move canonicalize into hotspot, I'd volunteer to bring this refactoring forward. Let me know.

But, apart from that possible refactoring, Ralf's change seems completely right to me. Also, using the hotspot test to verify the fix appears right. This test is a place where the functionality of Windows canonicalize is stressed and you won't find so many of them...

This fix seems a logical followup for JDK-8190737 [0] and JDK-8191521 [1].

Best regards
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8190737
[1] https://bugs.openjdk.java.net/browse/JDK-8191521


> On 15/10/2019 16:19, Schmelter, Ralf wrote:
> > Hello,
> >
> > this is a small change which fixes the some problems with the canonicalize()
> method in canonicalize_md.c.
> Can you split out the changes to the java.io into a separate issue and
> bring them to core-libs-dev to discuss? I suspect the changes will
> require a lot of review cycles.
> 
> -Alan
> 
> 
> > Currently it lets the wcanonicalize() method do the  work for path lengths >
> MAX_PATH. This change always calls the wcanonicalize() method, since the
> old implementation doesn't work for all path lengths <= MAX_PATH. In
> addition the canonicalizeWithPrefix() method has been removed, since it
> seems to be not used anymore.
> >
> > Bug report: https://bugs.openjdk.java.net/browse/JDK-8232168
> > Webrev:
> http://cr.openjdk.java.net/~rschmelter/webrevs/8232168/webrev.0/
> >
> > Best regards,
> > Ralf


From ralf.schmelter at sap.com  Wed Oct 16 08:28:40 2019
From: ralf.schmelter at sap.com (Schmelter, Ralf)
Date: Wed, 16 Oct 2019 08:28:40 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
Message-ID: <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>

Hi David,

the canonicalize() method is never used by java.io or any Java code. Currently it is used by the hotspot in classloader.cpp (which I use in the test) and in libinstrument in InvocationAdapter.c. There is no way to test it in core-libs. One can argue if the canonicalize method is in the right file, but that should be a separate discussion. 

Best regards,
Ralf

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Mittwoch, 16. Oktober 2019 05:59
To: Schmelter, Ralf <ralf.schmelter at sap.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows

Hi Ralf,

This isn't a hotspot issue but a core-libs one.

The use of a hotspot-runtime test seems more opportunistic than anything 
else - is it just for code coverage? I would expect to find a more 
appropriate test somewhere in core-libs.

Thanks,
David

From amy.lu at oracle.com  Wed Oct 16 09:49:37 2019
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 16 Oct 2019 17:49:37 +0800
Subject: [JDK 14] RFR 8232195: Enable BigInteger tests: DivisionOverflow, 
 SymmetricRangeTests and StringConstructorOverflow
In-Reply-To: <f47fa9f9-c8a2-3e3b-c28d-8a484b854eaa@oracle.com>
References: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>
 <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>
 <f47fa9f9-c8a2-3e3b-c28d-8a484b854eaa@oracle.com>
Message-ID: <d8b3b9ab-952d-da92-527d-ea313add7892@oracle.com>

Hi, Joe

I checked the elapsed time:

DivisionOverflow.java????????? <10 seconds? (normally 3 seconds)
StringConstructorOverflow.java <20 seconds? (normally 8 seconds)
SymmetricRangeTests.java?????? <100 seconds (normally 60-80 seconds)

I think it's fine and worth to enable them in standard testing. I'll 
continue monitor the results and make necessary adjustment if they cause 
any issue.

Any concerns? Please let me know.

Thanks,
Amy

On 10/16/19 9:31 AM, Joe Darcy wrote:
> Hello,
>
> How long to the tests take to run when they actually run?
>
> (It would be helpful to have a setting in jtreg that could indicate 
> "its okay to run the slow tests" or "run the more extensive set of 
> test vectors," but we haven't defined such a mechanism as of yet.)
>
> Thanks,
>
> -Joe
>
> On 10/15/2019 8:33 AM, Brian Burkhalter wrote:
>> Hi Amy,
>>
>> This looks OK. It looks like DivisionOverflow was already being run 
>> however.
>>
>> Also, the navigation in your webrev is broken: is your script current?
>>
>> Thanks,
>>
>> Brian
>>
>>> On Oct 14, 2019, at 10:05 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>
>>> test/jdk/java/math/BigInteger/DivisionOverflow.java
>>> test/jdk/java/math/BigInteger/StringConstructorOverflow.java
>>> test/jdk/java/math/BigInteger/SymmetricRangeTests.java
>>>
>>> These tests require huge memory and need to run with -Xmx8g
>>> They are skipped or tagged with @ignore and not actually run in 
>>> standard testing by jtreg.
>>>
>>> Please review the patch to enable them by:
>>> * Adding @requires os.maxMemory > 8g
>>> * Put them into exclusiveAccess.dirs (so they won't run 
>>> concurrently) to reduce the risk of impact other test.
>>>
>>> Tested on all platforms with small (<8g) or large memory machines.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232195 
>>> <https://bugs.openjdk.java.net/browse/JDK-8232195>
>>> webrev: http://cr.openjdk.java.net/~amlu/8232195/webrev.00/ 
>>> <http://cr.openjdk.java.net/~amlu/8232195/webrev.00/>


From amy.lu at oracle.com  Wed Oct 16 09:50:07 2019
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 16 Oct 2019 17:50:07 +0800
Subject: [JDK 14] RFR 8232195: Enable BigInteger tests: DivisionOverflow, 
 SymmetricRangeTests and StringConstructorOverflow
In-Reply-To: <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>
References: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>
 <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>
Message-ID: <b19010cc-817f-876e-631e-091991ca0eff@oracle.com>

Thank you Brian for reviewing and reminder.

Updated webrev script and re-generated (no code change compare to 
webrev.00):
http://cr.openjdk.java.net/~amlu/8232195/webrev.01

Thanks,
Amy

On 10/15/19 11:33 PM, Brian Burkhalter wrote:
> Hi Amy,
>
> This looks OK. It looks like DivisionOverflow was already being run 
> however.
>
> Also, the navigation in your webrev is broken: is your script current?
>
> Thanks,
>
> Brian
>
>> On Oct 14, 2019, at 10:05 PM, Amy Lu <amy.lu at oracle.com 
>> <mailto:amy.lu at oracle.com>> wrote:
>>
>> test/jdk/java/math/BigInteger/DivisionOverflow.java
>> test/jdk/java/math/BigInteger/StringConstructorOverflow.java
>> test/jdk/java/math/BigInteger/SymmetricRangeTests.java
>>
>> These tests require huge memory and need to run with -Xmx8g
>> They are skipped or tagged with @ignore and not actually run in 
>> standard testing by jtreg.
>>
>> Please review the patch to enable them by:
>> * Adding @requires os.maxMemory > 8g
>> * Put them into exclusiveAccess.dirs (so they won't run concurrently) 
>> to reduce the risk of impact other test.
>>
>> Tested on all platforms with small (<8g) or large memory machines.
>>
>> bug:https://bugs.openjdk.java.net/browse/JDK-8232195
>> webrev:http://cr.openjdk.java.net/~amlu/8232195/webrev.00/
>


From jan.lahoda at oracle.com  Wed Oct 16 12:50:56 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 16 Oct 2019 14:50:56 +0200
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
 <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
Message-ID: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>

Hi,

An updated patch is here:
http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/

Changes in the update:
-added the dependency into the makefiles
-loosened the handling of essential preview APIs when --enable-preview 
and @SuppressWarnings is applied - there is no warning for the essential 
APIs (as there is no warning in such a case for non-essential APIs). 
This is per the discussion in the CSR:
https://bugs.openjdk.java.net/browse/JDK-8231411

Any comments/feedback on this?

Thanks!
     Jan

On 09. 10. 19 17:41, Erik Joelsson wrote:
> Oh, you are absolutely correct, the dependency is missing.
> 
> We need something like this inside "define SetupInterimModule":
> 
> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
> 
> /Erik
> 
> On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
>> I can?t see how the compilation is dependent on the copy being 
>> finished. Since Erik contributed this it will probably be correct :) 
>> but I?d appreciate an explanation on how this dependency is guaranteed.
>>
>> Or maybe I?m misunderstanding what this is supposed to do?
>>
>> /Magnus
>>
>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
>>>
>>> Thanks for the new code Erik!
>>>
>>> A new webrev/patch that includes this better way of copying is here:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>>>
>>> Any feedback is welcome!
>>>
>>> Thanks,
>>> ??? Jan
>>>
>>>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>>>> Hello Jan,
>>>> The build change looks ok, but I would recommend this construct for 
>>>> copying the file instead:
>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>>> ???? FILES := 
>>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, 
>>>> \
>>>> ???? DEST := 
>>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, 
>>>> \
>>>> ))
>>>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>>> Then you automatically get all the corner case handling we have 
>>>> implemented over the years for logging, making directories and 
>>>> copying files. Your version is still correct for this case though.
>>>> /Erik
>>>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> This is a continuation of Joe's patch from here:
>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>>>>
>>>>>
>>>>> APIs associated with preview features are split into two groups: 
>>>>> essential and non-essential. These are marked with an JDK-internal 
>>>>> annotation, PreviewFeature, and a tag in the javadoc, @preview. The 
>>>>> javac follows the PreviewFeature annotation, and produces either 
>>>>> warnings or errors for the usages of such APIs. For the @preview 
>>>>> tag, there is a taglet in the JDK build that adds the content of 
>>>>> the tag into the documentation. The first part of the @preview's 
>>>>> text goes into the summary, the second part goes into the detailed 
>>>>> description.
>>>>>
>>>>> For build, a tricky problem is that the jdk.compiler module uses 
>>>>> the PreviewFeature annotation as well, but that is not in the 
>>>>> bootstrap JDK. So, for the intermediate langtools build, the 
>>>>> PreviewFeature annotation is copied from java.base.
>>>>>
>>>>> Proposed webrev:
>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>>>
>>>>> Javadoc with the change:
>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>>>
>>>>> See for example:
>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>>>>
>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>>>>
>>>>>
>>>>> JBS:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>>>
>>>>> CSR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>>>
>>>>> Feedback is welcome!
>>>>>
>>>>> Thanks,
>>>>> ???? Jan

From erik.joelsson at oracle.com  Wed Oct 16 12:55:12 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Oct 2019 05:55:12 -0700
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
 <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
 <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
Message-ID: <fc25e5d5-9584-2276-7f2f-5385448577fa@oracle.com>

Build change looks good now.

/Erik

On 2019-10-16 05:50, Jan Lahoda wrote:
> Hi,
>
> An updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/
>
> Changes in the update:
> -added the dependency into the makefiles
> -loosened the handling of essential preview APIs when --enable-preview 
> and @SuppressWarnings is applied - there is no warning for the 
> essential APIs (as there is no warning in such a case for 
> non-essential APIs). This is per the discussion in the CSR:
> https://bugs.openjdk.java.net/browse/JDK-8231411
>
> Any comments/feedback on this?
>
> Thanks!
> ??? Jan
>
> On 09. 10. 19 17:41, Erik Joelsson wrote:
>> Oh, you are absolutely correct, the dependency is missing.
>>
>> We need something like this inside "define SetupInterimModule":
>>
>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
>>
>> /Erik
>>
>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
>>> I can?t see how the compilation is dependent on the copy being 
>>> finished. Since Erik contributed this it will probably be correct :) 
>>> but I?d appreciate an explanation on how this dependency is guaranteed.
>>>
>>> Or maybe I?m misunderstanding what this is supposed to do?
>>>
>>> /Magnus
>>>
>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
>>>>
>>>> Thanks for the new code Erik!
>>>>
>>>> A new webrev/patch that includes this better way of copying is here:
>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>>>>
>>>> Any feedback is welcome!
>>>>
>>>> Thanks,
>>>> ??? Jan
>>>>
>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>>>>> Hello Jan,
>>>>> The build change looks ok, but I would recommend this construct 
>>>>> for copying the file instead:
>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>>>> ???? FILES := 
>>>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, 
>>>>> \
>>>>> ???? DEST := 
>>>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, 
>>>>> \
>>>>> ))
>>>>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>>>> Then you automatically get all the corner case handling we have 
>>>>> implemented over the years for logging, making directories and 
>>>>> copying files. Your version is still correct for this case though.
>>>>> /Erik
>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This is a continuation of Joe's patch from here:
>>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>>>>>
>>>>>>
>>>>>> APIs associated with preview features are split into two groups: 
>>>>>> essential and non-essential. These are marked with an 
>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the 
>>>>>> javadoc, @preview. The javac follows the PreviewFeature 
>>>>>> annotation, and produces either warnings or errors for the usages 
>>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK 
>>>>>> build that adds the content of the tag into the documentation. 
>>>>>> The first part of the @preview's text goes into the summary, the 
>>>>>> second part goes into the detailed description.
>>>>>>
>>>>>> For build, a tricky problem is that the jdk.compiler module uses 
>>>>>> the PreviewFeature annotation as well, but that is not in the 
>>>>>> bootstrap JDK. So, for the intermediate langtools build, the 
>>>>>> PreviewFeature annotation is copied from java.base.
>>>>>>
>>>>>> Proposed webrev:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>>>>
>>>>>> Javadoc with the change:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>>>>
>>>>>> See for example:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>>>>>
>>>>>>
>>>>>> JBS:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>>>>
>>>>>> CSR:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>>>>
>>>>>> Feedback is welcome!
>>>>>>
>>>>>> Thanks,
>>>>>> ???? Jan

From Roger.Riggs at oracle.com  Wed Oct 16 14:51:37 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 16 Oct 2019 10:51:37 -0400
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <4f137c57-8030-34a0-d363-f2a52afcd455@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <1c0c9532-02bf-1a6d-baeb-8eac50e0311b@oracle.com>
 <6af6ea0d-c5cf-377c-8080-23dae4e8cada@oracle.com>
 <4f137c57-8030-34a0-d363-f2a52afcd455@oracle.com>
Message-ID: <68ecc504-e37b-a638-83fe-4a34cbdab7a1@oracle.com>

Hi Hamlin,

Some additional logging that the socket has been closed might be useful 
in TCPTransport.java.

In particular,
 ?-? in the decrementExportCount() method
 ?-? in the closeSocket() method;


With respect to Asynchronous...

The call to unexport(force = true) is synchronous if the reference count 
decrements to zero.
So I'm a bit surprised that in this case there is an issue.

(I added printf of the thread invoking unexport and the code doing the 
ss.close(in TCPTransport)
and it was the same thread with the messages in order.)

The normal unexport(force = false) is async, since it needs the GC to 
determine
there are no references in the process and the ObjectTable.reaper thread
to decrement all the counts and close the socket.

The hard reference to Registry implementation in the CloseServerSocket test
shouldn't be an issue but depending on GC and optimizations, the GC may 
or may not
consider the value of the 'registry' variable to be alive after the call 
to unexportObject().
Setting it to null might remove that variable.

On 10/16/19 1:28 AM, Hamlin Li wrote:
>
> Thanks Roger, sorry for that I missed your response. (most of time I 
> focus on mail send to/cc me :) )
>
> On 2019/10/15 10:29 PM, Roger Riggs wrote:
>> Hi,
>>
>> 1. Replace the creation of the Registry with 
>> TestLibrary.crateRegistryOnEphemeralPort
>> and call TestLibrary.getRegistryPort to get the port number.
>>
>> The intent of the test is still satisified without the timing/port 
>> allocation issues.
>
> For this test, it failed only after unexportObject is called and port 
> is not freed in time or occupied again by others.
>
> So it would be fine to use createRegistryOnEphemeralPort but will not 
> help to resolve this issue.
>
ok, just cutting down on the variables
>
>>
>> 2. Another approach to testing if the port is in use would be to
>> assume its still active and do a registry.lookup("xxx").
>>
>> The response be NotBoundException if the registry is still alive
>> or will be a RemoteException indicating the port is closed.
>>
>> If some other application has grabbed the port, some other exception 
>> RemoteException cause will be thrown.
>
> I'm not sure if RemoteException equals to the port has been closed by 
> the registry.
>
> Based on API doc, "|RemoteException 
> <https://docs.oracle.com/en/java/javase/12/docs/api/java.rmi/java/rmi/RemoteException.html>|- 
> if remote communication with the registry failed; if exception is 
> a|ServerException|containing an|AccessException|, then the registry 
> denies the caller access to perform this operation", in my 
> understanding, a) "port is closed" and b) "others grab the port again" 
> will cause RemoteException, but RemoteException does not mean it's in 
> just one of the 2 situations a) and b).
>

I should have been more specific and to examine the exception that 
caused the RemoteException.
It should reflect the socket level error, if any.

Roger

> Thank you
>
> -Hamlin
>
>


From lance.andersen at oracle.com  Wed Oct 16 17:06:13 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 16 Oct 2019 13:06:13 -0400
Subject: RFR 8231451:  ZipFileInputStream::skip handling of negative values
 with STORED entries
Message-ID: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>

Hi all,

Please review this fix to ZipFileInputStream::skip when specifying a negative value to the skip method when accessing a STORED entry, https://bugs.openjdk.java.net/browse/JDK-8231451 <https://bugs.openjdk.java.net/browse/JDK-8231451>.  Prior to this fix, you could move past the beginning of the STORED entry.

I also added a release note, https://bugs.openjdk.java.net/browse/JDK-8232384 <https://bugs.openjdk.java.net/browse/JDK-8232384>, to help clarify the behavior of these methods when a negative value is specified.

The webrev can be found at: http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html>

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 alex.buckley at oracle.com  Wed Oct 16 17:45:08 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 16 Oct 2019 10:45:08 -0700
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
 <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
 <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
Message-ID: <07d16fc4-42a9-8f6f-992f-3ebc83e3e777@oracle.com>

On 10/16/2019 5:50 AM, Jan Lahoda wrote:
> -loosened the handling of essential preview APIs when --enable-preview 
> and @SuppressWarnings is applied - there is no warning for the essential 
> APIs (as there is no warning in such a case for non-essential APIs). 
> This is per the discussion in the CSR:
> https://bugs.openjdk.java.net/browse/JDK-8231411

Thank you for implementing this change so quickly. Per the discussion in 
the CSR, I have updated JEP 12 to allow suppression in the case above 
(see http://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs / 
second list / fourth bullet) and also the JLS RFE (JDK-8231433).

The interesting takeaway is that use of a preview language feature 
generates a non-suppressible warning (scan JEP 12 for "This message 
cannot be turned off") while use of an essential API element associated 
with a preview language feature generates a suppressible warning.

Alex

From andy.herrick at oracle.com  Wed Oct 16 20:03:19 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 16 Oct 2019 16:03:19 -0400
Subject: JDK-8232280: close() is not called on return value of Files.walk()
Message-ID: <32489c6e-70e8-a9ae-5051-bf382cdb0556@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

Fix is to wrap all Files.walk() calls in try-with-resource blocks.

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

[2] http://cr.openjdk.java.net/~herrick/8232280/webrev.01/

/Andy


From andy.herrick at oracle.com  Wed Oct 16 20:31:42 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 16 Oct 2019 16:31:42 -0400
Subject: RRF: JDK-8232280: close() is not called on return value of
 Files.walk()
In-Reply-To: <32489c6e-70e8-a9ae-5051-bf382cdb0556@oracle.com>
References: <32489c6e-70e8-a9ae-5051-bf382cdb0556@oracle.com>
Message-ID: <5765d9b5-5dab-c81e-b062-6683c770a72e@oracle.com>

fixing subject line ...

On 10/16/2019 4:03 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Fix is to wrap all Files.walk() calls in try-with-resource blocks.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232280
>
> [2] http://cr.openjdk.java.net/~herrick/8232280/webrev.01/
>
> /Andy
>

From alexander.matveev at oracle.com  Wed Oct 16 20:32:32 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 16 Oct 2019 13:32:32 -0700
Subject: JDK-8232280: close() is not called on return value of Files.walk()
In-Reply-To: <32489c6e-70e8-a9ae-5051-bf382cdb0556@oracle.com>
References: <32489c6e-70e8-a9ae-5051-bf382cdb0556@oracle.com>
Message-ID: <bd2667e4-f37a-aea7-8555-82546e045d35@oracle.com>

Hi Andy,

Looks good.

Thanks,
Alexander

On 10/16/2019 1:03 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Fix is to wrap all Files.walk() calls in try-with-resource blocks.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232280
>
> [2] http://cr.openjdk.java.net/~herrick/8232280/webrev.01/
>
> /Andy
>


From martinrb at google.com  Wed Oct 16 21:56:52 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Oct 2019 14:56:52 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
 <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
 <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>
Message-ID: <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>

I did another pass.

If there was a way for jsr166 maintainers to see these warnings, we could
more easily fix ourselves.  But there is no such thing as a "preview javac
warning", eh?
---
The comments for Condition declarations are still not consistent - every
one is known to be Serializable, but they cannot be declared Condition &
Serializable because Java does not have first-class support for
intersection types.  So just make all of these:
@SuppressWarnings("serial") // Not statically typed as Serializable

---
All of the suppressions in ForkJoinTask below should be
// Conditionally serializable
because serializability depends on user-supplied action, and T could be any
type.

--- old/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
2019-10-15 23:58:37.836743608 -0700
+++ new/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
2019-10-15 23:58:37.624743608 -0700
@@ -1374,7 +1374,9 @@
      */
     static final class AdaptedRunnable<T> extends ForkJoinTask<T>
         implements RunnableFuture<T> {
+        @SuppressWarnings("serial") // Not statically typed as Serializable
         final Runnable runnable;
+        @SuppressWarnings("serial") // Not statically typed as Serializable
         T result;
         AdaptedRunnable(Runnable runnable, T result) {
             if (runnable == null) throw new NullPointerException();
@@ -1396,6 +1398,7 @@
      */
     static final class AdaptedRunnableAction extends ForkJoinTask<Void>
         implements RunnableFuture<Void> {
+        @SuppressWarnings("serial") // Not statically typed as Serializable
         final Runnable runnable;
         AdaptedRunnableAction(Runnable runnable) {
             if (runnable == null) throw new NullPointerException();
@@ -1415,6 +1418,7 @@
      * Adapter for Runnables in which failure forces worker exception.
      */
     static final class RunnableExecuteAction extends ForkJoinTask<Void> {
+        @SuppressWarnings("serial") // Not statically typed as Serializable
         final Runnable runnable;
         RunnableExecuteAction(Runnable runnable) {
             if (runnable == null) throw new NullPointerException();
@@ -1434,7 +1438,9 @@
      */
     static final class AdaptedCallable<T> extends ForkJoinTask<T>
         implements RunnableFuture<T> {
+        @SuppressWarnings("serial") // Not statically typed as Serializable
         final Callable<? extends T> callable;
+        @SuppressWarnings("serial") // Not statically typed as Serializable
         T result;
         AdaptedCallable(Callable<? extends T> callable) {
             if (callable == null) throw new NullPointerException();

---
For Thread objects, I would say
// unlikely to be serializable
---
old/src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java
2019-10-15 23:58:40.460743608 -0700
+++
new/src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java
2019-10-15 23:58:40.256743608 -0700
@@ -604,8 +604,10 @@
         private static final long serialVersionUID = 6138294804551838833L;

         /** Thread this worker is running in.  Null if factory fails. */
+        @SuppressWarnings("serial") // Not statically typed as Serializable
         final Thread thread;
         /** Initial task to run.  Possibly null. */


On Wed, Oct 16, 2019 at 12:03 AM Joe Darcy <joe.darcy at oracle.com> wrote:

> Hi Martin,
> On 10/15/2019 8:02 AM, Martin Buchholz wrote:
>
>
>
> On Mon, Oct 14, 2019 at 10:48 PM Joe Darcy <joe.darcy at oracle.com> wrote:
>
>> Hi Martin,
>> On 10/14/2019 10:28 PM, Martin Buchholz wrote:
>>
>> Hi Joe,
>>
>> I'm surprised there were so few changes.
>>
>>
>> The changes in question allow the java.util.concurrent package to pass
>> cleanly through the current version of my checks. Perhaps a strong version
>> of the checks in the future will flag more issues of possible concern ;-)
>>
>>
>>
>> Why are some of the Condition's marked // Conditionally serializable
>>
>> Summarizing the discussion leading up to the changes for JDK-8231913, "Conditionally
>> serializable" describes collections that are serializable iff their
>> contents are serializable. The changes made for
>>
>> 8231202: Suppress warnings on non-serializable non-transient instance
>> fields in serializable classes
>> http://hg.openjdk.java.net/jdk/jdk/rev/e036ee8bae56
>>
>> use this terminology in the comments added for many collection types,
>> including Vector, TreeMap, and multiple implementation classes in
>> java.util.Collections. I tried to follow the same pattern in
>> java.util.concurrent where appropriate.
>>
> The Condition field in ArrayBlockingQueue plays exactly the same role as
> in e.g. LinkedBlockingQueue, so should have exactly the same treatment.
>
>
> Changed the comments on the Condition-typed fields to
>
>     // Classes implementing Condition may be serializable.
>
> Revised webrev at:
>
>     http://cr.openjdk.java.net/~darcy/8232230.1/
>
> ---
> All Condition implementations in OpenJDK are Serializable.
> In fact, we could promote all of those private Condition fields to
> ConditionObject, making their Serializability clear, and then elide the
> need for suppression.
>
> private final ConditionObject notEmpty = (ConditionObject)
> takeLock.newCondition();
>
> (Why won't Java let me declare those fields private final Condition &
> Serializable ?)
>
> but now we're drifting into actual user-meaningful development...  We
> promise that ReentrantLock is serializable, but we don't seem to have any
> such promise for Conditions returned from ReentrantLock.newCondition(), and
> we probably should.  Users are implicitly relying on the Serializability of
> Condition in the same way we are.
>
>
> I've filed JDK-8232359: "Review type of fields in Serializable classes of
> java.util.concurrent" to track this potential future cleanup.
>
>
>
> ---
>
> Joe, go ahead and commit this to openjdk head when review is done.  We'll
> incorporate.
>
>
> Acknowledged; thanks,
>
> -Joe
>

From andy.herrick at oracle.com  Wed Oct 16 22:04:44 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 16 Oct 2019 18:04:44 -0400
Subject: RRF: JDK-8232280: close() is not called on return value of
 Files.walk()
In-Reply-To: <5765d9b5-5dab-c81e-b062-6683c770a72e@oracle.com>
References: <32489c6e-70e8-a9ae-5051-bf382cdb0556@oracle.com>
 <5765d9b5-5dab-c81e-b062-6683c770a72e@oracle.com>
Message-ID: <01fee56d-e75f-58fe-5f9c-fd6c10442d93@oracle.com>

The webrev is modified in place to remove one file, and now passes build 
on all platforms.

/Andy

On 10/16/2019 4:31 PM, Andy Herrick wrote:
> fixing subject line ...
>
> On 10/16/2019 4:03 PM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> Fix is to wrap all Files.walk() calls in try-with-resource blocks.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232280
>>
>> [2] http://cr.openjdk.java.net/~herrick/8232280/webrev.01/
>>
>> /Andy
>>

From alexey.semenyuk at oracle.com  Wed Oct 16 22:19:07 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 16 Oct 2019 18:19:07 -0400
Subject: RRF: JDK-8232280: close() is not called on return value of
 Files.walk()
In-Reply-To: <01fee56d-e75f-58fe-5f9c-fd6c10442d93@oracle.com>
References: <32489c6e-70e8-a9ae-5051-bf382cdb0556@oracle.com>
 <5765d9b5-5dab-c81e-b062-6683c770a72e@oracle.com>
 <01fee56d-e75f-58fe-5f9c-fd6c10442d93@oracle.com>
Message-ID: <222f1960-b0e5-ce03-7a1b-26c5fd6e0394@oracle.com>

Looks good.

- Alexey

On 10/16/2019 6:04 PM, Andy Herrick wrote:
> The webrev is modified in place to remove one file, and now passes 
> build on all platforms.
>
> /Andy
>
> On 10/16/2019 4:31 PM, Andy Herrick wrote:
>> fixing subject line ...
>>
>> On 10/16/2019 4:03 PM, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> Fix is to wrap all Files.walk() calls in try-with-resource blocks.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232280
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8232280/webrev.01/
>>>
>>> /Andy
>>>


From joe.darcy at oracle.com  Wed Oct 16 22:56:49 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 16 Oct 2019 15:56:49 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
 <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
 <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>
 <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>
Message-ID: <0956dafa-385b-dd9d-64c4-f94d7497f0a0@oracle.com>

Hi Martin,

On 10/16/2019 2:56 PM, Martin Buchholz wrote:
> I did another pass.
>
> If there was a way for jsr166 maintainers to see these warnings, we 
> could more easily fix ourselves.? But there is no such thing as a 
> "preview javac warning", eh?

I could send you the annotation processor I'm using as a prototype, but 
the code isn't publicly visible anywhere as of yet.

(Given my background, it is easier for me to write an annotation 
processor as opposed to writing against the javac internal APIs, but the 
final lint check should use the internal APIs.)

> ---
> The comments for Condition?declarations are still not consistent - 
> every one is known to be Serializable, but they cannot be declared 
> Condition & Serializable because Java does not have first-class 
> support for intersection types.

FWIW, this code compiles in javac

 ??? public interface SerializableCondition extends Condition, 
Serializable {
 ??????? public static <C extends Condition & Serializable>
 ???????????????????????????????? SerializableCondition transform(C 
condition) {
 ??????????? return condition;
 ??????? }
 ??? }

and objects of existing types like 
AbstractQueuedLongSynchronizer.ConditionObject seem to get "converted" 
as desired.


> So just make all of these:
> @SuppressWarnings("serial") // Not statically typed as Serializable

I'll push with the amendments below.

Thanks,

-Joe


>
> ---
> All of the suppressions in ForkJoinTask below should be
> // Conditionally serializable
> because serializability depends on user-supplied action, and T could 
> be any type.
// Remainder elided...

From martinrb at google.com  Wed Oct 16 23:39:36 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Oct 2019 16:39:36 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <0956dafa-385b-dd9d-64c4-f94d7497f0a0@oracle.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
 <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
 <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>
 <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>
 <0956dafa-385b-dd9d-64c4-f94d7497f0a0@oracle.com>
Message-ID: <CA+kOe0_pS7qR0=6MkL-bKRpFBtAqhHC-AmRnhMCoP80M3QYXhQ@mail.gmail.com>

On Wed, Oct 16, 2019 at 3:56 PM Joe Darcy <joe.darcy at oracle.com> wrote:

>
> > The comments for Condition declarations are still not consistent -
> > every one is known to be Serializable, but they cannot be declared
> > Condition & Serializable because Java does not have first-class
> > support for intersection types.
>
> FWIW, this code compiles in javac
>
>      public interface SerializableCondition extends Condition,
> Serializable {
>          public static <C extends Condition & Serializable>
>                                   SerializableCondition transform(C
> condition) {
>              return condition;
>          }
>      }
>
> and objects of existing types like
> AbstractQueuedLongSynchronizer.ConditionObject seem to get "converted"
> as desired.
>

Here's another point of view of the same problem:
 https://blog.codefx.org/java/intersection-types-var/

From alexey.semenyuk at oracle.com  Wed Oct 16 23:56:26 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 16 Oct 2019 19:56:26 -0400
Subject: RFR: JDK-8232387:
 tools/jpackage/share/jdk/jpackage/tests/BasicTest.java fails
In-Reply-To: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
References: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
Message-ID: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

Additionally regression in JPackageCommand class fixed.

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8232387/webrev.00/


From martinrb at google.com  Thu Oct 17 01:11:23 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Oct 2019 18:11:23 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <0956dafa-385b-dd9d-64c4-f94d7497f0a0@oracle.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
 <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
 <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>
 <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>
 <0956dafa-385b-dd9d-64c4-f94d7497f0a0@oracle.com>
Message-ID: <CA+kOe094QjsWf9WhywF3n9maj6Q6t6SEb7DufgsBu2fj+dDuhw@mail.gmail.com>

On Wed, Oct 16, 2019 at 3:56 PM Joe Darcy <joe.darcy at oracle.com> wrote:

>
> FWIW, this code compiles in javac
>
>      public interface SerializableCondition extends Condition,
> Serializable {
>          public static <C extends Condition & Serializable>
>                                   SerializableCondition transform(C
> condition) {
>              return condition;
>          }
>      }
>
> and objects of existing types like
> AbstractQueuedLongSynchronizer.ConditionObject seem to get "converted"
> as desired.
>
>
I actually tried this ...
---
import java.io.Serializable;
import java.util.concurrent.locks.Condition;

public interface SerializableCondition
    extends Condition, Serializable {
    public static <C extends Condition & Serializable>
      SerializableCondition transform(C condition) {
        return condition;
    }
}
---
... and got:

==> javac -source 14 -Xlint:all SerializableCondition.java
SerializableCondition.java:8: error: incompatible types: C cannot be
converted to SerializableCondition
        return condition;
               ^
  where C is a type-variable:
    C extends Condition,Serializable declared in method <C>transform(C)
1 error

From alexander.matveev at oracle.com  Thu Oct 17 01:21:44 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 16 Oct 2019 18:21:44 -0700
Subject: RFR: JDK-8232387:
 tools/jpackage/share/jdk/jpackage/tests/BasicTest.java fails
In-Reply-To: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
References: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
 <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
Message-ID: <cc64a6e6-e466-ede5-b49d-7ccd5f41170a@oracle.com>

Looks good.

On 10/16/2019 4:56 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally regression in JPackageCommand class fixed.
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232387
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8232387/webrev.00/
>


From aditya.s at outlook.com  Thu Oct 17 03:12:42 2019
From: aditya.s at outlook.com (Aditya Srinivasan)
Date: Thu, 17 Oct 2019 03:12:42 +0000
Subject: Typo in a java base javadoc
In-Reply-To: <cc64a6e6-e466-ede5-b49d-7ccd5f41170a@oracle.com>
References: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
 <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
 <cc64a6e6-e466-ede5-b49d-7ccd5f41170a@oracle.com>
Message-ID: <95A80D9E-F284-45DB-B004-A95666C60B1F@outlook.com>

Hi there, I?m sending this message to this mailing list after receiving guidance from Dalibor Topic. I found a typo in a java.base class and wanted to know how I should go about making contributions to it. I hope this is the right channel to bring this up.

Aditya Srinivasan

From huaming.li at oracle.com  Thu Oct 17 05:41:31 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 17 Oct 2019 13:41:31 +0800
Subject: RFR of JDK-8134599: TEST_BUG:
 java/rmi/transport/closeServerSocket/CloseServerSocket.java fails
 intermittently with Address already in use
In-Reply-To: <68ecc504-e37b-a638-83fe-4a34cbdab7a1@oracle.com>
References: <d2e6514c-6b64-14d2-455c-9d4440ddadae@oracle.com>
 <fd7fafdd-06a9-4e62-94d4-b8908946b63b@oracle.com>
 <9c362028-6992-4933-3081-7da7975fa410@oracle.com>
 <B830D0FF-71B2-4FA5-8BF0-F6BE58DD5BAE@oracle.com>
 <1c0c9532-02bf-1a6d-baeb-8eac50e0311b@oracle.com>
 <6af6ea0d-c5cf-377c-8080-23dae4e8cada@oracle.com>
 <4f137c57-8030-34a0-d363-f2a52afcd455@oracle.com>
 <68ecc504-e37b-a638-83fe-4a34cbdab7a1@oracle.com>
Message-ID: <c8cf8855-c65a-a08e-1fe9-f1fb188e8152@oracle.com>

Thanks Roger!

On 2019/10/16 10:51 PM, Roger Riggs wrote:
> Hi Hamlin,
>
> Some additional logging that the socket has been closed might be 
> useful in TCPTransport.java.
>
> In particular,
> ?-? in the decrementExportCount() method
> ?-? in the closeSocket() method;
I agree, just created https://bugs.openjdk.java.net/browse/JDK-8232446 
to track this enhancement.
>
>
> With respect to Asynchronous...
>
> The call to unexport(force = true) is synchronous if the reference 
> count decrements to zero.
> So I'm a bit surprised that in this case there is an issue.
>
> (I added printf of the thread invoking unexport and the code doing the 
> ss.close(in TCPTransport)
> and it was the same thread with the messages in order.)
>
> The normal unexport(force = false) is async, since it needs the GC to 
> determine
> there are no references in the process and the ObjectTable.reaper thread
> to decrement all the counts and close the socket.
>
> The hard reference to Registry implementation in the CloseServerSocket 
> test
> shouldn't be an issue but depending on GC and optimizations, the GC 
> may or may not
> consider the value of the 'registry' variable to be alive after the 
> call to unexportObject().
> Setting it to null might remove that variable.

Thanks for the information.

I think it will be more clear when JDK-8232446 
<https://bugs.openjdk.java.net/browse/JDK-8232446> is finished, let see 
then. :-)

Thank you

-Hamlin

>
> On 10/16/19 1:28 AM, Hamlin Li wrote:
>>
>> Thanks Roger, sorry for that I missed your response. (most of time I 
>> focus on mail send to/cc me :) )
>>
>> On 2019/10/15 10:29 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> 1. Replace the creation of the Registry with 
>>> TestLibrary.crateRegistryOnEphemeralPort
>>> and call TestLibrary.getRegistryPort to get the port number.
>>>
>>> The intent of the test is still satisified without the timing/port 
>>> allocation issues.
>>
>> For this test, it failed only after unexportObject is called and port 
>> is not freed in time or occupied again by others.
>>
>> So it would be fine to use createRegistryOnEphemeralPort but will not 
>> help to resolve this issue.
>>
> ok, just cutting down on the variables
>>
>>>
>>> 2. Another approach to testing if the port is in use would be to
>>> assume its still active and do a registry.lookup("xxx").
>>>
>>> The response be NotBoundException if the registry is still alive
>>> or will be a RemoteException indicating the port is closed.
>>>
>>> If some other application has grabbed the port, some other exception 
>>> RemoteException cause will be thrown.
>>
>> I'm not sure if RemoteException equals to the port has been closed by 
>> the registry.
>>
>> Based on API doc, "|RemoteException 
>> <https://docs.oracle.com/en/java/javase/12/docs/api/java.rmi/java/rmi/RemoteException.html>|- 
>> if remote communication with the registry failed; if exception is 
>> a|ServerException|containing an|AccessException|, then the registry 
>> denies the caller access to perform this operation", in my 
>> understanding, a) "port is closed" and b) "others grab the port 
>> again" will cause RemoteException, but RemoteException does not mean 
>> it's in just one of the 2 situations a) and b).
>>
>
> I should have been more specific and to examine the exception that 
> caused the RemoteException.
> It should reflect the socket level error, if any.
>
> Roger
>
>> Thank you
>>
>> -Hamlin
>>
>>
>

From andy.herrick at oracle.com  Thu Oct 17 11:52:37 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 17 Oct 2019 07:52:37 -0400
Subject: RFR: JDK-8232387:
 tools/jpackage/share/jdk/jpackage/tests/BasicTest.java fails
In-Reply-To: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
References: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
 <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
Message-ID: <efe2806b-bab3-8d8a-c871-120cdc497981@oracle.com>

looks good.


/Andy


On 10/16/2019 7:56 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally regression in JPackageCommand class fixed.
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232387
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8232387/webrev.00/
>

From Roger.Riggs at oracle.com  Thu Oct 17 13:26:27 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 17 Oct 2019 09:26:27 -0400
Subject: Typo in a java base javadoc
In-Reply-To: <95A80D9E-F284-45DB-B004-A95666C60B1F@outlook.com>
References: <c113f86f-5e7b-903d-29de-9be939fbe22c@oracle.com>
 <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
 <cc64a6e6-e466-ede5-b49d-7ccd5f41170a@oracle.com>
 <95A80D9E-F284-45DB-B004-A95666C60B1F@outlook.com>
Message-ID: <b3ce95ed-a59f-787b-bbd4-191b614af064@oracle.com>

Hi Aditya,

This is the correct email,? for trivial changes like typos, just send 
the details (if they are brief).

See https://openjdk.java.net/contribute/ for full information on 
contributing.

$.02, Roger





On 10/16/19 11:12 PM, Aditya Srinivasan wrote:
> Hi there, I?m sending this message to this mailing list after receiving guidance from Dalibor Topic. I found a typo in a java.base class and wanted to know how I should go about making contributions to it. I hope this is the right channel to bring this up.
>
> Aditya Srinivasan


From brian.burkhalter at oracle.com  Thu Oct 17 17:35:46 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 17 Oct 2019 10:35:46 -0700
Subject: 8232271: java.io.File.get*Space() should be aligned to updated
 FileStore analog methods
Message-ID: <C15EDD06-9771-4E46-8C5A-A58FC37D2F7E@oracle.com>

For issue [1], please review the patch [2]. This change aligns the specifications of the File.get*Space() methods with their equivalents in java.nio.file.FileStore. This issue is related to [3] which is discussed in this thread [4].

Naturally a CSR would eventually be required.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8232271
[2] http://cr.openjdk.java.net/~bpb/8232271/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8162520
[4] http://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006644.html

From sverre.moe at gmail.com  Thu Oct 17 22:10:11 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Fri, 18 Oct 2019 00:10:11 +0200
Subject: JEP-343: jpackage Windows installer localization
In-Reply-To: <f472bb77-c09c-6bb4-c2df-aaf058ddfff8@oracle.com>
References: <CALAJ+5A3TGNWdR-WcgkEgCovNhMrWc8Nwky60crSWCG1-UzAJg@mail.gmail.com>
 <f472bb77-c09c-6bb4-c2df-aaf058ddfff8@oracle.com>
Message-ID: <CALAJ+5CazNuRHvs_3MCQJPVZEUmEGgwMMmsA+TVYQ1Cn9Q6ekQ@mail.gmail.com>

I wonder if there is something I can contribute with to improve the
localization. Perhaps work further with the existing Localization that
exists for WiX in jpackage.

Currently English, Japanese and Chinese Simplified localization files are
provided with jpackage. Though all are English localization.

I made some changes to the jpackage localization, that I can contribute
(mentioned in Change 1). The 2 other changes mentioned below require a
little discussion before beginning to implement.

*Change 1:* Add some missing localization for Strings on the installer
information dialog for when folder already exists.
  installer.folder.exists.dialog.title = Setup
  installer.folder.exists.dialog.button.yes = Yes
  installer.folder.exists.dialog.button.no = No

These are the Dialog Strings defined strictly in jpackage template.wxs for
the JpInvalidInstallDir dialog.


The jpackage WiX template file is using the built-in WixUI_InstallDir
dialog, and it has its own localization.
https://wixtoolset.org//documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html

WiX has some support for localization. Perhaps extensive enough for most:
en-us, hr-HR, lv-LV, ro-RO, uk-UA, ar-SA, es-es, hu-HU, ru-ru, zh-CN,
bg-BG, et-EE, sk-SK, zh-HK, ca-ES, it-it, nb-NO, sl-SI, zh-TW, cs-CZ,
fi-FI, ja-jp, nl-NL, sr-Latn-CS, da-DK, fr-fr, kk-KZ, pl-pl, sv-SE, de-de,
he-IL, ko-KR, pt-BR, th-TH

The culture switch must be provided to light.exe in order to use anything
other than English.
Use "-culture:nb-no" for the nb_NO localization.

The cultures switch is not provided to light.exe by jpackage, and it is
recommended by WiX.
> The -loc flag is used to specify the language file to use. It is
important to include the -cultures flag on the command line to ensure the
correct localized strings are included for extensions such as
WiXUIExtension.

I have tested this by manually running light.exe and it works fine. I got
the Norwegian localization for the installer when I specified
"-culture:nb_NO".

*Change 2:* Add --win-culture, or --win-localization option to jpackage
Provide the culture switch to light.exe as specified from the localization
option.
The second option is probably the best name. I would not even know what
culture was about before looking into WiX, but everyone knows what
localization means. The option approach would also allow users to run
multiple executions of jpackage in order to build multiple installers in
different languages.

One caveat though: We need to support the same number of localizations in
jpackage as WiX does. Otherwise if jpackage does not have its own
localization for the specified culture switch, then building the installer
will fail. It will fail for uknown localization variables on jpackage's own
Strings.
light.exe -culture:nb_NO MsiInstallerStrings_en.wxl
error The localization variable !(loc.message.install.dir.exist) is unknown.

There are many localization files in WiX, but luckily jpackage has only 4
Strings of its own. It should not be that much work to make an
MsiInstallerStrings file for each of the WiX localizations.

Using a culture that WiX has no localization for will not fail building the
installer, but just throw a warning, and fallback to English localization.
-culture:un-known MsiInstallerStrings_en.wxl

*Change 3:*
All the WiX localization Strings can be overridden in the provided -loc
MsiInstallerStrings.en.wxl file.
We could support custom localization files in resource directory. It could
allow users to provide localization which WiX does not have built-in
support for, or just with different text for the existing localization
Strings.
> Using MsiInstallerStrings_en.wxl localization (specify
application-name.wxl in resource-dir to customize)

/Sverre
--


tor. 10. okt. 2019 kl. 20:56 skrev Alexey Semenyuk <
alexey.semenyuk at oracle.com>:

> Sverre,
>
> I've captured your input in [1]. Currently Windows installers are not
> localized. We just have sources structured to support localization.
> This is a major effort to implement if multiple languages in msi
> installers generated by jpackage are required.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232136
>
> - Alexey
>
> On 10/10/2019 1:46 PM, Sverre Moe wrote:
> > It should be possible to provide localized strings to the Windows
> installer
> > with jpackage.
> >
> > WiX supports building localized installers through the use of language
> > files that include localized strings.
> >
> https://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/make_installer_localizable.html
> >
> > There are three localization resources for Windows in jpackage.
> > Though there is only one String in those three localization files,
> > "message.install.dir.exist", all in English and there are more Strings in
> > English in the main.wxs file that are not localized.
> > MsiInstallerStrings_en.wxl
> > MsiInstallerStrings_ja.wxl
> > MsiInstallerStrings_zh_CN.wxl
> >
> > These could be customized by providing an application_en.wxl or
> > application_es.wxl, or any other language to the resource directory.
> > Perhaps also allow for further customization by providing an
> > application.wxs to the resource directory to use instead of the main.wxs.
> >
> > /Sverre
>
>

From alexey.semenyuk at oracle.com  Thu Oct 17 22:24:10 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 17 Oct 2019 18:24:10 -0400
Subject: RFR: JDK-8223325: Improve wix sources generated by jpackage
In-Reply-To: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
References: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
Message-ID: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- moved code creating WiX sources for app image from WinMsiBundler in a 
separate class - WixSourcesBuilder;
- put at most one file in component in WiX sources;
- use StAX to create WiX sources;
- added IOUtils.createXml function to simplify xml creation;
- added basic javadoc to AppImageFile class;
- added support for use of icons in file associations test for better 
coverage;
- fixed the bug with not excluded `.jpackage.xml` from installed app 
image on Windows;
- improved test output isolation when jpackage tests are executed not 
with jtreg framework;
- bugfix of MainClassTest test class;

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/


From joe.darcy at oracle.com  Thu Oct 17 23:04:52 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 17 Oct 2019 16:04:52 -0700
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <CA+kOe094QjsWf9WhywF3n9maj6Q6t6SEb7DufgsBu2fj+dDuhw@mail.gmail.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
 <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
 <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>
 <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>
 <0956dafa-385b-dd9d-64c4-f94d7497f0a0@oracle.com>
 <CA+kOe094QjsWf9WhywF3n9maj6Q6t6SEb7DufgsBu2fj+dDuhw@mail.gmail.com>
Message-ID: <53584daa-917c-5624-b722-9b847fdcc861@oracle.com>

Hi Martin,

Hmm. Sorry about that; I thought I was sending something which compiled, 
but clearly made a mistake somewhere in the tool chain.

It is possible at some cost to have a SerializableConditionImpl that had 
a Serializable field and a Condition field that both pointed to same 
object and forwarded methods calls appropriately. However, that adds an 
extra layer of objects and indirections.

-Joe

On 10/16/2019 6:11 PM, Martin Buchholz wrote:
>
>
> On Wed, Oct 16, 2019 at 3:56 PM Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>
>     FWIW, this code compiles in javac
>
>     ???? public interface SerializableCondition extends Condition,
>     Serializable {
>     ???????? public static <C extends Condition & Serializable>
>     ????????????????????????????????? SerializableCondition transform(C
>     condition) {
>     ???????????? return condition;
>     ???????? }
>     ???? }
>
>     and objects of existing types like
>     AbstractQueuedLongSynchronizer.ConditionObject seem to get
>     "converted"
>     as desired.
>
>
> I actually tried this ...
> ---
> import java.io.Serializable;
> import java.util.concurrent.locks.Condition;
>
> public interface SerializableCondition
> ? ? extends Condition, Serializable {
> ? ? public static <C extends Condition & Serializable>
> ? ? ? SerializableCondition transform(C condition) {
> ? ? ? ? return condition;
> ? ? }
> }
> ---
> ... and got:
>
> ==> javac -source 14 -Xlint:all SerializableCondition.java
> SerializableCondition.java:8: error: incompatible types: C cannot be 
> converted to SerializableCondition
> ? ? ? ? return condition;
> ? ? ? ? ? ? ? ?^
> ? where C is a type-variable:
> ? ? C extends Condition,Serializable declared in method <C>transform(C)
> 1 error

From alexey.semenyuk at oracle.com  Thu Oct 17 23:16:55 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 17 Oct 2019 19:16:55 -0400
Subject: JEP-343: jpackage Windows installer localization
In-Reply-To: <CALAJ+5CazNuRHvs_3MCQJPVZEUmEGgwMMmsA+TVYQ1Cn9Q6ekQ@mail.gmail.com>
References: <CALAJ+5A3TGNWdR-WcgkEgCovNhMrWc8Nwky60crSWCG1-UzAJg@mail.gmail.com>
 <f472bb77-c09c-6bb4-c2df-aaf058ddfff8@oracle.com>
 <CALAJ+5CazNuRHvs_3MCQJPVZEUmEGgwMMmsA+TVYQ1Cn9Q6ekQ@mail.gmail.com>
Message-ID: <e214e83e-5598-1c1d-a30c-327d0bd2ac77@oracle.com>



On 10/17/2019 6:10 PM, Sverre Moe wrote:
> I wonder if there is something I can contribute with to improve the 
> localization. Perhaps work further with the existing Localization that 
> exists for WiX in jpackage.
>
> Currently English, Japanese and Chinese Simplified localization files 
> are provided with jpackage. Though all are English localization.
Correct. Translations will be provided later. Japanese and Chinese 
Simplified localization files are just stubs for now.

>
> I made some changes to the jpackage localization, that I can 
> contribute (mentioned in Change 1). The 2 other changes mentioned 
> below require a little discussion before beginning to implement.
>
> *Change 1:* Add some missing localization for Strings on the installer 
> information dialog for when folder already exists.
> ? installer.folder.exists.dialog.title = Setup
> ? installer.folder.exists.dialog.button.yes = Yes
> installer.folder.exists.dialog.button.no 
> <http://installer.folder.exists.dialog.button.no> = No
>
> These are the Dialog Strings defined strictly in jpackage template.wxs 
> for the JpInvalidInstallDir dialog.
I'm confused. Do you mean main.wxs? There is no template.wxs file in the 
sandbox, but there is main.wxs with JpInvalidInstallDir dialog.

>
>
> The jpackage WiX template file is using the built-in WixUI_InstallDir 
> dialog, and it has its own localization.
> https://wixtoolset.org//documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html
>
> WiX has some support for localization. Perhaps extensive enough for most:
> en-us, hr-HR, lv-LV, ro-RO, uk-UA, ar-SA, es-es, hu-HU, ru-ru, zh-CN, 
> bg-BG, et-EE, sk-SK, zh-HK, ca-ES, it-it, nb-NO, sl-SI, zh-TW, cs-CZ, 
> fi-FI, ja-jp, nl-NL, sr-Latn-CS, da-DK, fr-fr, kk-KZ, pl-pl, sv-SE, 
> de-de, he-IL, ko-KR, pt-BR, th-TH
>
> The culture switch must be provided to light.exe in order to use 
> anything other than English.
> Use "-culture:nb-no" for the nb_NO localization.
>
> The cultures switch is not provided to light.exe by jpackage, and it 
> is recommended by WiX.
> > The -loc flag is used to specify the language file to use. It is 
> important to include the -cultures flag on the command line to ensure 
> the correct localized strings are included for extensions such as 
> WiXUIExtension.
>
> I have tested this by manually running light.exe and it works fine. I 
> got the Norwegian localization for the installer when I specified 
> "-culture:nb_NO".
What type of localization you are looking for? MSI installers can be 
built with multilingual support. I.e. you can build an MSI package that 
would include English, Norwegian, German, etc. localizations and pick 
the one at installation time. But this is quite a complicated thing - 
https://www.firegiant.com/wix/tutorial/transforms/morphing-installers/.
If you need only one language in your installer, then simple 
"-culture:nb_NO" would be sufficient, of course.

>
> *Change 2:*?Add --win-culture, or --win-localization option to jpackage
> Provide the culture switch to light.exe as specified from the 
> localization option.
> The second option is probably the best name. I would not even know 
> what culture was about before looking into WiX, but everyone knows 
> what localization means. The option approach would also allow users to 
> run multiple executions of jpackage in order to build multiple 
> installers in different languages.
Adding --win-localization command line option looks reasonable. In case 
of missing .wxl file for requested localization in OpenJDK you would 
drop one in resource directory. Of course we need to fix jpackage to 
hook up .wxl files from resource directory. This functionality is 
missing at the moment.

>
> One caveat though: We need to support the same number of localizations 
> in jpackage as WiX does. Otherwise if jpackage does not have its own 
> localization for the specified culture switch, then building the 
> installer will fail. It will fail for uknown localization variables on 
> jpackage's own Strings.
> light.exe -culture:nb_NO MsiInstallerStrings_en.wxl
> error The localization variable !(loc.message.install.dir.exist) is 
> unknown.
>
> There are many localization files in WiX, but luckily jpackage has 
> only 4 Strings of its own. It should not be that much work to make an 
> MsiInstallerStrings file for each of the WiX localizations.
I don't think we would support any localization beyond English, Japanese 
and Chinese Simplified in OpenJDK. Who would provide translations in 
multiple languages on regular basis?

>
> Using a culture that WiX has no localization for will not fail 
> building the installer, but just throw a warning, and fallback to 
> English localization.
> -culture:un-known MsiInstallerStrings_en.wxl
>
> *Change 3:*
> All the WiX localization Strings can be overridden in the provided 
> -loc MsiInstallerStrings.en.wxl file.
> We could support custom localization files in resource directory. It 
> could allow users to provide localization which WiX does not have 
> built-in support for, or just with different text for the existing 
> localization Strings.
> > Using MsiInstallerStrings_en.wxl localization (specify 
> application-name.wxl in resource-dir to customize)
This is good idea.

- Alexey

>
> /Sverre
> --
>
>
> tor. 10. okt. 2019 kl. 20:56 skrev Alexey Semenyuk 
> <alexey.semenyuk at oracle.com <mailto:alexey.semenyuk at oracle.com>>:
>
>     Sverre,
>
>     I've captured your input in [1]. Currently Windows installers are not
>     localized. We just have sources structured to support localization.
>     This is a major effort to implement if multiple languages in msi
>     installers generated by jpackage are required.
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8232136
>
>     - Alexey
>
>     On 10/10/2019 1:46 PM, Sverre Moe wrote:
>     > It should be possible to provide localized strings to the
>     Windows installer
>     > with jpackage.
>     >
>     > WiX supports building localized installers through the use of
>     language
>     > files that include localized strings.
>     >
>     https://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/make_installer_localizable.html
>     >
>     > There are three localization resources for Windows in jpackage.
>     > Though there is only one String in those three localization files,
>     > "message.install.dir.exist", all in English and there are more
>     Strings in
>     > English in the main.wxs file that are not localized.
>     > MsiInstallerStrings_en.wxl
>     > MsiInstallerStrings_ja.wxl
>     > MsiInstallerStrings_zh_CN.wxl
>     >
>     > These could be customized by providing an application_en.wxl or
>     > application_es.wxl, or any other language to the resource directory.
>     > Perhaps also allow for further customization by providing an
>     > application.wxs to the resource directory to use instead of the
>     main.wxs.
>     >
>     > /Sverre
>


From alexey.semenyuk at oracle.com  Fri Oct 18 02:03:39 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 17 Oct 2019 22:03:39 -0400
Subject: RFR: JDK-8231972: Build a stable list of jpackager tests for SQE
In-Reply-To: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
Message-ID: <e804d39b-fc2a-fd47-9424-e1476d9f2ef9@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8231972/webrev.00/


From david.holmes at oracle.com  Fri Oct 18 04:04:27 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Oct 2019 14:04:27 +1000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
Message-ID: <aa88d81a-0acf-eace-410f-b2a4c537213e@oracle.com>

On 16/10/2019 6:28 pm, Schmelter, Ralf wrote:
> Hi David,
> 
> the canonicalize() method is never used by java.io or any Java code. Currently it is used by the hotspot in classloader.cpp (which I use in the test) and in libinstrument in InvocationAdapter.c. There is no way to test it in core-libs. One can argue if the canonicalize method is in the right file, but that should be a separate discussion.

Sorry Ralf, yes you are correct. What a strange arrangement.

The test change seems fine in that case.

I'm afraid I can't comment on the actual fix, sorry.

Thanks,
David
-----

> Best regards,
> Ralf
> 
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 16. Oktober 2019 05:59
> To: Schmelter, Ralf <ralf.schmelter at sap.com>; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows
> 
> Hi Ralf,
> 
> This isn't a hotspot issue but a core-libs one.
> 
> The use of a hotspot-runtime test seems more opportunistic than anything
> else - is it just for code coverage? I would expect to find a more
> appropriate test somewhere in core-libs.
> 
> Thanks,
> David
> 

From alexander.matveev at oracle.com  Fri Oct 18 04:17:18 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 17 Oct 2019 21:17:18 -0700
Subject: RFR: JDK-8231972: Build a stable list of jpackager tests for SQE
In-Reply-To: <e804d39b-fc2a-fd47-9424-e1476d9f2ef9@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
 <e804d39b-fc2a-fd47-9424-e1476d9f2ef9@oracle.com>
Message-ID: <be222ed4-5cc1-df9e-21b7-ed3ee3038fec@oracle.com>

Looks good.

On 10/17/19 7:03 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231972
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8231972/webrev.00/
>


From jai.forums2013 at gmail.com  Fri Oct 18 07:03:16 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 18 Oct 2019 12:33:16 +0530
Subject: java.lang.System's comment about initializeSystemClass
Message-ID: <7003f194-d776-c128-f547-4bdd96d2c708@gmail.com>

The java.lang.System has this code comment[1] which states:

"

/* Register the natives via the static initializer.
???? *
???? * VM will invoke the initializeSystemClass method to complete
???? * the initialization for this class separated from clinit.
???? * Note that to use properties set by the VM, see the constraints
???? * described in the initializeSystemClass method.
???? */

"

However, I can't find that "initializeSystemClass" method anywhere in
that class or any other class in the JDK code. Is that comment still
relevant or am I looking in the wrong places?

[1]
http://hg.openjdk.java.net/jdk/jdk/file/9f5b92d5a1b2/src/java.base/share/classes/java/lang/System.java#l97

-Jaikiran


From Alan.Bateman at oracle.com  Fri Oct 18 07:09:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Oct 2019 08:09:21 +0100
Subject: java.lang.System's comment about initializeSystemClass
In-Reply-To: <7003f194-d776-c128-f547-4bdd96d2c708@gmail.com>
References: <7003f194-d776-c128-f547-4bdd96d2c708@gmail.com>
Message-ID: <f68827c1-a529-3386-9b92-b6cf1df3d212@oracle.com>

On 18/10/2019 08:03, Jaikiran Pai wrote:
>
> However, I can't find that "initializeSystemClass" method anywhere in
> that class or any other class in the JDK code. Is that comment still
> relevant or am I looking in the wrong places?
>
It's stale, the equivalent of what was initializeSystemClass is 
initPhase1 now.

-Alan

From jai.forums2013 at gmail.com  Fri Oct 18 07:12:50 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 18 Oct 2019 12:42:50 +0530
Subject: java.lang.System's comment about initializeSystemClass
In-Reply-To: <f68827c1-a529-3386-9b92-b6cf1df3d212@oracle.com>
References: <7003f194-d776-c128-f547-4bdd96d2c708@gmail.com>
 <f68827c1-a529-3386-9b92-b6cf1df3d212@oracle.com>
Message-ID: <3af99439-9c69-0cd5-dff2-2b6e2816569f@gmail.com>


On 18/10/19 12:39 PM, Alan Bateman wrote:
> On 18/10/2019 08:03, Jaikiran Pai wrote:
>>
>> However, I can't find that "initializeSystemClass" method anywhere in
>> that class or any other class in the JDK code. Is that comment still
>> relevant or am I looking in the wrong places?
>>
> It's stale, the equivalent of what was initializeSystemClass is
> initPhase1 now.
>
> -Alan

Thank you Alan. Should I create a JBS issue to track and have this changed?

-Jaikiran



From sverre.moe at gmail.com  Fri Oct 18 08:41:25 2019
From: sverre.moe at gmail.com (Sverre Moe)
Date: Fri, 18 Oct 2019 10:41:25 +0200
Subject: JEP-343: jpackage Windows installer localization
In-Reply-To: <e214e83e-5598-1c1d-a30c-327d0bd2ac77@oracle.com>
References: <CALAJ+5A3TGNWdR-WcgkEgCovNhMrWc8Nwky60crSWCG1-UzAJg@mail.gmail.com>
 <f472bb77-c09c-6bb4-c2df-aaf058ddfff8@oracle.com>
 <CALAJ+5CazNuRHvs_3MCQJPVZEUmEGgwMMmsA+TVYQ1Cn9Q6ekQ@mail.gmail.com>
 <e214e83e-5598-1c1d-a30c-327d0bd2ac77@oracle.com>
Message-ID: <CALAJ+5BsB7j1ctBUo_nGw7Lsy3o0=QVS=nTzgD3pR5WY2U4jfA@mail.gmail.com>

fre. 18. okt. 2019 kl. 01:17 skrev Alexey Semenyuk <
alexey.semenyuk at oracle.com>:

>
>
> On 10/17/2019 6:10 PM, Sverre Moe wrote:
>
> I wonder if there is something I can contribute with to improve the
> localization. Perhaps work further with the existing Localization that
> exists for WiX in jpackage.
>
> I made some changes to the jpackage localization, that I can contribute
> (mentioned in Change 1). The 2 other changes mentioned below require a
> little discussion before beginning to implement.
>
> *Change 1:* Add some missing localization for Strings on the installer
> information dialog for when folder already exists.
>   installer.folder.exists.dialog.title = Setup
>   installer.folder.exists.dialog.button.yes = Yes
>   installer.folder.exists.dialog.button.no = No
>
> These are the Dialog Strings defined strictly in jpackage template.wxs for
> the JpInvalidInstallDir dialog.
>
> I'm confused. Do you mean main.wxs? There is no template.wxs file in the
> sandbox, but there is main.wxs with JpInvalidInstallDir dialog.
>
> Yes, I meant the main.wxs. It defines a dialog for the invalid install dir
which has 4 Strings. Currently only one of these Strings has localization
in MsiInstallerStrings with jpackage, the three others are missing.

The Change 1 I proposed was to add the localization for these three missing
Strings to the existing
MsiInstallerString_en.wxl, MsiInstallerString_ja.wxl and
MsiInstallerString_zh_CN.wxl

The jpackage WiX template file is using the built-in WixUI_InstallDir
> dialog, and it has its own localization.
>
> https://wixtoolset.org//documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html
>
> WiX has some support for localization. Perhaps extensive enough for most:
> en-us, hr-HR, lv-LV, ro-RO, uk-UA, ar-SA, es-es, hu-HU, ru-ru, zh-CN,
> bg-BG, et-EE, sk-SK, zh-HK, ca-ES, it-it, nb-NO, sl-SI, zh-TW, cs-CZ,
> fi-FI, ja-jp, nl-NL, sr-Latn-CS, da-DK, fr-fr, kk-KZ, pl-pl, sv-SE, de-de,
> he-IL, ko-KR, pt-BR, th-TH
>
> The culture switch must be provided to light.exe in order to use anything
> other than English.
> Use "-culture:nb-no" for the nb_NO localization.
>
> The cultures switch is not provided to light.exe by jpackage, and it is
> recommended by WiX.
> > The -loc flag is used to specify the language file to use. It is
> important to include the -cultures flag on the command line to ensure the
> correct localized strings are included for extensions such as
> WiXUIExtension.
>
> I have tested this by manually running light.exe and it works fine. I got
> the Norwegian localization for the installer when I specified
> "-culture:nb_NO".
>
> What type of localization you are looking for? MSI installers can be built
> with multilingual support. I.e. you can build an MSI package that would
> include English, Norwegian, German, etc. localizations and pick the one at
> installation time. But this is quite a complicated thing -
> https://www.firegiant.com/wix/tutorial/transforms/morphing-installers/.
> If you need only one language in your installer, then simple
> "-culture:nb_NO" would be sufficient, of course.
>
> I had a single language installer in mind yes. I think the
morphing-installers would be much more difficult to implement support for.
I think using the cultures switch with light.exe would suffice for jpackage
to support localization.

>
> *Change 2:* Add --win-culture, or --win-localization option to jpackage
> Provide the culture switch to light.exe as specified from the localization
> option.
> The second option is probably the best name. I would not even know what
> culture was about before looking into WiX, but everyone knows what
> localization means. The option approach would also allow users to run
> multiple executions of jpackage in order to build multiple installers in
> different languages.
>
> Adding --win-localization command line option looks reasonable. In case of
> missing .wxl file for requested localization in OpenJDK you would drop one
> in resource directory. Of course we need to fix jpackage to hook up .wxl
> files from resource directory. This functionality is missing at the moment.
>

> One caveat though: We need to support the same number of localizations in
> jpackage as WiX does. Otherwise if jpackage does not have its own
> localization for the specified culture switch, then building the installer
> will fail. It will fail for uknown localization variables on jpackage's own
> Strings.
> light.exe -culture:nb_NO MsiInstallerStrings_en.wxl
> error The localization variable !(loc.message.install.dir.exist) is
> unknown.
>
> There are many localization files in WiX, but luckily jpackage has only 4
> Strings of its own. It should not be that much work to make an
> MsiInstallerStrings file for each of the WiX localizations.
>
> I don't think we would support any localization beyond English, Japanese
> and Chinese Simplified in OpenJDK. Who would provide translations in
> multiple languages on regular basis?
>
> All these three localizations are in English, so what is the point then
with Japanese and Chinese?
Perhaps jpackage should just support English localization as default. and
the user would have to customize to get another localization.

There is pre-existing localization in WiX for most of the installer UI
created with jpackage, but the cultures switch must be provided to use them.
While testing with WiX Localization I found that these cannot be used
unless the localization file provided by jpackage has the same language.
WiX has Norwegian localization, among many other languages, while jpackage
does not.
This will fail light.exe with an error:
  -cultures:nb-no -loc MsiInstallerStrings_en.wxl
This will work though
  -cultures:nb-no -loc MsiInstallerStrings_nb_NO.wxl

This will also fail with Japanese and Chinese localization since they have
English en-us cultures set in their files.
  -cultures:ja -loc MsiInstallerStrings_ja.wxl
  -cultures:zh-cn -loc MsiInstallerStrings_zh_CN.wxl
So currently the Japanese and Chinese localization are useless as they are
both in English.

I found a way around this problem: The cultures switch support fallback
allowing the jpackage parts to remain in English, while the rest is
properly localized.
  -cultures:nb-no;en-us -loc MsiInstallerStrings_en.wxl

That way we can support the extensive localization support in WiX, while
the same time keep the localization support in jpackage to a minimum of
English, Japanese and Chinese Simplified.

>
> *Change 3:*
> All the WiX localization Strings can be overridden in the provided -loc
> MsiInstallerStrings.en.wxl file.
> We could support custom localization files in resource directory. It could
> allow users to provide localization which WiX does not have built-in
> support for, or just with different text for the existing localization
> Strings.
> > Using MsiInstallerStrings_en.wxl localization (specify
> application-name.wxl in resource-dir to customize)
>
> This is good idea.
>
> - Alexey
>

From Alan.Bateman at oracle.com  Fri Oct 18 10:40:46 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Oct 2019 11:40:46 +0100
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
Message-ID: <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>

On 16/10/2019 09:28, Schmelter, Ralf wrote:
> Hi David,
>
> the canonicalize() method is never used by java.io or any Java code. Currently it is used by the hotspot in classloader.cpp (which I use in the test) and in libinstrument in InvocationAdapter.c. There is no way to test it in core-libs. One can argue if the canonicalize method is in the right file, but that should be a separate discussion.
>
I plan to review this, I just haven't had time yet. You are right that 
there is technical debt here, include dependency in the JPLIS agent 
which crept in when java.lang.instrument was updated to support 
augmenting of the boot class path.

-Alan

From Alan.Bateman at oracle.com  Fri Oct 18 11:18:13 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Oct 2019 12:18:13 +0100
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
Message-ID: <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>

On 16/10/2019 18:06, Lance Andersen wrote:
> Hi all,
>
> Please review this fix to ZipFileInputStream::skip when specifying a negative value to the skip method when accessing a STORED entry, https://bugs.openjdk.java.net/browse/JDK-8231451 <https://bugs.openjdk.java.net/browse/JDK-8231451>.  Prior to this fix, you could move past the beginning of the STORED entry.
>
> I also added a release note, https://bugs.openjdk.java.net/browse/JDK-8232384 <https://bugs.openjdk.java.net/browse/JDK-8232384>, to help clarify the behavior of these methods when a negative value is specified.
>
> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html>
>
This seems to introduce inconsistency in that an attempt to seek beyond 
EOF will return the number of bytes skipped or 0 where as attempting to 
seek to before the start will throw IOException. It might be a corner 
case but a better alternative might be to seek to position 0, returning 
the number of bytes that were (negatively) skipped to get to 0.

-Alan.

From Alan.Bateman at oracle.com  Fri Oct 18 11:21:55 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Oct 2019 12:21:55 +0100
Subject: java.lang.System's comment about initializeSystemClass
In-Reply-To: <3af99439-9c69-0cd5-dff2-2b6e2816569f@gmail.com>
References: <7003f194-d776-c128-f547-4bdd96d2c708@gmail.com>
 <f68827c1-a529-3386-9b92-b6cf1df3d212@oracle.com>
 <3af99439-9c69-0cd5-dff2-2b6e2816569f@gmail.com>
Message-ID: <b7d9e1a8-1642-8775-9cb7-bdcfe16ffc30@oracle.com>

On 18/10/2019 08:12, Jaikiran Pai wrote:
> :
> Thank you Alan. Should I create a JBS issue to track and have this changed?
>
Yes, go ahead, we just missed updating this comment in JDK 9.

-Alan

From lance.andersen at oracle.com  Fri Oct 18 11:38:11 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 18 Oct 2019 07:38:11 -0400
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
Message-ID: <B5922E04-F3BE-4861-92C9-79E8DDD0DF51@oracle.com>

Thank you for the feedback Alan.
> On Oct 18, 2019, at 7:18 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 16/10/2019 18:06, Lance Andersen wrote:
>> Hi all,
>> 
>> Please review this fix to ZipFileInputStream::skip when specifying a negative value to the skip method when accessing a STORED entry, https://bugs.openjdk.java.net/browse/JDK-8231451 <https://bugs.openjdk.java.net/browse/JDK-8231451>.  Prior to this fix, you could move past the beginning of the STORED entry.
>> 
>> I also added a release note, https://bugs.openjdk.java.net/browse/JDK-8232384 <https://bugs.openjdk.java.net/browse/JDK-8232384>, to help clarify the behavior of these methods when a negative value is specified.
>> 
>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html>
>> 
> This seems to introduce inconsistency in that an attempt to seek beyond EOF will return the number of bytes skipped or 0 where as attempting to seek to before the start will throw IOException.

Yes I noticed this also but thought (at the time) throwing the exception made sense in the case moving past BOF?  

> It might be a corner case but a better alternative might be to seek to position 0, returning the number of bytes that were (negatively) skipped to get to 0.

I can make the change you propose and update the release note and send a revised patch.

Thank you.

Best
Lance
> 
> -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 maurizio.cimadamore at oracle.com  Fri Oct 18 12:05:45 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 18 Oct 2019 13:05:45 +0100
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
 <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
 <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
Message-ID: <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com>

Looks good - but I suggest garbage collecting the isEssentialAPI() from 
the @PreviewFeature annotation, as the new behavior effectively removes 
any distinctions between the two (unless I miss something).

Maurizio

On 16/10/2019 13:50, Jan Lahoda wrote:
> Hi,
>
> An updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/
>
> Changes in the update:
> -added the dependency into the makefiles
> -loosened the handling of essential preview APIs when --enable-preview 
> and @SuppressWarnings is applied - there is no warning for the 
> essential APIs (as there is no warning in such a case for 
> non-essential APIs). This is per the discussion in the CSR:
> https://bugs.openjdk.java.net/browse/JDK-8231411
>
> Any comments/feedback on this?
>
> Thanks!
> ??? Jan
>
> On 09. 10. 19 17:41, Erik Joelsson wrote:
>> Oh, you are absolutely correct, the dependency is missing.
>>
>> We need something like this inside "define SetupInterimModule":
>>
>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
>>
>> /Erik
>>
>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
>>> I can?t see how the compilation is dependent on the copy being 
>>> finished. Since Erik contributed this it will probably be correct :) 
>>> but I?d appreciate an explanation on how this dependency is guaranteed.
>>>
>>> Or maybe I?m misunderstanding what this is supposed to do?
>>>
>>> /Magnus
>>>
>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
>>>>
>>>> Thanks for the new code Erik!
>>>>
>>>> A new webrev/patch that includes this better way of copying is here:
>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>>>>
>>>> Any feedback is welcome!
>>>>
>>>> Thanks,
>>>> ??? Jan
>>>>
>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>>>>> Hello Jan,
>>>>> The build change looks ok, but I would recommend this construct 
>>>>> for copying the file instead:
>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>>>> ???? FILES := 
>>>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, 
>>>>> \
>>>>> ???? DEST := 
>>>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, 
>>>>> \
>>>>> ))
>>>>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>>>> Then you automatically get all the corner case handling we have 
>>>>> implemented over the years for logging, making directories and 
>>>>> copying files. Your version is still correct for this case though.
>>>>> /Erik
>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This is a continuation of Joe's patch from here:
>>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>>>>>
>>>>>>
>>>>>> APIs associated with preview features are split into two groups: 
>>>>>> essential and non-essential. These are marked with an 
>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the 
>>>>>> javadoc, @preview. The javac follows the PreviewFeature 
>>>>>> annotation, and produces either warnings or errors for the usages 
>>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK 
>>>>>> build that adds the content of the tag into the documentation. 
>>>>>> The first part of the @preview's text goes into the summary, the 
>>>>>> second part goes into the detailed description.
>>>>>>
>>>>>> For build, a tricky problem is that the jdk.compiler module uses 
>>>>>> the PreviewFeature annotation as well, but that is not in the 
>>>>>> bootstrap JDK. So, for the intermediate langtools build, the 
>>>>>> PreviewFeature annotation is copied from java.base.
>>>>>>
>>>>>> Proposed webrev:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>>>>
>>>>>> Javadoc with the change:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>>>>
>>>>>> See for example:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>>>>>
>>>>>>
>>>>>> JBS:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>>>>
>>>>>> CSR:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>>>>
>>>>>> Feedback is welcome!
>>>>>>
>>>>>> Thanks,
>>>>>> ???? Jan

From dl at cs.oswego.edu  Fri Oct 18 12:25:03 2019
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 18 Oct 2019 08:25:03 -0400
Subject: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable
 non-transient instance fields in java.util.concurrent
In-Reply-To: <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>
References: <93cec8fa-837b-56d1-2fcc-4f72f0fb03ab@oracle.com>
 <CA+kOe09c+dWSUiHMxG9-C-JCes+XkfrXupopR9O7pPmrACMsjA@mail.gmail.com>
 <f20be82c-aacf-b04d-99f9-8357cce39242@oracle.com>
 <CA+kOe0-t+CBinVMMJirS+_B60YmqQ+N9aUJDC7E5p3Nf4bXZuw@mail.gmail.com>
 <65886eaf-1d12-424c-8ee1-395f3f4b567b@oracle.com>
 <CA+kOe08HUGOGi58XM89rgmRPitgdcSTfitTHZZb8Uj3A9Ga9NQ@mail.gmail.com>
Message-ID: <c27fcc67-b636-7e2d-00bf-37f67b14453e@cs.oswego.edu>


These look OK to me. We could change some declared types to
ConditionObject for sake of clarifying some Condition usages, but it
would not be an improvement. I did notice though that ForkJoinTask doc
should include a caveat that is normally the case now, but will always
hold under some upcoming changes:

 * A deserialized task that completed exceptionally in any way reports
 * a {@code CancellationException}.

I'll wait until applying those changes to include this.

-Doug


From andy.herrick at oracle.com  Fri Oct 18 12:25:57 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 18 Oct 2019 08:25:57 -0400
Subject: RFR: JDK-8231972: Build a stable list of jpackager tests for SQE
In-Reply-To: <e804d39b-fc2a-fd47-9424-e1476d9f2ef9@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
 <e804d39b-fc2a-fd47-9424-e1476d9f2ef9@oracle.com>
Message-ID: <aa4f7351-dfd6-8a43-3281-778ddccda928@oracle.com>

Looks good.

/Andy

On 10/17/2019 10:03 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8231972
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8231972/webrev.00/
>

From jan.lahoda at oracle.com  Fri Oct 18 12:38:07 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 18 Oct 2019 14:38:07 +0200
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
 <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
 <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
 <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com>
Message-ID: <6B0AC83B-213C-4B61-A4A3-0771A9DCF68A@oracle.com>



18. ??jna 2019 14:05:45 SEL?, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> napsal:
>Looks good - but I suggest garbage collecting the isEssentialAPI() from
>
>the @PreviewFeature annotation, as the new behavior effectively removes
>
>any distinctions between the two (unless I miss something).

I am afraid there is still a distinction between them - when --enable-preview is not specified, use of essential APIs will lead to a compile time warning, while use of non essential API (reflection, typically) only produces warnings.

Jan

>
>Maurizio
>
>On 16/10/2019 13:50, Jan Lahoda wrote:
>> Hi,
>>
>> An updated patch is here:
>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/
>>
>> Changes in the update:
>> -added the dependency into the makefiles
>> -loosened the handling of essential preview APIs when
>--enable-preview 
>> and @SuppressWarnings is applied - there is no warning for the 
>> essential APIs (as there is no warning in such a case for 
>> non-essential APIs). This is per the discussion in the CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>
>> Any comments/feedback on this?
>>
>> Thanks!
>> ??? Jan
>>
>> On 09. 10. 19 17:41, Erik Joelsson wrote:
>>> Oh, you are absolutely correct, the dependency is missing.
>>>
>>> We need something like this inside "define SetupInterimModule":
>>>
>>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
>>>
>>> /Erik
>>>
>>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
>>>> I can?t see how the compilation is dependent on the copy being 
>>>> finished. Since Erik contributed this it will probably be correct
>:) 
>>>> but I?d appreciate an explanation on how this dependency is
>guaranteed.
>>>>
>>>> Or maybe I?m misunderstanding what this is supposed to do?
>>>>
>>>> /Magnus
>>>>
>>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
>>>>>
>>>>> Thanks for the new code Erik!
>>>>>
>>>>> A new webrev/patch that includes this better way of copying is
>here:
>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>>>>>
>>>>> Any feedback is welcome!
>>>>>
>>>>> Thanks,
>>>>> ??? Jan
>>>>>
>>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>>>>>> Hello Jan,
>>>>>> The build change looks ok, but I would recommend this construct 
>>>>>> for copying the file instead:
>>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>>>>> ???? FILES := 
>>>>>>
>$(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java,
>
>>>>>> \
>>>>>> ???? DEST := 
>>>>>>
>$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java,
>
>>>>>> \
>>>>>> ))
>>>>>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>>>>> Then you automatically get all the corner case handling we have 
>>>>>> implemented over the years for logging, making directories and 
>>>>>> copying files. Your version is still correct for this case
>though.
>>>>>> /Erik
>>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is a continuation of Joe's patch from here:
>>>>>>>
>https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html
>
>>>>>>>
>>>>>>>
>>>>>>> APIs associated with preview features are split into two groups:
>
>>>>>>> essential and non-essential. These are marked with an 
>>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the 
>>>>>>> javadoc, @preview. The javac follows the PreviewFeature 
>>>>>>> annotation, and produces either warnings or errors for the
>usages 
>>>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK
>
>>>>>>> build that adds the content of the tag into the documentation. 
>>>>>>> The first part of the @preview's text goes into the summary, the
>
>>>>>>> second part goes into the detailed description.
>>>>>>>
>>>>>>> For build, a tricky problem is that the jdk.compiler module uses
>
>>>>>>> the PreviewFeature annotation as well, but that is not in the 
>>>>>>> bootstrap JDK. So, for the intermediate langtools build, the 
>>>>>>> PreviewFeature annotation is copied from java.base.
>>>>>>>
>>>>>>> Proposed webrev:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>>>>>
>>>>>>> Javadoc with the change:
>>>>>>>
>http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>>>>>
>>>>>>> See for example:
>>>>>>>
>http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html
>
>>>>>>>
>>>>>>>
>http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html
>
>>>>>>>
>>>>>>>
>>>>>>> JBS:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>>>>>
>>>>>>> CSR:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>>>>>
>>>>>>> Feedback is welcome!
>>>>>>>
>>>>>>> Thanks,
>>>>>>> ???? Jan

From andy.herrick at oracle.com  Fri Oct 18 12:45:54 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 18 Oct 2019 08:45:54 -0400
Subject: RFR: JDK-8223325: Improve wix sources generated by jpackage
In-Reply-To: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
References: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
 <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
Message-ID: <f29ef04a-d75b-d6ed-4278-204d702880a3@oracle.com>

This change seems ok to me, but since it is a fairly substantial change 
I want to test it locally a bit before integrating.

I also think we should we should release another EA after this change is 
pushed.

/Andy

On 10/17/2019 6:24 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - moved code creating WiX sources for app image from WinMsiBundler in 
> a separate class - WixSourcesBuilder;
> - put at most one file in component in WiX sources;
> - use StAX to create WiX sources;
> - added IOUtils.createXml function to simplify xml creation;
> - added basic javadoc to AppImageFile class;
> - added support for use of icons in file associations test for better 
> coverage;
> - fixed the bug with not excluded `.jpackage.xml` from installed app 
> image on Windows;
> - improved test output isolation when jpackage tests are executed not 
> with jtreg framework;
> - bugfix of MainClassTest test class;
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223325
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/
>

From alexey.semenyuk at oracle.com  Fri Oct 18 12:54:40 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 18 Oct 2019 08:54:40 -0400
Subject: RFR: JDK-8223325: Improve wix sources generated by jpackage
In-Reply-To: <f29ef04a-d75b-d6ed-4278-204d702880a3@oracle.com>
References: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
 <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
 <f29ef04a-d75b-d6ed-4278-204d702880a3@oracle.com>
Message-ID: <827999c3-d549-a04f-e355-773200199e85@oracle.com>

Sounds good.

- Alexey

On 10/18/2019 8:45 AM, Andy Herrick wrote:
> This change seems ok to me, but since it is a fairly substantial 
> change I want to test it locally a bit before integrating.
>
> I also think we should we should release another EA after this change 
> is pushed.
>
> /Andy
>
> On 10/17/2019 6:24 PM, Alexey Semenyuk wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> - moved code creating WiX sources for app image from WinMsiBundler in 
>> a separate class - WixSourcesBuilder;
>> - put at most one file in component in WiX sources;
>> - use StAX to create WiX sources;
>> - added IOUtils.createXml function to simplify xml creation;
>> - added basic javadoc to AppImageFile class;
>> - added support for use of icons in file associations test for better 
>> coverage;
>> - fixed the bug with not excluded `.jpackage.xml` from installed app 
>> image on Windows;
>> - improved test output isolation when jpackage tests are executed not 
>> with jtreg framework;
>> - bugfix of MainClassTest test class;
>>
>> - Alexey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223325
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/
>>


From jai.forums2013 at gmail.com  Fri Oct 18 13:01:00 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 18 Oct 2019 18:31:00 +0530
Subject: java.lang.System's comment about initializeSystemClass
In-Reply-To: <b7d9e1a8-1642-8775-9cb7-bdcfe16ffc30@oracle.com>
References: <7003f194-d776-c128-f547-4bdd96d2c708@gmail.com>
 <f68827c1-a529-3386-9b92-b6cf1df3d212@oracle.com>
 <3af99439-9c69-0cd5-dff2-2b6e2816569f@gmail.com>
 <b7d9e1a8-1642-8775-9cb7-bdcfe16ffc30@oracle.com>
Message-ID: <7ff56945-299f-e6f2-cdde-e18336944e13@gmail.com>


On 18/10/19 4:51 PM, Alan Bateman wrote:
> On 18/10/2019 08:12, Jaikiran Pai wrote:
>> :
>> Thank you Alan. Should I create a JBS issue to track and have this
>> changed?
>>
> Yes, go ahead, we just missed updating this comment in JDK 9.

Done - https://bugs.openjdk.java.net/browse/JDK-8232617


-Jaikiran


From maurizio.cimadamore at oracle.com  Fri Oct 18 13:08:20 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 18 Oct 2019 14:08:20 +0100
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <6B0AC83B-213C-4B61-A4A3-0771A9DCF68A@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
 <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
 <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
 <68ee0609-3b98-85ec-97f8-1cc2ced8aa04@oracle.com>
 <6B0AC83B-213C-4B61-A4A3-0771A9DCF68A@oracle.com>
Message-ID: <214762ca-2826-9304-6eff-d1389b816deb@oracle.com>

Sorry, I got the table in the CSR completely mixed up.

So, the new behavior only really changes the fact that essential API 
warnings are now suppressible when using --enable-preview.

I now see the relevant difference in Check.java.

Looks good

Maurizio

On 18/10/2019 13:38, Jan Lahoda wrote:
>
> 18. ??jna 2019 14:05:45 SEL?, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> napsal:
>> Looks good - but I suggest garbage collecting the isEssentialAPI() from
>>
>> the @PreviewFeature annotation, as the new behavior effectively removes
>>
>> any distinctions between the two (unless I miss something).
> I am afraid there is still a distinction between them - when --enable-preview is not specified, use of essential APIs will lead to a compile time warning, while use of non essential API (reflection, typically) only produces warnings.
>
> Jan
>
>> Maurizio
>>
>> On 16/10/2019 13:50, Jan Lahoda wrote:
>>> Hi,
>>>
>>> An updated patch is here:
>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/
>>>
>>> Changes in the update:
>>> -added the dependency into the makefiles
>>> -loosened the handling of essential preview APIs when
>> --enable-preview
>>> and @SuppressWarnings is applied - there is no warning for the
>>> essential APIs (as there is no warning in such a case for
>>> non-essential APIs). This is per the discussion in the CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>
>>> Any comments/feedback on this?
>>>
>>> Thanks!
>>>  ??? Jan
>>>
>>> On 09. 10. 19 17:41, Erik Joelsson wrote:
>>>> Oh, you are absolutely correct, the dependency is missing.
>>>>
>>>> We need something like this inside "define SetupInterimModule":
>>>>
>>>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
>>>>
>>>> /Erik
>>>>
>>>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
>>>>> I can?t see how the compilation is dependent on the copy being
>>>>> finished. Since Erik contributed this it will probably be correct
>> :)
>>>>> but I?d appreciate an explanation on how this dependency is
>> guaranteed.
>>>>> Or maybe I?m misunderstanding what this is supposed to do?
>>>>>
>>>>> /Magnus
>>>>>
>>>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
>>>>>>
>>>>>> Thanks for the new code Erik!
>>>>>>
>>>>>> A new webrev/patch that includes this better way of copying is
>> here:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>>>>>>
>>>>>> Any feedback is welcome!
>>>>>>
>>>>>> Thanks,
>>>>>>  ??? Jan
>>>>>>
>>>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>>>>>>> Hello Jan,
>>>>>>> The build change looks ok, but I would recommend this construct
>>>>>>> for copying the file instead:
>>>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>>>>>>  ???? FILES :=
>>>>>>>
>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java,
>>
>>>>>>> \
>>>>>>>  ???? DEST :=
>>>>>>>
>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java,
>>
>>>>>>> \
>>>>>>> ))
>>>>>>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>>>>>> Then you automatically get all the corner case handling we have
>>>>>>> implemented over the years for logging, making directories and
>>>>>>> copying files. Your version is still correct for this case
>> though.
>>>>>>> /Erik
>>>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This is a continuation of Joe's patch from here:
>>>>>>>>
>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html
>>
>>>>>>>>
>>>>>>>> APIs associated with preview features are split into two groups:
>>>>>>>> essential and non-essential. These are marked with an
>>>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the
>>>>>>>> javadoc, @preview. The javac follows the PreviewFeature
>>>>>>>> annotation, and produces either warnings or errors for the
>> usages
>>>>>>>> of such APIs. For the @preview tag, there is a taglet in the JDK
>>>>>>>> build that adds the content of the tag into the documentation.
>>>>>>>> The first part of the @preview's text goes into the summary, the
>>>>>>>> second part goes into the detailed description.
>>>>>>>>
>>>>>>>> For build, a tricky problem is that the jdk.compiler module uses
>>>>>>>> the PreviewFeature annotation as well, but that is not in the
>>>>>>>> bootstrap JDK. So, for the intermediate langtools build, the
>>>>>>>> PreviewFeature annotation is copied from java.base.
>>>>>>>>
>>>>>>>> Proposed webrev:
>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>>>>>>
>>>>>>>> Javadoc with the change:
>>>>>>>>
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>>>>>> See for example:
>>>>>>>>
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html
>>
>>>>>>>>
>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html
>>
>>>>>>>>
>>>>>>>> JBS:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>>>>>>
>>>>>>>> CSR:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>>>>>>
>>>>>>>> Feedback is welcome!
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>  ???? Jan

From andy.herrick at oracle.com  Fri Oct 18 14:53:41 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 18 Oct 2019 10:53:41 -0400
Subject: RFR: JDK-8232281,,jpackage is not always reporting an error when no
 main class specified
Message-ID: <4f1a67e8-7ebc-4d55-1b55-45a46f83c585@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

This fixes the case where using runtime-image prevented checking for no 
main class being specified.

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

[2] http://cr.openjdk.java.net/~herrick/8232281/webrev.01/index.html

/Andy


From alexey.semenyuk at oracle.com  Fri Oct 18 14:55:33 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 18 Oct 2019 10:55:33 -0400
Subject: JEP-343: jpackage Windows installer localization
In-Reply-To: <CALAJ+5BsB7j1ctBUo_nGw7Lsy3o0=QVS=nTzgD3pR5WY2U4jfA@mail.gmail.com>
References: <CALAJ+5A3TGNWdR-WcgkEgCovNhMrWc8Nwky60crSWCG1-UzAJg@mail.gmail.com>
 <f472bb77-c09c-6bb4-c2df-aaf058ddfff8@oracle.com>
 <CALAJ+5CazNuRHvs_3MCQJPVZEUmEGgwMMmsA+TVYQ1Cn9Q6ekQ@mail.gmail.com>
 <e214e83e-5598-1c1d-a30c-327d0bd2ac77@oracle.com>
 <CALAJ+5BsB7j1ctBUo_nGw7Lsy3o0=QVS=nTzgD3pR5WY2U4jfA@mail.gmail.com>
Message-ID: <9b24b7e0-0894-21e5-52bd-136ebac17f3d@oracle.com>



On 10/18/2019 4:41 AM, Sverre Moe wrote:
> fre. 18. okt. 2019 kl. 01:17 skrev Alexey Semenyuk 
> <alexey.semenyuk at oracle.com <mailto:alexey.semenyuk at oracle.com>>:
>
>
>
>     On 10/17/2019 6:10 PM, Sverre Moe wrote:
>>     I wonder if there is something I can contribute with to improve
>>     the localization. Perhaps work further with the existing
>>     Localization that exists for WiX in jpackage.
>>
>>     I made some changes to the jpackage localization, that I can
>>     contribute (mentioned in Change 1). The 2 other changes mentioned
>>     below require a little discussion before beginning to implement.
>>
>>     *Change 1:* Add some missing localization for Strings on the
>>     installer information dialog for when folder already exists.
>>     ? installer.folder.exists.dialog.title = Setup
>>     ? installer.folder.exists.dialog.button.yes = Yes
>>     installer.folder.exists.dialog.button.no
>>     <http://installer.folder.exists.dialog.button.no> = No
>>
>>     These are the Dialog Strings defined strictly in jpackage
>>     template.wxs for the JpInvalidInstallDir dialog.
>     I'm confused. Do you mean main.wxs? There is no template.wxs file
>     in the sandbox, but there is main.wxs with JpInvalidInstallDir dialog.
>
> Yes, I meant the main.wxs. It defines a dialog for the invalid install 
> dir which has 4 Strings. Currently only one of these Strings has 
> localization in MsiInstallerStrings with jpackage, the three others 
> are missing.
>
> The Change 1 I proposed was to add the localization for these three 
> missing Strings to the existing 
> MsiInstallerString_en.wxl,?MsiInstallerString_ja.wxl and 
> MsiInstallerString_zh_CN.wxl
Sounds good.
You can create a ticket in Jira (You can use 
https://bugs.openjdk.java.net/browse/JDK-8230668 as a template for your 
ticket), send review request to this mail alias and your path will be 
integrated after review.
Details on submitting code reviews - 
https://openjdk.java.net/guide/codeReview.html

>
>>     The jpackage WiX template file is using the built-in
>>     WixUI_InstallDir dialog, and it has its own localization.
>>     https://wixtoolset.org//documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html
>>
>>     WiX has some support for localization. Perhaps extensive enough
>>     for most:
>>     en-us, hr-HR, lv-LV, ro-RO, uk-UA, ar-SA, es-es, hu-HU, ru-ru,
>>     zh-CN, bg-BG, et-EE, sk-SK, zh-HK, ca-ES, it-it, nb-NO, sl-SI,
>>     zh-TW, cs-CZ, fi-FI, ja-jp, nl-NL, sr-Latn-CS, da-DK, fr-fr,
>>     kk-KZ, pl-pl, sv-SE, de-de, he-IL, ko-KR, pt-BR, th-TH
>>
>>     The culture switch must be provided to light.exe in order to use
>>     anything other than English.
>>     Use "-culture:nb-no" for the nb_NO localization.
>>
>>     The cultures switch is not provided to light.exe by jpackage, and
>>     it is recommended by WiX.
>>     > The -loc flag is used to specify the language file to use. It
>>     is important to include the -cultures flag on the command line to
>>     ensure the correct localized strings are included for extensions
>>     such as WiXUIExtension.
>>
>>     I have tested this by manually running light.exe and it works
>>     fine. I got the Norwegian localization for the installer when I
>>     specified "-culture:nb_NO".
>     What type of localization you are looking for? MSI installers can
>     be built with multilingual support. I.e. you can build an MSI
>     package that would include English, Norwegian, German, etc.
>     localizations and pick the one at installation time. But this is
>     quite a complicated thing -
>     https://www.firegiant.com/wix/tutorial/transforms/morphing-installers/.
>     If you need only one language in your installer, then simple
>     "-culture:nb_NO" would be sufficient, of course.
>
> I had a single language installer in mind yes. I think the 
> morphing-installers would be much more difficult to implement support for.
> I think using the cultures switch with light.exe would suffice for 
> jpackage to support localization.
Agreed.

>>
>>     *Change 2:*?Add --win-culture, or --win-localization option to
>>     jpackage
>>     Provide the culture switch to light.exe as specified from the
>>     localization option.
>>     The second option is probably the best name. I would not even
>>     know what culture was about before looking into WiX, but everyone
>>     knows what localization means. The option approach would also
>>     allow users to run multiple executions of jpackage in order to
>>     build multiple installers in different languages.
>     Adding --win-localization command line option looks reasonable. In
>     case of missing .wxl file for requested localization in OpenJDK
>     you would drop one in resource directory. Of course we need to fix
>     jpackage to hook up .wxl files from resource directory. This
>     functionality is missing at the moment.
>
>>
>>     One caveat though: We need to support the same number of
>>     localizations in jpackage as WiX does. Otherwise if jpackage does
>>     not have its own localization for the specified culture switch,
>>     then building the installer will fail. It will fail for uknown
>>     localization variables on jpackage's own Strings.
>>     light.exe -culture:nb_NO MsiInstallerStrings_en.wxl
>>     error The localization variable !(loc.message.install.dir.exist)
>>     is unknown.
>>
>>     There are many localization files in WiX, but luckily jpackage
>>     has only 4 Strings of its own. It should not be that much work to
>>     make an MsiInstallerStrings file for each of the WiX localizations.
>     I don't think we would support any localization beyond English,
>     Japanese and Chinese Simplified in OpenJDK. Who would provide
>     translations in multiple languages on regular basis?
>
> All these three localizations are in English, so what is the point 
> then with Japanese and Chinese?
jpackage is not a part of OpenJDK yet, once this will be the case, we 
will have proper localization of that stub files.

> Perhaps jpackage should just support English localization as default. 
> and the user would have to customize to get another localization.
jpackage should support all localizations that OpenJDK supports.

>
> There is pre-existing localization in WiX for most of the installer UI 
> created with jpackage, but the cultures switch must be provided to use 
> them.
> While testing with WiX Localization I found that these cannot be used 
> unless the localization file provided by jpackage has the same language.
> WiX has Norwegian localization, among many other languages, while 
> jpackage does not.
> This will fail light.exe with an error:
> ? -cultures:nb-no -loc MsiInstallerStrings_en.wxl
> This will work though
> ? -cultures:nb-no -loc MsiInstallerStrings_nb_NO.wxl
Ok, so in jpackage we are missing:
1. Logic to pick up .wxl files from resource dir and use them with 
light.exe.
2. Option to specify value of -cultures light.exe option.

>
> This will also fail with Japanese and Chinese localization since they 
> have English en-us cultures set in their files.
> ? -cultures:ja -loc MsiInstallerStrings_ja.wxl
> ? -cultures:zh-cn -loc MsiInstallerStrings_zh_CN.wxl
> So currently the Japanese and Chinese localization are useless as they 
> are both in English.
Oh, en-us cultures set in MsiInstallerStrings_ja.wxl and in 
MsiInstallerStrings_zh_CN.wxl is a bug. Thank you for the catch!

>
> I found a way around this problem: The cultures switch support 
> fallback allowing the jpackage parts to remain in English, while the 
> rest is properly localized.
> ? -cultures:nb-no;en-us -loc MsiInstallerStrings_en.wxl
>
> That way we can support the extensive localization support in WiX, 
> while the same time keep the localization support in jpackage to a 
> minimum of English, Japanese and Chinese Simplified.
Good to know, thank you!

I've created https://bugs.openjdk.java.net/browse/JDK-8232621 to capture 
all l10n related issues of msi installers.

- Alexey

>>
>>     *Change 3:*
>>     All the WiX localization Strings can be overridden in the
>>     provided -loc MsiInstallerStrings.en.wxl file.
>>     We could support custom localization files in resource directory.
>>     It could allow users to provide localization which WiX does not
>>     have built-in support for, or just with different text for the
>>     existing localization Strings.
>>     > Using MsiInstallerStrings_en.wxl localization (specify
>>     application-name.wxl in resource-dir to customize)
>     This is good idea.
>
>     - Alexey
>


From alexey.semenyuk at oracle.com  Fri Oct 18 14:58:33 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 18 Oct 2019 10:58:33 -0400
Subject: RFR: JDK-8232281, , jpackage is not always reporting an error when
 no main class specified
In-Reply-To: <4f1a67e8-7ebc-4d55-1b55-45a46f83c585@oracle.com>
References: <4f1a67e8-7ebc-4d55-1b55-45a46f83c585@oracle.com>
Message-ID: <578f7c01-9be5-b17d-137c-4f64cd577b3d@oracle.com>

Looks good.

- Alexey

On 10/18/2019 10:53 AM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This fixes the case where using runtime-image prevented checking for 
> no main class being specified.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232281
>
> [2] http://cr.openjdk.java.net/~herrick/8232281/webrev.01/index.html
>
> /Andy
>


From ioi.lam at oracle.com  Fri Oct 18 17:36:56 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 18 Oct 2019 10:36:56 -0700
Subject: Loading classes during VM shutdown
Message-ID: <de6eeace-0559-7e29-c4ad-a5b80df84c72@oracle.com>

For JDK-8232081 (Try to link all classes with ArchiveClassesAtExit), 
when creating a dynamic CDS archive, I need to link all classes in the 
"loaded" state. I am thinking of doing it at this point:

src/java.base/share/classes/java/lang/Shutdown.java:

 ??? private static void runHooks() {
 ??????? synchronized (lock) {
 ??????????? /* Guard against the possibility of a daemon thread 
invoking exit
 ???????????? * after DestroyJavaVM initiates the shutdown sequence
 ???????????? */
 ??????????? if (VM.isShutdown()) return;
 ??????? }

 ??????? for (int i=0; i < MAX_SYSTEM_HOOKS; i++) {
 ??????????? try {
 ??????????????? Runnable hook;
 ??????????????? synchronized (lock) {
 ??????????????????? // acquire the lock to make sure the hook 
registered during
 ??????????????????? // shutdown is visible here.
 ??????????????????? currentRunningHook = i;
 ??????????????????? hook = hooks[i];
 ??????????????? }
 ??????????????? if (hook != null) hook.run();
 ??????????? } catch (Throwable t) {
 ??????????????? if (t instanceof ThreadDeath) {
 ??????????????????? ThreadDeath td = (ThreadDeath)t;
 ??????????????????? throw td;
 ??????????????? }
 ??????????? }
 ??????? }

+ ? ? ? VM.linkClassesIfDumpingDynamicArchive(); <<<<<<<<

 ??????? // set shutdown state
 ??????? VM.shutdown();
 ??? }

To be safe, I will only link classes loaded by the built-in loaders 
(boot/platform/system). The reasons is linking classes may result in 
more class loading, which would execute Java code in the class loaders. 
I worry that arbitrary custom class loaders may not work well when 
executed in this context, but the built-in loader should be OK. After 
all, regular Shutdown hooks could (I think??) load classes ....

Does anyone see a problem with doing this?

Thanks
- Ioi

From mandy.chung at oracle.com  Fri Oct 18 20:56:34 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 18 Oct 2019 13:56:34 -0700
Subject: Review Request JDK-8232617: Update the outdated code comments in
 java.lang.System class
Message-ID: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>

A trivial doc fix:


diff --git a/src/java.base/share/classes/java/lang/System.java b/src/java.base/share/classes/java/lang/System.java
--- a/src/java.base/share/classes/java/lang/System.java
+++ b/src/java.base/share/classes/java/lang/System.java
@@ -94,10 +94,8 @@
  public final class System {
      /* Register the natives via the static initializer.
       *
-     * VM will invoke the initializeSystemClass method to complete
-     * the initialization for this class separated from clinit.
-     * Note that to use properties set by the VM, see the constraints
-     * described in the initializeSystemClass method.
+     * VM will invoke the initPhase1 method to complete the initialization
+     * for this class separated from <clinit>.
       */
      private static native void registerNatives();
      static {



Thanks
Mandy


From brent.christian at oracle.com  Fri Oct 18 21:46:21 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 18 Oct 2019 14:46:21 -0700
Subject: Review Request JDK-8232617: Update the outdated code comments in
 java.lang.System class
In-Reply-To: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>
References: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>
Message-ID: <9b6fc41e-ebea-17ef-15b6-fc5b5d3c5d3e@oracle.com>

Looks fine.  You might consider s/separated/separately/ .

-Brent

On 10/18/19 1:56 PM, Mandy Chung wrote:
> A trivial doc fix:
> 
> 
> diff --git a/src/java.base/share/classes/java/lang/System.java 
> b/src/java.base/share/classes/java/lang/System.java
> --- a/src/java.base/share/classes/java/lang/System.java
> +++ b/src/java.base/share/classes/java/lang/System.java
> @@ -94,10 +94,8 @@
>  ?public final class System {
>  ???? /* Register the natives via the static initializer.
>  ????? *
> -???? * VM will invoke the initializeSystemClass method to complete
> -???? * the initialization for this class separated from clinit.
> -???? * Note that to use properties set by the VM, see the constraints
> -???? * described in the initializeSystemClass method.
> +???? * VM will invoke the initPhase1 method to complete the initialization
> +???? * for this class separated from <clinit>.
>  ????? */
>  ???? private static native void registerNatives();
>  ???? static {
> 
> 
> 
> Thanks
> Mandy
> 

From alexander.matveev at oracle.com  Fri Oct 18 21:51:49 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 18 Oct 2019 14:51:49 -0700
Subject: RFR: JDK-8232281, , jpackage is not always reporting an error when
 no main class specified
In-Reply-To: <4f1a67e8-7ebc-4d55-1b55-45a46f83c585@oracle.com>
References: <4f1a67e8-7ebc-4d55-1b55-45a46f83c585@oracle.com>
Message-ID: <5b6963c7-1b36-d55a-591e-2220283592e8@oracle.com>

Looks good.

On 10/18/2019 7:53 AM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This fixes the case where using runtime-image prevented checking for 
> no main class being specified.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232281
>
> [2] http://cr.openjdk.java.net/~herrick/8232281/webrev.01/index.html
>
> /Andy
>


From alexander.matveev at oracle.com  Fri Oct 18 22:15:28 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 18 Oct 2019 15:15:28 -0700
Subject: RFR: JDK-8223325: Improve wix sources generated by jpackage
In-Reply-To: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
References: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
 <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
Message-ID: <7c847b97-6a50-c8a9-3464-59061125f23c@oracle.com>

Hi Alexey,

http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java.frames.html
Line 180: man -> main

http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java.frames.html
createXml() should we force it to UTF-8? Like we did in MacPkgBundler.

http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java.html
findWixInstallDirs() I think we used to check PATH variable as well for 
Wix. In any case this needs to be fixed. We cannot assume "C:\Program 
Files". This folder can be on different drive, so it is better to use 
Windows API to get path to "Program Files". Also, user might install Wix 
into different folder. I think it is better to file a bug and improve it 
eventually.

Looks good overall.

Thanks,
Alexander

On 10/17/19 3:24 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - moved code creating WiX sources for app image from WinMsiBundler in 
> a separate class - WixSourcesBuilder;
> - put at most one file in component in WiX sources;
> - use StAX to create WiX sources;
> - added IOUtils.createXml function to simplify xml creation;
> - added basic javadoc to AppImageFile class;
> - added support for use of icons in file associations test for better 
> coverage;
> - fixed the bug with not excluded `.jpackage.xml` from installed app 
> image on Windows;
> - improved test output isolation when jpackage tests are executed not 
> with jtreg framework;
> - bugfix of MainClassTest test class;
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223325
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/
>


From alexey.semenyuk at oracle.com  Fri Oct 18 23:25:48 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 18 Oct 2019 19:25:48 -0400
Subject: RFR: JDK-8223325: Improve wix sources generated by jpackage
In-Reply-To: <7c847b97-6a50-c8a9-3464-59061125f23c@oracle.com>
References: <1d364027-0243-cc41-486e-69120e259d15@oracle.com>
 <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
 <7c847b97-6a50-c8a9-3464-59061125f23c@oracle.com>
Message-ID: <a7f4ad81-0240-94e5-6c0c-d068105791e3@oracle.com>

Little bit late, Andy has pushed the patch already. Please find my 
comment below.

On 10/18/2019 6:15 PM, Alexander Matveev wrote:
> Hi Alexey,
>
> http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java.frames.html 
>
> Line 180: man -> main
>
> http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java.frames.html 
>
> createXml() should we force it to UTF-8? Like we did in MacPkgBundler.
XMLStreamWriter.writeStartDocument() without arguments should create 
`<?xml version=?1.0? encoding=?utf-8??>` xml declaration.
I'm not sure though that UTF-8 encoding would be used for underlying 
java.io.Writer. I agree this should be reworked to make sure we save xml 
in file with UTF-8 encoding.

> http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java.html 
>
> findWixInstallDirs() I think we used to check PATH variable as well 
> for Wix. 
The same approach is used in WixTool. But instead of parsing PATH 
variable jpackage tries to launch light.exe or candle.exe without 
specifying full paths to them first, i.e. it checks if they are in PATH 
without parsing value of PATH variable. In case of failure it checks for 
well known install dirs. Please look at WixTool.find() method for the 
logic of locating WiX tools.

> In any case this needs to be fixed. We cannot assume "C:\Program Files". 
Agree.

> This folder can be on different drive, so it is better to use Windows 
> API to get path to "Program Files". 
There is environment variable for program files - PROGRAMFILES. However 
it is not always set (e.g. jtreg resets it). Another approach would be 
to query registry value for the path to program files folder. So there 
are different options.
I just decided not to touch "C:\Program Files" as the patch is already 
quite messy.

I created follow up for your findings - 
https://bugs.openjdk.java.net/browse/JDK-8232646.

- Alexey

> Also, user might install Wix into different folder. I think it is 
> better to file a bug and improve it eventually.
>
> Looks good overall.
>
> Thanks,
> Alexander
>
> On 10/17/19 3:24 PM, Alexey Semenyuk wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> - moved code creating WiX sources for app image from WinMsiBundler in 
>> a separate class - WixSourcesBuilder;
>> - put at most one file in component in WiX sources;
>> - use StAX to create WiX sources;
>> - added IOUtils.createXml function to simplify xml creation;
>> - added basic javadoc to AppImageFile class;
>> - added support for use of icons in file associations test for better 
>> coverage;
>> - fixed the bug with not excluded `.jpackage.xml` from installed app 
>> image on Windows;
>> - improved test output isolation when jpackage tests are executed not 
>> with jtreg framework;
>> - bugfix of MainClassTest test class;
>>
>> - Alexey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223325
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8223325/webrev.00/
>>
>


From mandy.chung at oracle.com  Sat Oct 19 00:38:11 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 18 Oct 2019 17:38:11 -0700
Subject: Review Request JDK-8232617: Update the outdated code comments in
 java.lang.System class
In-Reply-To: <9b6fc41e-ebea-17ef-15b6-fc5b5d3c5d3e@oracle.com>
References: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>
 <9b6fc41e-ebea-17ef-15b6-fc5b5d3c5d3e@oracle.com>
Message-ID: <4ac452cd-08b3-01be-7e11-43fe9127aae8@oracle.com>

thanks. I think "separated from" reads right to me.? I will leave it as is.

Mandy

On 10/18/19 2:46 PM, Brent Christian wrote:
> Looks fine.? You might consider s/separated/separately/ .
>
> -Brent
>
> On 10/18/19 1:56 PM, Mandy Chung wrote:
>> A trivial doc fix:
>>
>>
>> diff --git a/src/java.base/share/classes/java/lang/System.java 
>> b/src/java.base/share/classes/java/lang/System.java
>> --- a/src/java.base/share/classes/java/lang/System.java
>> +++ b/src/java.base/share/classes/java/lang/System.java
>> @@ -94,10 +94,8 @@
>> ??public final class System {
>> ????? /* Register the natives via the static initializer.
>> ?????? *
>> -???? * VM will invoke the initializeSystemClass method to complete
>> -???? * the initialization for this class separated from clinit.
>> -???? * Note that to use properties set by the VM, see the constraints
>> -???? * described in the initializeSystemClass method.
>> +???? * VM will invoke the initPhase1 method to complete the 
>> initialization
>> +???? * for this class separated from <clinit>.
>> ?????? */
>> ????? private static native void registerNatives();
>> ????? static {
>>
>>
>>
>> Thanks
>> Mandy
>>


From Alan.Bateman at oracle.com  Sat Oct 19 07:36:25 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 19 Oct 2019 08:36:25 +0100
Subject: RFR: 8232161 Unexpected 1-way trip conversion entries on MS950
 charset
In-Reply-To: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
Message-ID: <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>

On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
> Hello.
>
> Could you review the fix ?
>
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>
> I have a concern about 1-way trip conversion entries (4 entries) on 
> MS950 charset.
> The detail information is in JDK-8232161 [1]
>
Do you know any sense on the compatibility impact of changing this? I 
think Naoto has the same question and we aren't sure if this one with 
need a compatibility property. I think it will need a CSR.

-Alan


From alexey.ivanov at oracle.com  Sun Oct 20 16:20:09 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Sun, 20 Oct 2019 17:20:09 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
Message-ID: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>

Hello,

Please review the following fix which it brings back NewStringPlatform 
alias for JNU_NewStringPlatform. Without it, 32 bit Windows build of 
Java does not work.

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

-- 
Regards,
Alexey

From Alan.Bateman at oracle.com  Sun Oct 20 18:24:15 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 20 Oct 2019 19:24:15 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
Message-ID: <04db5883-0aa4-45de-681d-d05779f196a8@oracle.com>

On 20/10/2019 17:20, Alexey Ivanov wrote:
> Hello,
>
> Please review the following fix which it brings back NewStringPlatform 
> alias for JNU_NewStringPlatform. Without it, 32 bit Windows build of 
> Java does not work.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8232624
> webrev: http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
This looks okay.

-Alan

From david.holmes at oracle.com  Sun Oct 20 22:29:11 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Oct 2019 08:29:11 +1000
Subject: Loading classes during VM shutdown
In-Reply-To: <de6eeace-0559-7e29-c4ad-a5b80df84c72@oracle.com>
References: <de6eeace-0559-7e29-c4ad-a5b80df84c72@oracle.com>
Message-ID: <d132ef3a-e8f1-1bad-5809-35ecdec1e467@oracle.com>

Hi Ioi,

On 19/10/2019 3:36 am, Ioi Lam wrote:
> For JDK-8232081 (Try to link all classes with ArchiveClassesAtExit), 
> when creating a dynamic CDS archive, I need to link all classes in the 
> "loaded" state. I am thinking of doing it at this point:
> 
> src/java.base/share/classes/java/lang/Shutdown.java:
> 
>  ??? private static void runHooks() {
>  ??????? synchronized (lock) {
>  ??????????? /* Guard against the possibility of a daemon thread 
> invoking exit
>  ???????????? * after DestroyJavaVM initiates the shutdown sequence
>  ???????????? */
>  ??????????? if (VM.isShutdown()) return;
>  ??????? }
> 
>  ??????? for (int i=0; i < MAX_SYSTEM_HOOKS; i++) {
>  ??????????? try {
>  ??????????????? Runnable hook;
>  ??????????????? synchronized (lock) {
>  ??????????????????? // acquire the lock to make sure the hook 
> registered during
>  ??????????????????? // shutdown is visible here.
>  ??????????????????? currentRunningHook = i;
>  ??????????????????? hook = hooks[i];
>  ??????????????? }
>  ??????????????? if (hook != null) hook.run();
>  ??????????? } catch (Throwable t) {
>  ??????????????? if (t instanceof ThreadDeath) {
>  ??????????????????? ThreadDeath td = (ThreadDeath)t;
>  ??????????????????? throw td;
>  ??????????????? }
>  ??????????? }
>  ??????? }
> 
> + ? ? ? VM.linkClassesIfDumpingDynamicArchive(); <<<<<<<<
> 
>  ??????? // set shutdown state
>  ??????? VM.shutdown();
>  ??? }
> 
> To be safe, I will only link classes loaded by the built-in loaders 
> (boot/platform/system). The reasons is linking classes may result in 
> more class loading, which would execute Java code in the class loaders. 
> I worry that arbitrary custom class loaders may not work well when 
> executed in this context, but the built-in loader should be OK. After 
> all, regular Shutdown hooks could (I think??) load classes ....
> 
> Does anyone see a problem with doing this?

When you say "built-in" do you mean all of the boot/platform/app loaders?

Any non-trivial execution of Java code could potentially have a bad 
interaction if run after shutdown hooks have completed.

Cheers,
David

> Thanks
> - Ioi

From david.holmes at oracle.com  Sun Oct 20 22:50:13 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Oct 2019 08:50:13 +1000
Subject: Review Request JDK-8232617: Update the outdated code comments in
 java.lang.System class
In-Reply-To: <4ac452cd-08b3-01be-7e11-43fe9127aae8@oracle.com>
References: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>
 <9b6fc41e-ebea-17ef-15b6-fc5b5d3c5d3e@oracle.com>
 <4ac452cd-08b3-01be-7e11-43fe9127aae8@oracle.com>
Message-ID: <2edc94ef-7cf6-4705-c129-b1c38bd6cdd2@oracle.com>

On 19/10/2019 10:38 am, Mandy Chung wrote:
> thanks. I think "separated from" reads right to me.? I will leave it as is.

I think "separately" or "separate" seems more correct here. And if we're 
picking on grammar then it should be "The VM ..." and "of this class" 
rather than "for this class".

Cheers,
David

> Mandy
> 
> On 10/18/19 2:46 PM, Brent Christian wrote:
>> Looks fine.? You might consider s/separated/separately/ .
>>
>> -Brent
>>
>> On 10/18/19 1:56 PM, Mandy Chung wrote:
>>> A trivial doc fix:
>>>
>>>
>>> diff --git a/src/java.base/share/classes/java/lang/System.java 
>>> b/src/java.base/share/classes/java/lang/System.java
>>> --- a/src/java.base/share/classes/java/lang/System.java
>>> +++ b/src/java.base/share/classes/java/lang/System.java
>>> @@ -94,10 +94,8 @@
>>> ??public final class System {
>>> ????? /* Register the natives via the static initializer.
>>> ?????? *
>>> -???? * VM will invoke the initializeSystemClass method to complete
>>> -???? * the initialization for this class separated from clinit.
>>> -???? * Note that to use properties set by the VM, see the constraints
>>> -???? * described in the initializeSystemClass method.
>>> +???? * VM will invoke the initPhase1 method to complete the 
>>> initialization
>>> +???? * for this class separated from <clinit>.
>>> ?????? */
>>> ????? private static native void registerNatives();
>>> ????? static {
>>>
>>>
>>>
>>> Thanks
>>> Mandy
>>>
> 

From david.holmes at oracle.com  Sun Oct 20 22:59:52 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Oct 2019 08:59:52 +1000
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
Message-ID: <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>

Hi Alexey,

On 21/10/2019 2:20 am, Alexey Ivanov wrote:
> Hello,
> 
> Please review the following fix which it brings back NewStringPlatform 
> alias for JNU_NewStringPlatform. Without it, 32 bit Windows build of 
> Java does not work.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8232624
> webrev: http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/

Not sure this is the correct fix. The problem as I see it is that 
NewStringPlatform was not declared as a JNICALL previously whereas the 
JNU_NewStringPLatform is. That affects the linkage on 32-bit Windows only.

David


From alexey.ivanov at oracle.com  Sun Oct 20 23:37:11 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 21 Oct 2019 00:37:11 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
Message-ID: <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>

Hi David,

On 20/10/2019 23:59, David Holmes wrote:
> Hi Alexey,
>
> On 21/10/2019 2:20 am, Alexey Ivanov wrote:
>> Hello,
>>
>> Please review the following fix which it brings back 
>> NewStringPlatform alias for JNU_NewStringPlatform. Without it, 32 bit 
>> Windows build of Java does not work.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8232624
>> webrev: http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
>
> Not sure this is the correct fix. The problem as I see it is that 
> NewStringPlatform was not declared as a JNICALL previously whereas the 
> JNU_NewStringPLatform is. That affects the linkage on 32-bit Windows only.

Yes, JNICALL affects 32-bit Windows only. And this is exactly why 
"JNU_NewStringPLatform" cannot be found by its name on 32-bit Windows; 
"NewStringPlatform" is not declared as JNICALL and it can be found by 
its undecorated name on 32-bit Windows and all the other platforms. I 
believe it's the reason why this alias exists.

Another way to fix it is to lookup the undecorated name first and, if it 
fails, to lookup the decorated name, which makes the code harder to read.

With this patch, I'm reverting the code to the state it was before.

>
> David
-- 
Regards,
Alexey

From david.holmes at oracle.com  Mon Oct 21 01:19:12 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Oct 2019 11:19:12 +1000
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
Message-ID: <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>

Hi Alexey,

On 21/10/2019 9:37 am, Alexey Ivanov wrote:
> Hi David,
> 
> On 20/10/2019 23:59, David Holmes wrote:
>> Hi Alexey,
>>
>> On 21/10/2019 2:20 am, Alexey Ivanov wrote:
>>> Hello,
>>>
>>> Please review the following fix which it brings back 
>>> NewStringPlatform alias for JNU_NewStringPlatform. Without it, 32 bit 
>>> Windows build of Java does not work.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232624
>>> webrev: http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
>>
>> Not sure this is the correct fix. The problem as I see it is that 
>> NewStringPlatform was not declared as a JNICALL previously whereas the 
>> JNU_NewStringPLatform is. That affects the linkage on 32-bit Windows 
>> only.
> 
> Yes, JNICALL affects 32-bit Windows only. And this is exactly why 
> "JNU_NewStringPLatform" cannot be found by its name on 32-bit Windows; 
> "NewStringPlatform" is not declared as JNICALL and it can be found by 
> its undecorated name on 32-bit Windows and all the other platforms. I 
> believe it's the reason why this alias exists.

So what would happen if we drop the JNICALL from JNU_NewStringPLatform?

> Another way to fix it is to lookup the undecorated name first and, if it 
> fails, to lookup the decorated name, which makes the code harder to read.
> 
> With this patch, I'm reverting the code to the state it was before.

Yes, but Claes didn't like the way it was before :) so I'm hoping we can 
keep his cleanup whilst still allowing Windows to work correctly.

Thanks,
David

>>
>> David

From amy.lu at oracle.com  Mon Oct 21 03:13:05 2019
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 21 Oct 2019 11:13:05 +0800
Subject: [JDK 14] RFR 8232195: Enable BigInteger tests: DivisionOverflow, 
 SymmetricRangeTests and StringConstructorOverflow
In-Reply-To: <d8b3b9ab-952d-da92-527d-ea313add7892@oracle.com>
References: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>
 <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>
 <f47fa9f9-c8a2-3e3b-c28d-8a484b854eaa@oracle.com>
 <d8b3b9ab-952d-da92-527d-ea313add7892@oracle.com>
Message-ID: <7343308a-ff96-ec76-8eed-0fbb691efb5a@oracle.com>

Hearing no other concerns, I'll do push soon.

Thanks,
Amy

On 10/16/19 5:49 PM, Amy Lu wrote:
> Hi, Joe
>
> I checked the elapsed time:
>
> DivisionOverflow.java????????? <10 seconds? (normally 3 seconds)
> StringConstructorOverflow.java <20 seconds? (normally 8 seconds)
> SymmetricRangeTests.java?????? <100 seconds (normally 60-80 seconds)
>
> I think it's fine and worth to enable them in standard testing. I'll 
> continue monitor the results and make necessary adjustment if they 
> cause any issue.
>
> Any concerns? Please let me know.
>
> Thanks,
> Amy
>
> On 10/16/19 9:31 AM, Joe Darcy wrote:
>> Hello,
>>
>> How long to the tests take to run when they actually run?
>>
>> (It would be helpful to have a setting in jtreg that could indicate 
>> "its okay to run the slow tests" or "run the more extensive set of 
>> test vectors," but we haven't defined such a mechanism as of yet.)
>>
>> Thanks,
>>
>> -Joe
>>
>> On 10/15/2019 8:33 AM, Brian Burkhalter wrote:
>>> Hi Amy,
>>>
>>> This looks OK. It looks like DivisionOverflow was already being run 
>>> however.
>>>
>>> Also, the navigation in your webrev is broken: is your script current?
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>>> On Oct 14, 2019, at 10:05 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>>
>>>> test/jdk/java/math/BigInteger/DivisionOverflow.java
>>>> test/jdk/java/math/BigInteger/StringConstructorOverflow.java
>>>> test/jdk/java/math/BigInteger/SymmetricRangeTests.java
>>>>
>>>> These tests require huge memory and need to run with -Xmx8g
>>>> They are skipped or tagged with @ignore and not actually run in 
>>>> standard testing by jtreg.
>>>>
>>>> Please review the patch to enable them by:
>>>> * Adding @requires os.maxMemory > 8g
>>>> * Put them into exclusiveAccess.dirs (so they won't run 
>>>> concurrently) to reduce the risk of impact other test.
>>>>
>>>> Tested on all platforms with small (<8g) or large memory machines.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232195 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8232195>
>>>> webrev: http://cr.openjdk.java.net/~amlu/8232195/webrev.00/ 
>>>> <http://cr.openjdk.java.net/~amlu/8232195/webrev.00/>
>


From Alan.Bateman at oracle.com  Mon Oct 21 06:26:03 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 21 Oct 2019 07:26:03 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
Message-ID: <f87c84c0-5cd6-41fc-51f4-2518e3ec1676@oracle.com>

On 21/10/2019 00:37, Alexey Ivanov wrote:
>
> Yes, JNICALL affects 32-bit Windows only. And this is exactly why 
> "JNU_NewStringPLatform" cannot be found by its name on 32-bit Windows; 
> "NewStringPlatform" is not declared as JNICALL and it can be found by 
> its undecorated name on 32-bit Windows and all the other platforms. I 
> believe it's the reason why this alias exists.
>
> Another way to fix it is to lookup the undecorated name first and, if 
> it fails, to lookup the decorated name, which makes the code harder to 
> read.
>
> With this patch, I'm reverting the code to the state it was before.
If you are blocked building Windows 32-bit then reverting that part, as 
you've proposed, should be okay. You can create a second issue to re-do 
the cleanup.

-Alan

From nicolas.roduit at mycable.ch  Sun Oct 20 13:49:13 2019
From: nicolas.roduit at mycable.ch (Nicolas Roduit)
Date: Sun, 20 Oct 2019 15:49:13 +0200
Subject: Jpackage - Limitation with WiX script
Message-ID: <b4c0e8b9-e4b7-d30c-4ae8-623279ca520b@mycable.ch>

Hi,

Previously the WiX script could be overloaded in the resource directory 
but not anymore. Is there a reason?

It seems important to me to be able to modify the script for real-world 
applications. For example, my needs are:
- To build 32-bit package (changing InstallScope="$(var.JpInstallScope)" 
Platform="x64"/>)
- Package compression
- Add an icon to the package
- Register a custom URI scheme to launch the application in a web context
- Adding a policy to chrome
...

Here is a patch proposal:


--- 
a/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java 
Sat Oct 19 09:50:19 2019 +0200
+++ 
b/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java 
Sun Oct 20 12:10:26 2019 +0200
@@ -425,10 +425,8 @@
 ???????????? }
 ???????? }

-??????? try (InputStream is = 
OverridableResource.readDefault("main.wxs")) {
-??????????? Files.copy(is, Paths.get(
- getConfig_ProjectFile(params).getAbsolutePath()));
-??????? }
+??????? Path wixScript = 
Paths.get(getConfig_ProjectFile(params).getAbsolutePath());
+??????? createResource("main.wxs", params).saveToFile(wixScript);

 ???????? return data;
 ???? }


Kind Regards,

Nicolas


From aph at redhat.com  Mon Oct 21 09:31:20 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 21 Oct 2019 10:31:20 +0100
Subject: [JDK 14] RFR 8232195: Enable BigInteger tests: DivisionOverflow, 
 SymmetricRangeTests and StringConstructorOverflow
In-Reply-To: <d8b3b9ab-952d-da92-527d-ea313add7892@oracle.com>
References: <d851aecf-5c92-7a4b-0e03-6f110985c804@oracle.com>
 <F2B86961-5167-4429-96BD-59309A1C646A@oracle.com>
 <f47fa9f9-c8a2-3e3b-c28d-8a484b854eaa@oracle.com>
 <d8b3b9ab-952d-da92-527d-ea313add7892@oracle.com>
Message-ID: <0c9d5362-1c7d-a7ca-cbd8-08d8790df6a5@redhat.com>

On 10/16/19 10:49 AM, Amy Lu wrote:
> I think it's fine and worth to enable them in standard testing. I'll 
> continue monitor the results and make necessary adjustment if they cause 
> any issue.
> 
> Any concerns? Please let me know.

It might be worth disabling such tests in Zero builds.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From alexey.ivanov at oracle.com  Mon Oct 21 12:14:01 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 21 Oct 2019 13:14:01 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
Message-ID: <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>

Hi David,

On 21/10/2019 02:19, David Holmes wrote:
> Hi Alexey,
>
> On 21/10/2019 9:37 am, Alexey Ivanov wrote:
>> Hi David,
>>
>> On 20/10/2019 23:59, David Holmes wrote:
>>> Hi Alexey,
>>>
>>> On 21/10/2019 2:20 am, Alexey Ivanov wrote:
>>>> Hello,
>>>>
>>>> Please review the following fix which it brings back 
>>>> NewStringPlatform alias for JNU_NewStringPlatform. Without it, 32 
>>>> bit Windows build of Java does not work.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232624
>>>> webrev: http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
>>>
>>> Not sure this is the correct fix. The problem as I see it is that 
>>> NewStringPlatform was not declared as a JNICALL previously whereas 
>>> the JNU_NewStringPLatform is. That affects the linkage on 32-bit 
>>> Windows only.
>>
>> Yes, JNICALL affects 32-bit Windows only. And this is exactly why 
>> "JNU_NewStringPLatform" cannot be found by its name on 32-bit 
>> Windows; "NewStringPlatform" is not declared as JNICALL and it can be 
>> found by its undecorated name on 32-bit Windows and all the other 
>> platforms. I believe it's the reason why this alias exists.
>
> So what would happen if we drop the JNICALL from JNU_NewStringPLatform?

Yes, it will be found by its undecorated name too.
But I'd rather not change the calling conventions of functions with JNU_ 
prefix.

So, I think the proposed patch is the easiest and safest way to fix 
32-bit Windows build.

>> Another way to fix it is to lookup the undecorated name first and, if 
>> it fails, to lookup the decorated name, which makes the code harder 
>> to read.
>>
>> With this patch, I'm reverting the code to the state it was before.
>
> Yes, but Claes didn't like the way it was before :) so I'm hoping we 
> can keep his cleanup whilst still allowing Windows to work correctly.

Probably, Claes thought "NewStringPlatform" wasn't used. Yet it proved 
that "NewStringPlatform" is still used.

If required, I can create a follow-up issue to re-do the cleanup as Alan 
suggested.

-- 
Regards,
Alexey

From claes.redestad at oracle.com  Mon Oct 21 12:49:19 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 21 Oct 2019 14:49:19 +0200
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
 <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
Message-ID: <e3c61b49-d923-07a1-a70c-ff080a10e4d9@oracle.com>

On 2019-10-21 14:14, Alexey Ivanov wrote:
> 
> Probably, Claes thought "NewStringPlatform" wasn't used. Yet it proved 
> that "NewStringPlatform" is still used.
> 
> If required, I can create a follow-up issue to re-do the cleanup as Alan 
> suggested.

Yes, please. If some or even just one platform needs a special,
undecorated alias for this type of internal dll_lookup to work, it seems
prudent to add it back in a way that doesn't add it back (along with a
possibly non-free indirection) to every other platform.

/Claes

From david.holmes at oracle.com  Mon Oct 21 13:00:46 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Oct 2019 23:00:46 +1000
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
 <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
Message-ID: <64e1bdf8-3f03-e6cc-a478-e52870e28464@oracle.com>



On 21/10/2019 10:14 pm, Alexey Ivanov wrote:
> Hi David,
> 
> On 21/10/2019 02:19, David Holmes wrote:
>> Hi Alexey,
>>
>> On 21/10/2019 9:37 am, Alexey Ivanov wrote:
>>> Hi David,
>>>
>>> On 20/10/2019 23:59, David Holmes wrote:
>>>> Hi Alexey,
>>>>
>>>> On 21/10/2019 2:20 am, Alexey Ivanov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following fix which it brings back 
>>>>> NewStringPlatform alias for JNU_NewStringPlatform. Without it, 32 
>>>>> bit Windows build of Java does not work.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232624
>>>>> webrev: http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
>>>>
>>>> Not sure this is the correct fix. The problem as I see it is that 
>>>> NewStringPlatform was not declared as a JNICALL previously whereas 
>>>> the JNU_NewStringPLatform is. That affects the linkage on 32-bit 
>>>> Windows only.
>>>
>>> Yes, JNICALL affects 32-bit Windows only. And this is exactly why 
>>> "JNU_NewStringPLatform" cannot be found by its name on 32-bit 
>>> Windows; "NewStringPlatform" is not declared as JNICALL and it can be 
>>> found by its undecorated name on 32-bit Windows and all the other 
>>> platforms. I believe it's the reason why this alias exists.
>>
>> So what would happen if we drop the JNICALL from JNU_NewStringPLatform?
> 
> Yes, it will be found by its undecorated name too.
> But I'd rather not change the calling conventions of functions with JNU_ 
> prefix.

Yes you are right. All the JNU_ methods are declared as JNICALL and they 
all work fine.

The issue/problem here is that we have the JVM using os::dll_lookup to 
find a method back in libjava and that can't be a JNICALL else the 
lookup won't work (without jumping through extra hoops).


> So, I think the proposed patch is the easiest and safest way to fix 
> 32-bit Windows build.

Yes I now agree. Thanks for bearing with me.

>>> Another way to fix it is to lookup the undecorated name first and, if 
>>> it fails, to lookup the decorated name, which makes the code harder 
>>> to read.
>>>
>>> With this patch, I'm reverting the code to the state it was before.
>>
>> Yes, but Claes didn't like the way it was before :) so I'm hoping we 
>> can keep his cleanup whilst still allowing Windows to work correctly.
> 
> Probably, Claes thought "NewStringPlatform" wasn't used. Yet it proved 
> that "NewStringPlatform" is still used.
> 
> If required, I can create a follow-up issue to re-do the cleanup as Alan 
> suggested.

Okay. Though I'm not sure what form that might take.

Thanks,
David

From aleksej.efimov at oracle.com  Mon Oct 21 13:09:24 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 21 Oct 2019 14:09:24 +0100
Subject: RFR(XS): 8232713: Update BCEL version to 6.3.1 in license file
Message-ID: <33c8fc27-afa8-2be0-9520-f13d38365863@oracle.com>

Hi,

The BCEL version has been updated to 6.3.1 by JDK-8224157 [1]. The BCEL 
license file needs to be updated to include the correct version.

Webrev: http://cr.openjdk.java.net/~aefimov/8232713/00

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


With Best Regards,
Aleksei

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

From rkennke at redhat.com  Mon Oct 21 13:45:26 2019
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 21 Oct 2019 15:45:26 +0200
Subject: RFR: 8213325: (props) Properties.loadFromXML does not fully
 comply with the spec
In-Reply-To: <465b5374-b539-164a-9fcb-7789c77212c5@redhat.com>
References: <1d0a8a5d-3467-99ed-3dff-187b70ea95fa@redhat.com>
 <e2b6cb07-d0d7-cfea-da60-7ec19809b176@redhat.com>
 <465b5374-b539-164a-9fcb-7789c77212c5@redhat.com>
Message-ID: <9e6ecbaa-b5b0-8cc9-0aaf-f23b1015ec2b@redhat.com>

(adding core-libs-dev)

Ping?


> I just realized that this has still not been reviewed. Can I do anything
> to move forward?
> 
> Thanks,
> Roman
> 
>> I added one extra verification to the JAXP based properties parser to
>> verify that no extra internal DTD is being supplied. As far as I can
>> tell, the other checks that have been added to the ukit parser for this
>> bug are already done by the JAXP parser, by validating the XML against
>> the built-in DTD.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.01/
>>
>> This passes all relevant tests, and I also run tier1 w/o regressions.
>>
>> What do you think?
>>
>> Roman
>>
>>> This is a backport of:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8227274
>>>
>>> which is a backport of the original:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8213325
>>>
>>> It's mostly the original change with a few significant extra modifications:
>>>
>>> -
>>> src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider
>>>
>>> is changed from:
>>> sun.util.xml.PlatformXmlPropertiesProvider
>>>
>>> to:
>>> jdk.internal.util.xml.BasicXmlPropertiesProvider
>>>
>>> The reason is that the fix is for the latter, but 8u uses the former by
>>> default. As far as I understand, the latter uses the new slimmer parser,
>>> while the former uses the fullblown XML parser, but I am not sure about
>>> that. However, we need to consider this, because it might be a very
>>> significant change.
>>>
>>> The alternative would be to port over the fixes to the other XML parser,
>>> which I have no desire to do.
>>>
>>> - The (test) JAR file:
>>> test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar
>>>
>>> has been regenerated from the modified sources XmlRB.xml and XmlRB_ja.xml.
>>>
>>> This is not present in jdk11 and later. I think it's generated on the
>>> fly and not checked-in.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.00/
>>>
>>> Testing: New testcases are passing. No regressions in tier1 tests.
>>>
>>> Opinions? Can I get reviews?
>>>
>>> Thanks,
>>> Roman
>>>
>>
> 


From andy.herrick at oracle.com  Mon Oct 21 13:58:01 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 21 Oct 2019 09:58:01 -0400
Subject: Jpackage - Limitation with WiX script
In-Reply-To: <b4c0e8b9-e4b7-d30c-4ae8-623279ca520b@mycable.ch>
References: <b4c0e8b9-e4b7-d30c-4ae8-623279ca520b@mycable.ch>
Message-ID: <22b16a7e-2466-7f8c-df1b-9c7862395022@oracle.com>

Yes - we should fix.

filed issue: https://bugs.openjdk.java.net/browse/JDK-8232723

/Andy

On 10/20/2019 9:49 AM, Nicolas Roduit wrote:
> Hi,
>
> Previously the WiX script could be overloaded in the resource 
> directory but not anymore. Is there a reason?
>
> It seems important to me to be able to modify the script for 
> real-world applications. For example, my needs are:
> - To build 32-bit package (changing 
> InstallScope="$(var.JpInstallScope)" Platform="x64"/>)
> - Package compression
> - Add an icon to the package
> - Register a custom URI scheme to launch the application in a web context
> - Adding a policy to chrome
> ...
>
> Here is a patch proposal:
>
>
> --- 
> a/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java 
> Sat Oct 19 09:50:19 2019 +0200
> +++ 
> b/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java 
> Sun Oct 20 12:10:26 2019 +0200
> @@ -425,10 +425,8 @@
> ???????????? }
> ???????? }
>
> -??????? try (InputStream is = 
> OverridableResource.readDefault("main.wxs")) {
> -??????????? Files.copy(is, Paths.get(
> - getConfig_ProjectFile(params).getAbsolutePath()));
> -??????? }
> +??????? Path wixScript = 
> Paths.get(getConfig_ProjectFile(params).getAbsolutePath());
> +??????? createResource("main.wxs", params).saveToFile(wixScript);
>
> ???????? return data;
> ???? }
>
>
> Kind Regards,
>
> Nicolas
>

From alexey.ivanov at oracle.com  Mon Oct 21 14:13:48 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 21 Oct 2019 15:13:48 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <e3c61b49-d923-07a1-a70c-ff080a10e4d9@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
 <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
 <e3c61b49-d923-07a1-a70c-ff080a10e4d9@oracle.com>
Message-ID: <c3c53fae-f214-f616-e109-8adef1fa3330@oracle.com>

I have filed
https://bugs.openjdk.java.net/browse/JDK-8232724
"Remove indirection with calling JNU_NewStringPlatform"

On 21/10/2019 13:49, Claes Redestad wrote:
> On 2019-10-21 14:14, Alexey Ivanov wrote:
>>
>> Probably, Claes thought "NewStringPlatform" wasn't used. Yet it 
>> proved that "NewStringPlatform" is still used.
>>
>> If required, I can create a follow-up issue to re-do the cleanup as 
>> Alan suggested.
>
> Yes, please. If some or even just one platform needs a special,
> undecorated alias for this type of internal dll_lookup to work, it seems
> prudent to add it back in a way that doesn't add it back (along with a
> possibly non-free indirection) to every other platform.
>
> /Claes
-- 
Regards,
Alexey

From alexey.ivanov at oracle.com  Mon Oct 21 14:22:09 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 21 Oct 2019 15:22:09 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <64e1bdf8-3f03-e6cc-a478-e52870e28464@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
 <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
 <64e1bdf8-3f03-e6cc-a478-e52870e28464@oracle.com>
Message-ID: <a6cf2b5a-9af1-e687-aa53-1713c736669a@oracle.com>

Hi David,

On 21/10/2019 14:00, David Holmes wrote:
>
> On 21/10/2019 10:14 pm, Alexey Ivanov wrote:
>> Hi David,
>>
>> On 21/10/2019 02:19, David Holmes wrote:
>>> <SNIP>
>>>
>>> So what would happen if we drop the JNICALL from JNU_NewStringPLatform?
>>
>> Yes, it will be found by its undecorated name too.
>> But I'd rather not change the calling conventions of functions with 
>> JNU_ prefix.
>
> Yes you are right. All the JNU_ methods are declared as JNICALL and 
> they all work fine.
>
> The issue/problem here is that we have the JVM using os::dll_lookup to 
> find a method back in libjava and that can't be a JNICALL else the 
> lookup won't work (without jumping through extra hoops).
>
>> So, I think the proposed patch is the easiest and safest way to fix 
>> 32-bit Windows build.
>
> Yes I now agree. Thanks for bearing with me.
>
>>>> Another way to fix it is to lookup the undecorated name first and, 
>>>> if it fails, to lookup the decorated name, which makes the code 
>>>> harder to read.
>>>>
>>>> With this patch, I'm reverting the code to the state it was before.
>>>
>>> Yes, but Claes didn't like the way it was before :) so I'm hoping we 
>>> can keep his cleanup whilst still allowing Windows to work correctly.
>>
>> Probably, Claes thought "NewStringPlatform" wasn't used. Yet it 
>> proved that "NewStringPlatform" is still used.
>>
>> If required, I can create a follow-up issue to re-do the cleanup as 
>> Alan suggested.
>
> Okay. Though I'm not sure what form that might take.

I have submitted
https://bugs.openjdk.java.net/browse/JDK-8232724

I see no other way but to try both the decorated and
undecorated names like it was done for
https://bugs.openjdk.java.net/browse/JDK-8214122
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057396.html

> Thanks,
> David
-- 
Regards,
Alexey

From claes.redestad at oracle.com  Mon Oct 21 14:55:43 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 21 Oct 2019 16:55:43 +0200
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
Message-ID: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>

Hi,

  Object.java currently registers various native functions via the
registerNatives facility.

     private static native void registerNatives();
     static {
         registerNatives();
     }

Not costly in and off itself, but this has the side effect that these
two methods are taken into account every time the VM has to generate
default methods and overpasses for some class during class load, which
can take up substantial time. When prototyping JDK-8219713[1],
explicitly excluding these two methods showed some improvement to
default method generation, but adding special cases to the logic was
decided against.

If we instead can get rid of the Object <clinit> and the registerNatives
altogether we get the same (or a slightly better) speedup. This
effectively reduces memory use and instructions retired doing default
method generation by 3-5%.

Webrev: http://cr.openjdk.java.net/~redestad/8232613/open.00/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8232613

Testing:
- tier1-7
- Added a test which naively redefines Object and ensures native methods
keep working

Thanks!

/Claes

From huizhe.wang at oracle.com  Mon Oct 21 16:27:59 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 21 Oct 2019 09:27:59 -0700
Subject: RFR(XS): 8232713: Update BCEL version to 6.3.1 in license file
In-Reply-To: <33c8fc27-afa8-2be0-9520-f13d38365863@oracle.com>
References: <33c8fc27-afa8-2be0-9520-f13d38365863@oracle.com>
Message-ID: <52152a0f-e4d4-c8d8-e659-1688af4828be@oracle.com>

+1. Thanks Aleksei!

-Joe

On 10/21/19 6:09 AM, Aleks Efimov wrote:
> Hi,
>
> The BCEL version has been updated to 6.3.1 by JDK-8224157 [1]. The 
> BCEL license file needs to be updated to include the correct version.
>
> Webrev: http://cr.openjdk.java.net/~aefimov/8232713/00
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8232713
>
>
> With Best Regards,
> Aleksei
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8224157


From mandy.chung at oracle.com  Mon Oct 21 17:10:07 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 21 Oct 2019 10:10:07 -0700
Subject: Review Request JDK-8232617: Update the outdated code comments in
 java.lang.System class
In-Reply-To: <2edc94ef-7cf6-4705-c129-b1c38bd6cdd2@oracle.com>
References: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>
 <9b6fc41e-ebea-17ef-15b6-fc5b5d3c5d3e@oracle.com>
 <4ac452cd-08b3-01be-7e11-43fe9127aae8@oracle.com>
 <2edc94ef-7cf6-4705-c129-b1c38bd6cdd2@oracle.com>
Message-ID: <39a87002-7128-1f43-3f6c-91bbad9c6ef0@oracle.com>

On 10/20/19 3:50 PM, David Holmes wrote:
> On 19/10/2019 10:38 am, Mandy Chung wrote:
>> thanks. I think "separated from" reads right to me.? I will leave it 
>> as is.
>
> I think "separately" or "separate" seems more correct here. And if 
> we're picking on grammar then it should be "The VM ..." and "of this 
> class" rather than "for this class".
>
Thanks.?? Updated:

    ?/* Register the natives via the static initializer.
      *
      * The VM will invoke the initPhase1 method to complete the initialization
      * of this class separate from <clinit>.
      */


Mandy


> Cheers,
> David
>
>> Mandy
>>
>> On 10/18/19 2:46 PM, Brent Christian wrote:
>>> Looks fine.? You might consider s/separated/separately/ .
>>>
>>> -Brent
>>>
>>> On 10/18/19 1:56 PM, Mandy Chung wrote:
>>>> A trivial doc fix:
>>>>
>>>>
>>>> diff --git a/src/java.base/share/classes/java/lang/System.java 
>>>> b/src/java.base/share/classes/java/lang/System.java
>>>> --- a/src/java.base/share/classes/java/lang/System.java
>>>> +++ b/src/java.base/share/classes/java/lang/System.java
>>>> @@ -94,10 +94,8 @@
>>>> ??public final class System {
>>>> ????? /* Register the natives via the static initializer.
>>>> ?????? *
>>>> -???? * VM will invoke the initializeSystemClass method to complete
>>>> -???? * the initialization for this class separated from clinit.
>>>> -???? * Note that to use properties set by the VM, see the constraints
>>>> -???? * described in the initializeSystemClass method.
>>>> +???? * VM will invoke the initPhase1 method to complete the 
>>>> initialization
>>>> +???? * for this class separated from <clinit>.
>>>> ?????? */
>>>> ????? private static native void registerNatives();
>>>> ????? static {
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Mandy
>>>>
>>


From alexey.ivanov at oracle.com  Mon Oct 21 17:58:39 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 21 Oct 2019 18:58:39 +0100
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <a6cf2b5a-9af1-e687-aa53-1713c736669a@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
 <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
 <64e1bdf8-3f03-e6cc-a478-e52870e28464@oracle.com>
 <a6cf2b5a-9af1-e687-aa53-1713c736669a@oracle.com>
Message-ID: <cae8f591-bd66-d5e8-2bd8-fa9adc985787@oracle.com>

Hi David, Claes, Alan,

Thank you for your reviews!

Just to confirm: Is the patch
http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
approved?

The cleanup to avoid indirection for calling JNU_NewStringPLatform will 
be addressed in the follow-up issue
https://bugs.openjdk.java.net/browse/JDK-8232724

-- 
Regards,
Alexey

From claes.redestad at oracle.com  Mon Oct 21 18:03:40 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 21 Oct 2019 20:03:40 +0200
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <cae8f591-bd66-d5e8-2bd8-fa9adc985787@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
 <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
 <64e1bdf8-3f03-e6cc-a478-e52870e28464@oracle.com>
 <a6cf2b5a-9af1-e687-aa53-1713c736669a@oracle.com>
 <cae8f591-bd66-d5e8-2bd8-fa9adc985787@oracle.com>
Message-ID: <a6d8869d-ad7d-f7ed-adad-6fcbd16b4d90@oracle.com>



On 2019-10-21 19:58, Alexey Ivanov wrote:
> 
> 
> Just to confirm: Is the patch
> http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
> approved?

Ship it!

/Claes

From vicente.romero at oracle.com  Mon Oct 21 18:32:01 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 21 Oct 2019 14:32:01 -0400
Subject: RFR: JEP 359-Records: serialization code and API changes
Message-ID: <c34e1d05-c1cb-4cd3-5bc0-5760c6199ddd@oracle.com>

Hi all,

Please review the serialization changes to support records.

Thanks,
Vicente

http://cr.openjdk.java.net/~vromero/records.review/serialization/webrev.00/

From brent.christian at oracle.com  Mon Oct 21 20:33:06 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 21 Oct 2019 13:33:06 -0700
Subject: Review Request JDK-8232617: Update the outdated code comments in
 java.lang.System class
In-Reply-To: <39a87002-7128-1f43-3f6c-91bbad9c6ef0@oracle.com>
References: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>
 <9b6fc41e-ebea-17ef-15b6-fc5b5d3c5d3e@oracle.com>
 <4ac452cd-08b3-01be-7e11-43fe9127aae8@oracle.com>
 <2edc94ef-7cf6-4705-c129-b1c38bd6cdd2@oracle.com>
 <39a87002-7128-1f43-3f6c-91bbad9c6ef0@oracle.com>
Message-ID: <4b204c80-d7d5-e995-fc40-395f0cc4b826@oracle.com>

Looks great. -B

On 10/21/19 10:10 AM, Mandy Chung wrote:
 >
> Thanks.?? Updated:
> 
>     ?/* Register the natives via the static initializer.
>       *
>       * The VM will invoke the initPhase1 method to complete the initialization
>       * of this class separate from <clinit>.
>       */
> 
>>>
>>> On 10/18/19 2:46 PM, Brent Christian wrote:
>>>> Looks fine.? You might consider s/separated/separately/ .
>>>>
>>>> -Brent
>>>>
>>>> On 10/18/19 1:56 PM, Mandy Chung wrote:
>>>>> A trivial doc fix:
>>>>>
>>>>>
>>>>> diff --git a/src/java.base/share/classes/java/lang/System.java 
>>>>> b/src/java.base/share/classes/java/lang/System.java
>>>>> --- a/src/java.base/share/classes/java/lang/System.java
>>>>> +++ b/src/java.base/share/classes/java/lang/System.java
>>>>> @@ -94,10 +94,8 @@
>>>>> ??public final class System {
>>>>> ????? /* Register the natives via the static initializer.
>>>>> ?????? *
>>>>> -???? * VM will invoke the initializeSystemClass method to complete
>>>>> -???? * the initialization for this class separated from clinit.
>>>>> -???? * Note that to use properties set by the VM, see the constraints
>>>>> -???? * described in the initializeSystemClass method.
>>>>> +???? * VM will invoke the initPhase1 method to complete the 
>>>>> initialization
>>>>> +???? * for this class separated from <clinit>.
>>>>> ?????? */
>>>>> ????? private static native void registerNatives();
>>>>> ????? static {
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Mandy
>>>>>
>>>
> 

From david.holmes at oracle.com  Mon Oct 21 22:52:05 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Oct 2019 08:52:05 +1000
Subject: Review Request JDK-8232617: Update the outdated code comments in
 java.lang.System class
In-Reply-To: <4b204c80-d7d5-e995-fc40-395f0cc4b826@oracle.com>
References: <36ee7629-bd49-238d-0cee-05e564e9f2c2@oracle.com>
 <9b6fc41e-ebea-17ef-15b6-fc5b5d3c5d3e@oracle.com>
 <4ac452cd-08b3-01be-7e11-43fe9127aae8@oracle.com>
 <2edc94ef-7cf6-4705-c129-b1c38bd6cdd2@oracle.com>
 <39a87002-7128-1f43-3f6c-91bbad9c6ef0@oracle.com>
 <4b204c80-d7d5-e995-fc40-395f0cc4b826@oracle.com>
Message-ID: <4745a986-88af-e58e-3ee2-1f4baf5c98ce@oracle.com>

+1

Thanks,
David

On 22/10/2019 6:33 am, Brent Christian wrote:
> Looks great. -B
> 
> On 10/21/19 10:10 AM, Mandy Chung wrote:
>  >
>> Thanks.?? Updated:
>>
>> ??? ?/* Register the natives via the static initializer.
>> ????? *
>> ????? * The VM will invoke the initPhase1 method to complete the 
>> initialization
>> ????? * of this class separate from <clinit>.
>> ????? */
>>
>>>>
>>>> On 10/18/19 2:46 PM, Brent Christian wrote:
>>>>> Looks fine.? You might consider s/separated/separately/ .
>>>>>
>>>>> -Brent
>>>>>
>>>>> On 10/18/19 1:56 PM, Mandy Chung wrote:
>>>>>> A trivial doc fix:
>>>>>>
>>>>>>
>>>>>> diff --git a/src/java.base/share/classes/java/lang/System.java 
>>>>>> b/src/java.base/share/classes/java/lang/System.java
>>>>>> --- a/src/java.base/share/classes/java/lang/System.java
>>>>>> +++ b/src/java.base/share/classes/java/lang/System.java
>>>>>> @@ -94,10 +94,8 @@
>>>>>> ??public final class System {
>>>>>> ????? /* Register the natives via the static initializer.
>>>>>> ?????? *
>>>>>> -???? * VM will invoke the initializeSystemClass method to complete
>>>>>> -???? * the initialization for this class separated from clinit.
>>>>>> -???? * Note that to use properties set by the VM, see the 
>>>>>> constraints
>>>>>> -???? * described in the initializeSystemClass method.
>>>>>> +???? * VM will invoke the initPhase1 method to complete the 
>>>>>> initialization
>>>>>> +???? * for this class separated from <clinit>.
>>>>>> ?????? */
>>>>>> ????? private static native void registerNatives();
>>>>>> ????? static {
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Mandy
>>>>>>
>>>>
>>

From david.holmes at oracle.com  Mon Oct 21 22:53:09 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Oct 2019 08:53:09 +1000
Subject: RFR JDK-8232624: Java cannot start: NewStringPlatform missing
In-Reply-To: <a6d8869d-ad7d-f7ed-adad-6fcbd16b4d90@oracle.com>
References: <55d3ffd7-f4aa-adf7-bcec-aead2bc0a743@oracle.com>
 <f8c9715a-ea25-4818-8b2a-7036dbea9ce0@oracle.com>
 <14194df6-cd93-8272-bea9-c8f2ee848bb1@oracle.com>
 <eeb83327-6d4d-30e5-6e46-e085529904a3@oracle.com>
 <7f3268f6-7d84-5fde-ec3f-d9248161cd76@oracle.com>
 <64e1bdf8-3f03-e6cc-a478-e52870e28464@oracle.com>
 <a6cf2b5a-9af1-e687-aa53-1713c736669a@oracle.com>
 <cae8f591-bd66-d5e8-2bd8-fa9adc985787@oracle.com>
 <a6d8869d-ad7d-f7ed-adad-6fcbd16b4d90@oracle.com>
Message-ID: <e3e598ad-c506-6b60-a0f9-53fc6a069225@oracle.com>

+1

On 22/10/2019 4:03 am, Claes Redestad wrote:
> 
> 
> On 2019-10-21 19:58, Alexey Ivanov wrote:
>>
>>
>> Just to confirm: Is the patch
>> http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
>> approved?
> 
> Ship it!
> 
> /Claes

From david.holmes at oracle.com  Mon Oct 21 23:08:30 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Oct 2019 09:08:30 +1000
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
Message-ID: <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>

Hi Claes,

My only nit with this is that I don't think register_native and friends 
belongs in the SystemDictionary class as it has nothing to do with the 
SD. This code seems to be all about Methods so that seems like the place 
to put this.

Thanks,
David

On 22/10/2019 12:55 am, Claes Redestad wrote:
> Hi,
> 
>  ?Object.java currently registers various native functions via the
> registerNatives facility.
> 
>  ??? private static native void registerNatives();
>  ??? static {
>  ??????? registerNatives();
>  ??? }
> 
> Not costly in and off itself, but this has the side effect that these
> two methods are taken into account every time the VM has to generate
> default methods and overpasses for some class during class load, which
> can take up substantial time. When prototyping JDK-8219713[1],
> explicitly excluding these two methods showed some improvement to
> default method generation, but adding special cases to the logic was
> decided against.
> 
> If we instead can get rid of the Object <clinit> and the registerNatives
> altogether we get the same (or a slightly better) speedup. This
> effectively reduces memory use and instructions retired doing default
> method generation by 3-5%.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8232613/open.00/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232613
> 
> Testing:
> - tier1-7
> - Added a test which naively redefines Object and ensures native methods
> keep working
> 
> Thanks!
> 
> /Claes

From mark.reinhold at oracle.com  Tue Oct 22 03:22:53 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 21 Oct 2019 20:22:53 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time
 options
Message-ID: <20191021202253.825695282@eggemoggin.niobe.net>

RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/

This change implements jlink plugins, and associated changes in the VM
and libraries, to support the following new jlink options:

  - --vendor-bug-url=<vendor-bug-url> overrides the vendor bug URL baked
    into the build.  The value of the system property "java.vendor.url.bug"
    will be <vendor-bug-url>.

  - --vendor-vm-bug-url=<vendor-vm-bug-url> overrides the vendor VM bug
    URL baked into the build.  This value will be displayed in VM error
    logs.

  - --vendor-version=<vendor-version> overrides the vendor version string
    baked into the build, if any.  The value of the system property
    "java.vendor.version" will be <vendor-version>.  This value will be
    displayed in the output of java --version.

  - --add-options=<options> prepends the specified <options> string,
    which may include whitespace, before any other options when invoking
    the VM in the resulting image.

The vendor-information plugins work by using the JDK?s internal ASM
library to redefine static fields in the java.lang.VersionProps class.
The VM reads the vendor-version and vendor-vm-bug-url strings from that
class during startup.

The add-options plugin works by storing the requested options in an
internal resource, /java.base/jdk/internal/vm/options.  The VM loads that
resource from the lib/modules jimage file during startup and prepends any
options found there to those given on the command line.

Passes tier1-3 and JCK on {linux,macos,windows}-x64.

Thanks,
- Mark

From adinn at redhat.com  Tue Oct 22 08:11:19 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 22 Oct 2019 09:11:19 +0100
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
Message-ID: <e87add51-14f7-eb6d-207b-a0551ae54d6c@redhat.com>

Hi Claes/David,

On 22/10/2019 00:08, David Holmes wrote:
> My only nit with this is that I don't think register_native and friends
> belongs in the SystemDictionary class as it has nothing to do with the
> SD. This code seems to be all about Methods so that seems like the place
> to put this.
Claes, the patch looks good.

David, I'm not clear why you think this is about methods. The calls to
register_native occur under

  SystemDictionary::resolve_well_known_classes

which indicates to me that this code is very much about Classes/klasses
-- specifically initializing class Object during early bootstrap. The
fact that it is /methods/ of Object that are being fixed up doesn't
really change that for me.

So, I would have thought it would be clearer for the code that does this
specific bit of 'well known class init' to be located with the other
'well known class init' code.

regards,


Andrew Dinn
-----------


From david.holmes at oracle.com  Tue Oct 22 08:58:01 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Oct 2019 18:58:01 +1000
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <e87add51-14f7-eb6d-207b-a0551ae54d6c@redhat.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <e87add51-14f7-eb6d-207b-a0551ae54d6c@redhat.com>
Message-ID: <654257b1-29f3-8b1c-63e5-d5075542144d@oracle.com>

Hi Andrew,

On 22/10/2019 6:11 pm, Andrew Dinn wrote:
> Hi Claes/David,
> 
> On 22/10/2019 00:08, David Holmes wrote:
>> My only nit with this is that I don't think register_native and friends
>> belongs in the SystemDictionary class as it has nothing to do with the
>> SD. This code seems to be all about Methods so that seems like the place
>> to put this.
> Claes, the patch looks good.
> 
> David, I'm not clear why you think this is about methods. The calls to
> register_native occur under
> 
>    SystemDictionary::resolve_well_known_classes
> 
> which indicates to me that this code is very much about Classes/klasses
> -- specifically initializing class Object during early bootstrap. The
> fact that it is /methods/ of Object that are being fixed up doesn't
> really change that for me.

Ultimately "registering" a native method is doing:

method->set_native_function(entry, 
Method::native_bind_event_is_interesting);

that's the crux of it. Seems pretty specifically about Methods to me.

> So, I would have thought it would be clearer for the code that does this
> specific bit of 'well known class init' to be located with the other
> 'well known class init' code.

I don't see how the call site dictates where the called code should be 
located ???

Regards,
David
-----

> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From magnus.ihse.bursie at oracle.com  Tue Oct 22 09:37:35 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 Oct 2019 11:37:35 +0200
Subject: RFR: JDK-8226585: Improve javac messages for using a preview API
In-Reply-To: <fc25e5d5-9584-2276-7f2f-5385448577fa@oracle.com>
References: <aef66e9e-f2e6-9ea1-be16-8c1258535a9f@oracle.com>
 <e231f88e-744c-0f1d-6338-3c933bbd2d53@oracle.com>
 <85fa1e39-4966-c30a-b609-970caaaa6a4d@oracle.com>
 <5984363A-8615-42DC-AA11-B3017D2D2372@oracle.com>
 <d007ba61-95e9-a89c-a13e-741a56f4f93a@oracle.com>
 <875ebdb1-c37b-079c-0416-3a80351c87bb@oracle.com>
 <fc25e5d5-9584-2276-7f2f-5385448577fa@oracle.com>
Message-ID: <b1b2b8cf-c186-707c-55d9-0f5ffa584141@oracle.com>

On 2019-10-16 14:55, Erik Joelsson wrote:
> Build change looks good now.
I agree.

/Magnus
>
> /Erik
>
> On 2019-10-16 05:50, Jan Lahoda wrote:
>> Hi,
>>
>> An updated patch is here:
>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.02/
>>
>> Changes in the update:
>> -added the dependency into the makefiles
>> -loosened the handling of essential preview APIs when 
>> --enable-preview and @SuppressWarnings is applied - there is no 
>> warning for the essential APIs (as there is no warning in such a case 
>> for non-essential APIs). This is per the discussion in the CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>
>> Any comments/feedback on this?
>>
>> Thanks!
>> ??? Jan
>>
>> On 09. 10. 19 17:41, Erik Joelsson wrote:
>>> Oh, you are absolutely correct, the dependency is missing.
>>>
>>> We need something like this inside "define SetupInterimModule":
>>>
>>> $$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
>>>
>>> /Erik
>>>
>>> On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
>>>> I can?t see how the compilation is dependent on the copy being 
>>>> finished. Since Erik contributed this it will probably be correct 
>>>> :) but I?d appreciate an explanation on how this dependency is 
>>>> guaranteed.
>>>>
>>>> Or maybe I?m misunderstanding what this is supposed to do?
>>>>
>>>> /Magnus
>>>>
>>>>> 8 okt. 2019 kl. 17:27 skrev Jan Lahoda <jan.lahoda at oracle.com>:
>>>>>
>>>>> Thanks for the new code Erik!
>>>>>
>>>>> A new webrev/patch that includes this better way of copying is here:
>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
>>>>>
>>>>> Any feedback is welcome!
>>>>>
>>>>> Thanks,
>>>>> ??? Jan
>>>>>
>>>>>> On 03. 10. 19 18:06, Erik Joelsson wrote:
>>>>>> Hello Jan,
>>>>>> The build change looks ok, but I would recommend this construct 
>>>>>> for copying the file instead:
>>>>>> $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
>>>>>> ???? FILES := 
>>>>>> $(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, 
>>>>>> \
>>>>>> ???? DEST := 
>>>>>> $(BUILDTOOLS_OUTPUTDIR)/gensrc/java.base.interim/jdk/internal/PreviewFeature.java, 
>>>>>> \
>>>>>> ))
>>>>>> TARGETS += $(COPY_PREVIEW_FEATURES)
>>>>>> Then you automatically get all the corner case handling we have 
>>>>>> implemented over the years for logging, making directories and 
>>>>>> copying files. Your version is still correct for this case though.
>>>>>> /Erik
>>>>>>> On 2019-10-03 02:57, Jan Lahoda wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is a continuation of Joe's patch from here:
>>>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html 
>>>>>>>
>>>>>>>
>>>>>>> APIs associated with preview features are split into two groups: 
>>>>>>> essential and non-essential. These are marked with an 
>>>>>>> JDK-internal annotation, PreviewFeature, and a tag in the 
>>>>>>> javadoc, @preview. The javac follows the PreviewFeature 
>>>>>>> annotation, and produces either warnings or errors for the 
>>>>>>> usages of such APIs. For the @preview tag, there is a taglet in 
>>>>>>> the JDK build that adds the content of the tag into the 
>>>>>>> documentation. The first part of the @preview's text goes into 
>>>>>>> the summary, the second part goes into the detailed description.
>>>>>>>
>>>>>>> For build, a tricky problem is that the jdk.compiler module uses 
>>>>>>> the PreviewFeature annotation as well, but that is not in the 
>>>>>>> bootstrap JDK. So, for the intermediate langtools build, the 
>>>>>>> PreviewFeature annotation is copied from java.base.
>>>>>>>
>>>>>>> Proposed webrev:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/webrev.00/
>>>>>>>
>>>>>>> Javadoc with the change:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/index.html
>>>>>>>
>>>>>>> See for example:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/java.base/java/lang/String.html 
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8226585/docs.00/api/jdk.compiler/com/sun/source/tree/CaseTree.html 
>>>>>>>
>>>>>>>
>>>>>>> JBS:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226585
>>>>>>>
>>>>>>> CSR:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231411
>>>>>>>
>>>>>>> Feedback is welcome!
>>>>>>>
>>>>>>> Thanks,
>>>>>>> ???? Jan


From magnus.ihse.bursie at oracle.com  Tue Oct 22 09:45:41 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 Oct 2019 11:45:41 +0200
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
Message-ID: <b3b88187-63ae-748f-0727-e04c12510db7@oracle.com>

On 2019-10-22 05:22, mark.reinhold at oracle.com wrote:
> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
Build changes look good.

/Magnus
>
> This change implements jlink plugins, and associated changes in the VM
> and libraries, to support the following new jlink options:
>
>    - --vendor-bug-url=<vendor-bug-url> overrides the vendor bug URL baked
>      into the build.  The value of the system property "java.vendor.url.bug"
>      will be <vendor-bug-url>.
>
>    - --vendor-vm-bug-url=<vendor-vm-bug-url> overrides the vendor VM bug
>      URL baked into the build.  This value will be displayed in VM error
>      logs.
>
>    - --vendor-version=<vendor-version> overrides the vendor version string
>      baked into the build, if any.  The value of the system property
>      "java.vendor.version" will be <vendor-version>.  This value will be
>      displayed in the output of java --version.
>
>    - --add-options=<options> prepends the specified <options> string,
>      which may include whitespace, before any other options when invoking
>      the VM in the resulting image.
>
> The vendor-information plugins work by using the JDK?s internal ASM
> library to redefine static fields in the java.lang.VersionProps class.
> The VM reads the vendor-version and vendor-vm-bug-url strings from that
> class during startup.
>
> The add-options plugin works by storing the requested options in an
> internal resource, /java.base/jdk/internal/vm/options.  The VM loads that
> resource from the lib/modules jimage file during startup and prepends any
> options found there to those given on the command line.
>
> Passes tier1-3 and JCK on {linux,macos,windows}-x64.
>
> Thanks,
> - Mark


From claes.redestad at oracle.com  Tue Oct 22 10:38:57 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 22 Oct 2019 12:38:57 +0200
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
Message-ID: <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>

Hi David,

On 2019-10-22 01:08, David Holmes wrote:
> Hi Claes,
> 
> My only nit with this is that I don't think register_native and friends 
> belongs in the SystemDictionary class as it has nothing to do with the 
> SD. This code seems to be all about Methods so that seems like the place 
> to put this.

how about this:

http://cr.openjdk.java.net/~redestad/8232613/open.01/

/Claes

From adam.farley at uk.ibm.com  Tue Oct 22 10:40:35 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 22 Oct 2019 11:40:35 +0100
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
Message-ID: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>

Hey All,

This one goes out to anyone who's struggled to figure out 
why OpenJDK isn't loading their class.

The requirement is for OpenJDK to give more detailed 
information while loading user-specified classes (e.g. the 
one OpenJDK is failing to load). Some debug information is 
available while the loading is in-progress, and more is 
available after the fact, but it seems there is not a way 
to monitor what the ClassLoaders are actually doing without
the use of debugging tools.

For your approval: a formal write-up of the problem (as 
I understand it), and a draft webrev containing the 
proposed solution.

Tests will be developed and added if/when the issue is 
accepted as a problem, and a solution has been selected.

Please review and opine.

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

Webrev: http://cr.openjdk.java.net/~afarley/8232773/webrev/ 

Thanks for your time. :)

Best Regards

Adam Farley 
IBM Runtimes


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From adinn at redhat.com  Tue Oct 22 10:44:54 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 22 Oct 2019 11:44:54 +0100
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
Message-ID: <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>

On 22/10/2019 11:38, Claes Redestad wrote:
> how about this:
> 
> http://cr.openjdk.java.net/~redestad/8232613/open.01/
Sure that works.

It's a bit more obvious now though that you are pointlessly returning a
boolean from Method::register_native (this was also there in the
previous version).

Why not leave it void?

regards,


Andrew Dinn
-----------


From claes.redestad at oracle.com  Tue Oct 22 11:05:41 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 22 Oct 2019 13:05:41 +0200
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
Message-ID: <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>



On 2019-10-22 12:44, Andrew Dinn wrote:
> On 22/10/2019 11:38, Claes Redestad wrote:
>> how about this:
>>
>> http://cr.openjdk.java.net/~redestad/8232613/open.01/
> Sure that works.
> 
> It's a bit more obvious now though that you are pointlessly returning a
> boolean from Method::register_native (this was also there in the
> previous version).

It was also there in the code that I moved. :-)

> 
> Why not leave it void?

I guess:

http://cr.openjdk.java.net/~redestad/8232613/open.02/

/Claes

From adinn at redhat.com  Tue Oct 22 11:05:41 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 22 Oct 2019 12:05:41 +0100
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
Message-ID: <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>

On 22/10/2019 12:05, Claes Redestad wrote:
> On 2019-10-22 12:44, Andrew Dinn wrote:
>> Why not leave it void?
> 
> I guess:
> 
> http://cr.openjdk.java.net/~redestad/8232613/open.02/
Ship it ;-)

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From claes.redestad at oracle.com  Tue Oct 22 11:13:06 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 22 Oct 2019 13:13:06 +0200
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
Message-ID: <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>



On 2019-10-22 13:05, Andrew Dinn wrote:
> On 22/10/2019 12:05, Claes Redestad wrote:
>> On 2019-10-22 12:44, Andrew Dinn wrote:
>>> Why not leave it void?
>>
>> I guess:
>>
>> http://cr.openjdk.java.net/~redestad/8232613/open.02/
> Ship it ;-)

No wait, I missed the use in jni.cpp where the bool return is actually
used. I ignored it in systemDict since when I got an exception there
(by misspelling a name or using the wrong signature) the exception
bubbles up and crashes the VM.

Perhaps this could be reworked to remove the bool cleanly, but let's go 
back to open.01 and move that cleanup to a follow-up.

/Claes




From Alan.Bateman at oracle.com  Tue Oct 22 11:36:26 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Oct 2019 12:36:26 +0100
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
Message-ID: <5152be78-bf16-3473-1c52-fd5adf211944@oracle.com>

On 22/10/2019 11:40, Adam Farley8 wrote:
> Hey All,
>
> This one goes out to anyone who's struggled to figure out
> why OpenJDK isn't loading their class.
>
> The requirement is for OpenJDK to give more detailed
> information while loading user-specified classes (e.g. the
> one OpenJDK is failing to load). Some debug information is
> available while the loading is in-progress, and more is
> available after the fact, but it seems there is not a way
> to monitor what the ClassLoaders are actually doing without
> the use of debugging tools.
>
> For your approval: a formal write-up of the problem (as
> I understand it), and a draft webrev containing the
> proposed solution.
>
> Tests will be developed and added if/when the issue is
> accepted as a problem, and a solution has been selected.
>
> Please review and opine.
This looks very messy and I don't think is in any state to be reviewed. 
When changing existing code it is important to respect the existing 
coding conventions and keep the style as consistent as possible. Also we 
should avoid adding new code in 2019 that uses Vector, StringTokenizer 
and other legacy classes.

That said, I think we do need to improve the serviceability and 
diagnosability in the java.base module. This will become more important 
as more of the runtime is developed in the libraries rather than in 
libjvm. We have ad hoc logging in several areas, and one or two places 
that emit JFR events, but don't have a consistent approach. Stuart Marks 
lead a discussion on this at the OpenJDK workshop in August but it 
didn't get any far. Maybe your needs may help that discussion to get 
going again.

For the issue at hand, maybe you could start by describing some of the 
needs in the class loader areas. Is it mostly visibility issues? I see 
the issue you created in JBS mentions "wrong version of a class" which 
suggests you are interested in linkage errors too.

-Alan

From lois.foltan at oracle.com  Tue Oct 22 12:33:01 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 22 Oct 2019 08:33:01 -0400
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
Message-ID: <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>

On 10/22/2019 7:13 AM, Claes Redestad wrote:
>
>
> On 2019-10-22 13:05, Andrew Dinn wrote:
>> On 22/10/2019 12:05, Claes Redestad wrote:
>>> On 2019-10-22 12:44, Andrew Dinn wrote:
>>>> Why not leave it void?
>>>
>>> I guess:
>>>
>>> http://cr.openjdk.java.net/~redestad/8232613/open.02/
>> Ship it ;-)
>
> No wait, I missed the use in jni.cpp where the bool return is actually
> used. I ignored it in systemDict since when I got an exception there
> (by misspelling a name or using the wrong signature) the exception
> bubbles up and crashes the VM.
>
> Perhaps this could be reworked to remove the bool cleanly, but let's 
> go back to open.01 and move that cleanup to a follow-up.
>
> /Claes
>
Hi Claes,

I do have a concern that this will be a behavioral change for method 
resolution if Object::registerNatives is removed.? For example,

public class RegisterNatives {
 ? interface I { default public void registerNatives() { 
System.out.println("I"); } }
 ? static class A implements I { }
 ? public static void main(String... args) {
 ??? A varA = new A();
 ??? varA.registerNatives();
 ? }

Currently class A finds registerNatives in its superclass Object and the 
test receives the following:

    Exception in thread "main" java.lang.IllegalAccessError: class
    RegisterNatives tried to access private method 'void
    java.lang.Object.registerNatives()' (RegisterNatives is in unnamed
    module of loader 'app'; java.lang.Object is in module java.base of
    loader 'bootstrap')
     ??????? at RegisterNatives.main(RegisterNatives.java:6)

With your change interface I's registerNatives default method is invoked 
successfully.? I don't think this is a major backward compatibilty issue 
but we should have someone from core-libs okay the removal of the method 
from Object before committing.? In addition, can you add this test as 
part of your change?? I think it would be okay to put it in 
open/test/hotspot/jtreg/runtime/8024804 which contains an existing 
registerNatives test.

Otherwise I think .01 from the Hotspot side looks good.? Only one minor 
comment:
method.cpp
- line #426 and 427:? Since you are in this code can your change to 
resourceMark(THREAD)?

Thanks,
Lois





From chris.hegarty at oracle.com  Tue Oct 22 12:48:01 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 22 Oct 2019 13:48:01 +0100
Subject: RFR: JEP 359-Records: serialization code and API changes
In-Reply-To: <c34e1d05-c1cb-4cd3-5bc0-5760c6199ddd@oracle.com>
References: <c34e1d05-c1cb-4cd3-5bc0-5760c6199ddd@oracle.com>
Message-ID: <AF25DE15-8C29-4775-B4C1-F732129FA17F@oracle.com>


> On 21 Oct 2019, at 19:32, Vicente Romero <vicente.romero at oracle.com> wrote:
> 
> Hi all,
> 
> Please review the serialization changes to support records.
> 
> Thanks,
> Vicente
> 
> http://cr.openjdk.java.net/~vromero/records.review/serialization/webrev.00/

Peter has raised an issue over on amber-spec-experts [1], which has been addressed in the records branch.

-Chris.

[1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-October/001731.html <https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-October/001731.html>


From adinn at redhat.com  Tue Oct 22 13:03:55 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 22 Oct 2019 14:03:55 +0100
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
Message-ID: <47c9118d-1e03-7329-09b2-6dc0b233f52a@redhat.com>

On 22/10/2019 12:13, Claes Redestad wrote:
> No wait, I missed the use in jni.cpp where the bool return is actually
> used. I ignored it in systemDict since when I got an exception there
> (by misspelling a name or using the wrong signature) the exception
> bubbles up and crashes the VM.
> 
> Perhaps this could be reworked to remove the bool cleanly, but let's go
> back to open.01 and move that cleanup to a follow-up.
Sure, no problem.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From david.holmes at oracle.com  Tue Oct 22 13:08:48 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Oct 2019 23:08:48 +1000
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
Message-ID: <a0f069d7-5d63-882a-0ba3-0be5e95e7b4d@oracle.com>

Hi Claes,

On 22/10/2019 8:38 pm, Claes Redestad wrote:
> Hi David,
> 
> On 2019-10-22 01:08, David Holmes wrote:
>> Hi Claes,
>>
>> My only nit with this is that I don't think register_native and 
>> friends belongs in the SystemDictionary class as it has nothing to do 
>> with the SD. This code seems to be all about Methods so that seems 
>> like the place to put this.
> 
> how about this:
> 
> http://cr.openjdk.java.net/~redestad/8232613/open.01/

Much better thanks :) But now I see how jarring the change to the SD 
code is. I don't think this logic really belongs in 
SystemDictionary::resolve_well_known_classes. This is a form of 
pre-initialization ... is it better suited for 
Threads::initialize_java_lang_classes perhaps?

I won't insist on this further change, but may take another look at this 
later.

Thanks,
David


> /Claes

From david.holmes at oracle.com  Tue Oct 22 13:12:55 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Oct 2019 23:12:55 +1000
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
Message-ID: <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>

Hi Adam,

Did you look at the logging available from the VM: -Xlog:class+load?

BTW I moved the bug you filed to the correct component.

Cheers,
David

On 22/10/2019 8:40 pm, Adam Farley8 wrote:
> Hey All,
> 
> This one goes out to anyone who's struggled to figure out
> why OpenJDK isn't loading their class.
> 
> The requirement is for OpenJDK to give more detailed
> information while loading user-specified classes (e.g. the
> one OpenJDK is failing to load). Some debug information is
> available while the loading is in-progress, and more is
> available after the fact, but it seems there is not a way
> to monitor what the ClassLoaders are actually doing without
> the use of debugging tools.
> 
> For your approval: a formal write-up of the problem (as
> I understand it), and a draft webrev containing the
> proposed solution.
> 
> Tests will be developed and added if/when the issue is
> accepted as a problem, and a solution has been selected.
> 
> Please review and opine.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232773
> 
> Webrev: http://cr.openjdk.java.net/~afarley/8232773/webrev/
> 
> Thanks for your time. :)
> 
> Best Regards
> 
> Adam Farley
> IBM Runtimes
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 

From claes.redestad at oracle.com  Tue Oct 22 13:41:04 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 22 Oct 2019 15:41:04 +0200
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
 <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
Message-ID: <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>

Hi Lois,

to make sure noone misses it, here's the new webrev:
http://cr.openjdk.java.net/~redestad/8232613/open.03

Comments inline..

On 2019-10-22 14:33, Lois Foltan wrote:
> On 10/22/2019 7:13 AM, Claes Redestad wrote:
>>
>>
>> On 2019-10-22 13:05, Andrew Dinn wrote:
>>> On 22/10/2019 12:05, Claes Redestad wrote:
>>>> On 2019-10-22 12:44, Andrew Dinn wrote:
>>>>> Why not leave it void?
>>>>
>>>> I guess:
>>>>
>>>> http://cr.openjdk.java.net/~redestad/8232613/open.02/
>>> Ship it ;-)
>>
>> No wait, I missed the use in jni.cpp where the bool return is actually
>> used. I ignored it in systemDict since when I got an exception there
>> (by misspelling a name or using the wrong signature) the exception
>> bubbles up and crashes the VM.
>>
>> Perhaps this could be reworked to remove the bool cleanly, but let's 
>> go back to open.01 and move that cleanup to a follow-up.
>>
>> /Claes
>>
> Hi Claes,
> 
> I do have a concern that this will be a behavioral change for method 
> resolution if Object::registerNatives is removed.? For example,
> 
> public class RegisterNatives {
>  ? interface I { default public void registerNatives() { 
> System.out.println("I"); } }
>  ? static class A implements I { }
>  ? public static void main(String... args) {
>  ??? A varA = new A();
>  ??? varA.registerNatives();
>  ? }
> 
> Currently class A finds registerNatives in its superclass Object and the 
> test receives the following:
> 
>     Exception in thread "main" java.lang.IllegalAccessError: class
>     RegisterNatives tried to access private method 'void
>     java.lang.Object.registerNatives()' (RegisterNatives is in unnamed
>     module of loader 'app'; java.lang.Object is in module java.base of
>     loader 'bootstrap')
>      ??????? at RegisterNatives.main(RegisterNatives.java:6)
> 
> With your change interface I's registerNatives default method is invoked 
> successfully.? I don't think this is a major backward compatibilty issue 
> but we should have someone from core-libs okay the removal of the method 
> from Object before committing.? In addition, can you add this test as 
> part of your change?? I think it would be okay to put it in 
> open/test/hotspot/jtreg/runtime/8024804 which contains an existing 
> registerNatives test.

Yeah, *not* throwing an IAE on this feels like an unintentional bug fix.
:-)

We're relaxing a very subtle interaction, so I think compatibility
issues with existing code is non-existing. What could be an issue is
that someone might implement this pattern and then see it no longer
working on older versions of the OpenJDK.

However, that's already a possible scenario since the sample already
runs fine on some other non-OpenJDK JCK-compliant java implementations.
Thus I think this compatibility observation just adds an argument _in
favor_ of this RFE.

I've updated the test you pointed me to to include your test scenario.

Thanks!

/Claes

> 
> Otherwise I think .01 from the Hotspot side looks good.? Only one minor 
> comment:
> method.cpp
> - line #426 and 427:? Since you are in this code can your change to 
> resourceMark(THREAD)?
> 
> Thanks,
> Lois
> 
> 
> 
> 

From david.holmes at oracle.com  Tue Oct 22 13:55:59 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Oct 2019 23:55:59 +1000
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
 <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
 <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>
Message-ID: <2dbde280-086a-4eae-9f8a-8c2652c30ce0@oracle.com>

On 22/10/2019 11:41 pm, Claes Redestad wrote:
> Hi Lois,
> 
> to make sure noone misses it, here's the new webrev:
> http://cr.openjdk.java.net/~redestad/8232613/open.03

I like the code placement in this version - Coleen's suggestion was 
better than mine :)

> Comments inline..

Comments inline ...

> On 2019-10-22 14:33, Lois Foltan wrote:
>> On 10/22/2019 7:13 AM, Claes Redestad wrote:
>>>
>>>
>>> On 2019-10-22 13:05, Andrew Dinn wrote:
>>>> On 22/10/2019 12:05, Claes Redestad wrote:
>>>>> On 2019-10-22 12:44, Andrew Dinn wrote:
>>>>>> Why not leave it void?
>>>>>
>>>>> I guess:
>>>>>
>>>>> http://cr.openjdk.java.net/~redestad/8232613/open.02/
>>>> Ship it ;-)
>>>
>>> No wait, I missed the use in jni.cpp where the bool return is actually
>>> used. I ignored it in systemDict since when I got an exception there
>>> (by misspelling a name or using the wrong signature) the exception
>>> bubbles up and crashes the VM.
>>>
>>> Perhaps this could be reworked to remove the bool cleanly, but let's 
>>> go back to open.01 and move that cleanup to a follow-up.
>>>
>>> /Claes
>>>
>> Hi Claes,
>>
>> I do have a concern that this will be a behavioral change for method 
>> resolution if Object::registerNatives is removed.? For example,

Good catch Lois!

>>
>> public class RegisterNatives {
>> ?? interface I { default public void registerNatives() { 
>> System.out.println("I"); } }
>> ?? static class A implements I { }
>> ?? public static void main(String... args) {
>> ???? A varA = new A();
>> ???? varA.registerNatives();
>> ?? }
>>
>> Currently class A finds registerNatives in its superclass Object and 
>> the test receives the following:
>>
>> ??? Exception in thread "main" java.lang.IllegalAccessError: class
>> ??? RegisterNatives tried to access private method 'void
>> ??? java.lang.Object.registerNatives()' (RegisterNatives is in unnamed
>> ??? module of loader 'app'; java.lang.Object is in module java.base of
>> ??? loader 'bootstrap')
>> ???? ??????? at RegisterNatives.main(RegisterNatives.java:6)
>>
>> With your change interface I's registerNatives default method is 
>> invoked successfully.? I don't think this is a major backward 
>> compatibilty issue but we should have someone from core-libs okay the 
>> removal of the method from Object before committing.? In addition, can 
>> you add this test as part of your change?? I think it would be okay to 
>> put it in open/test/hotspot/jtreg/runtime/8024804 which contains an 
>> existing registerNatives test.
> 
> Yeah, *not* throwing an IAE on this feels like an unintentional bug fix.
> :-)

Yes it is a somewhat surprising aspect of default method resolution, but 
methods in the class hierarchy must be considered ahead of any default 
method - even inaccessible ones.

> We're relaxing a very subtle interaction, so I think compatibility
> issues with existing code is non-existing. 

I don't think there is a compatibility issue here because we don't in 
general have to maintain error compatibility. However as it is a change 
in behaviour it does warrant a CSR request just so the compatibility 
argument is captured/recorded.

> What could be an issue is
> that someone might implement this pattern and then see it no longer
> working on older versions of the OpenJDK.

Unfortunate, but not a compatibility scenario we have to support.

Cheers,
David
-----

> However, that's already a possible scenario since the sample already
> runs fine on some other non-OpenJDK JCK-compliant java implementations.
> Thus I think this compatibility observation just adds an argument _in
> favor_ of this RFE.
> 
> I've updated the test you pointed me to to include your test scenario.
> 
> Thanks!
> 
> /Claes
> 
>>
>> Otherwise I think .01 from the Hotspot side looks good.? Only one 
>> minor comment:
>> method.cpp
>> - line #426 and 427:? Since you are in this code can your change to 
>> resourceMark(THREAD)?
>>
>> Thanks,
>> Lois
>>
>>
>>
>>

From Alan.Bateman at oracle.com  Tue Oct 22 14:15:10 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Oct 2019 15:15:10 +0100
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
Message-ID: <eb40ba74-f3a9-2127-959b-8673aedd85e6@oracle.com>

On 22/10/2019 04:22, mark.reinhold at oracle.com wrote:
> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
I've read through the code for the new jlink plugins and the changes to 
VersionProps and it looks good.

An alternative for VersionProps would have been to generate a helper 
class at link time rather than extending the static initilizer to set 
the fields. That would allow the VENDOR* fields to be final (but I don't 
think it makes too much difference and it may be a bit more complicated 
due to having 4 plugins contributing code).

The need for a plugin per CLI option may be motivation to explore (in 
the future) having a single plugin expose multiple options.

-Alan

From claes.redestad at oracle.com  Tue Oct 22 15:03:36 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 22 Oct 2019 17:03:36 +0200
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <2dbde280-086a-4eae-9f8a-8c2652c30ce0@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
 <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
 <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>
 <2dbde280-086a-4eae-9f8a-8c2652c30ce0@oracle.com>
Message-ID: <177392ac-e157-f726-a3b4-8d551414782c@oracle.com>



On 2019-10-22 15:55, David Holmes wrote:
>>> With your change interface I's registerNatives default method is 
>>> invoked successfully.? I don't think this is a major backward 
>>> compatibilty issue but we should have someone from core-libs okay the 
>>> removal of the method from Object before committing.? In addition, 
>>> can you add this test as part of your change?? I think it would be 
>>> okay to put it in open/test/hotspot/jtreg/runtime/8024804 which 
>>> contains an existing registerNatives test.
>>
>> Yeah, *not* throwing an IAE on this feels like an unintentional bug fix.
>> :-)
> 
> Yes it is a somewhat surprising aspect of default method resolution, but 
> methods in the class hierarchy must be considered ahead of any default 
> method - even inaccessible ones.
> 
>> We're relaxing a very subtle interaction, so I think compatibility
>> issues with existing code is non-existing. 
> 
> I don't think there is a compatibility issue here because we don't in 
> general have to maintain error compatibility. However as it is a change 
> in behaviour it does warrant a CSR request just so the compatibility 
> argument is captured/recorded.
> 

Filed and drafted a CSR: https://bugs.openjdk.java.net/browse/JDK-8232801

Thanks!

/Claes

From adam.farley at uk.ibm.com  Tue Oct 22 15:35:37 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 22 Oct 2019 16:35:37 +0100
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <5152be78-bf16-3473-1c52-fd5adf211944@oracle.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <5152be78-bf16-3473-1c52-fd5adf211944@oracle.com>
Message-ID: <OF42DDFB73.5588707A-ON0025849B.00445C08-8025849B.0055A96B@notes.na.collabserv.com>

Hi Alan,

Thanks for the quick response.

Stewart, if you have a moment, could you please advise on the section with 
the @Stewart tag?

Alan Bateman <Alan.Bateman at oracle.com> wrote on 22/10/2019 12:36:26:

> From: Alan Bateman <Alan.Bateman at oracle.com>
...
> This looks very messy and I don't think is in any state to be reviewed. 

I'm sorry to hear that. The code was always meant as a very rough
draft to demonstrate what I had in mind, but your word choice there
tells me it's likely more "rough" than I had intended.

The thing that stands out the most, to me, are the ten two-layer 
single-line "IF" statements. The outer layer could be merged with the 
inner layer if I knew for sure that combining a static final boolean 
check with a non-static, non-final boolean check wouldn't discourage 
the JIT from optimising it away. Plus, some curly braces wouldn't hurt.

so this:

if (JDK_CL_VERBOSE)
    if (showClassLoading)
        ClassLoaderDiagnosticsHelper.doSomething();

Would become this:

if (JDK_CL_VERBOSE && showClassLoading) {
    ClassLoaderDiagnosticsHelper.doSomething();
}

I'd appreciate your thoughts on that, and while I appreciate that it would 

be unfair to expect you walk me though every problem in the code, it would
help me as a developer if you could bullet-point the biggest problems.

> When changing existing code it is important to respect the existing 
> coding conventions and keep the style as consistent as possible. Also we 

> should avoid adding new code in 2019 that uses Vector, StringTokenizer 
> and other legacy classes.

That's fair. If we do end up using some form of the Diagnostics Helper
class, I'll be sure to re-write it to exclude legacy classes.

> 
> That said, I think we do need to improve the serviceability and 
> diagnosability in the java.base module. This will become more important 
> as more of the runtime is developed in the libraries rather than in 
> libjvm. We have ad hoc logging in several areas, and one or two places 
> that emit JFR events, but don't have a consistent approach. Stuart Marks 

> lead a discussion on this at the OpenJDK workshop in August but it 
> didn't get any far. Maybe your needs may help that discussion to get 
> going again.

@Stuart ^

@Alan: I've added Stuart to this chain. Perhaps he could advise on the 
right way to address this issue. Whether we salvage this webrev or not, 
I feel we agree that more diagnostic information from the classloader 
would be beneficial.

> 
> For the issue at hand, maybe you could start by describing some of the 
> needs in the class loader areas. Is it mostly visibility issues? I see 
> the issue you created in JBS mentions "wrong version of a class" which 
> suggests you are interested in linkage errors too.
> 
> -Alan
> 

The primary need is to answer the following question for the everyman:

"Why isn't OpenJDK loading the class I want it to?"

By adding extra debugging to the ClassLoader, I hope to answer that
question for anyone who has that problem, regardless of the specific 
circumstance.

The bug was me attempting to flesh out that question, rather than a
strict list of contexts.

Hope that answers your question. :)

- Adam 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From adam.farley at uk.ibm.com  Tue Oct 22 15:42:42 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 22 Oct 2019 16:42:42 +0100
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
Message-ID: <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>

Hi David,

I didn't, no. Thanks for pointing it out. :)

I see this tells us where the class comes from, much like 
"-verbose:class".

So it's useful when a class can be successfully loaded, but 
doesn't tell us which classloaders tried to load the class, 
nor where they looked, etc.

Something I could have done a better job conveying was that
the core question this debugging is meant to answer is:

"Why didn't OpenJDK load the class I wanted it to?"

"-Xlog:class+load" seems very useful for finding where a
class came from, which answers the "loading the wrong version 
of a class" problem, but does not seem to give us 
information in the case of class loading failure.

Also, thanks for moving the bug to the correct component. :)

Best Regards

Adam Farley 
IBM Runtimes


David Holmes <david.holmes at oracle.com> wrote on 22/10/2019 14:12:55:

> From: David Holmes <david.holmes at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, Java Core Libs <core-
> libs-dev at openjdk.java.net>
> Date: 22/10/2019 14:14
> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output 
> for Specific Classes
> 
> Hi Adam,
> 
> Did you look at the logging available from the VM: -Xlog:class+load?
> 
> BTW I moved the bug you filed to the correct component.
> 
> Cheers,
> David
> 
> On 22/10/2019 8:40 pm, Adam Farley8 wrote:
> > Hey All,
> > 
> > This one goes out to anyone who's struggled to figure out
> > why OpenJDK isn't loading their class.
> > 
> > The requirement is for OpenJDK to give more detailed
> > information while loading user-specified classes (e.g. the
> > one OpenJDK is failing to load). Some debug information is
> > available while the loading is in-progress, and more is
> > available after the fact, but it seems there is not a way
> > to monitor what the ClassLoaders are actually doing without
> > the use of debugging tools.
> > 
> > For your approval: a formal write-up of the problem (as
> > I understand it), and a draft webrev containing the
> > proposed solution.
> > 
> > Tests will be developed and added if/when the issue is
> > accepted as a problem, and a solution has been selected.
> > 
> > Please review and opine.
> > 
> > Bug: https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232773&d=DwICaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=WEfc_wG4s2o_lhOKcZOykIG0RNybBiMMVbKIzmrlY3k&e=
> > 
> > Webrev: https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__cr.openjdk.java.net_-7Eafarley_8232773_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=jDSMDaCpBBZcYMU-
> IUqDh8PoCyl1Jk1G-QGIPKGjgeY&e= 
> > 
> > Thanks for your time. :)
> > 
> > Best Regards
> > 
> > Adam Farley
> > IBM Runtimes
> > 
> > 
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with 
number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> > 
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From ioi.lam at oracle.com  Tue Oct 22 16:10:23 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 22 Oct 2019 09:10:23 -0700
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
 <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
Message-ID: <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>

Hi Adam,

The HotSpot logging option:

 ????? -Xlog:class+load=debug

will show the class loader, super class, interfaces, size of the 
classfile, etc.

A related option:

 ????? -Xlog:class+resolve=debug

shows all the class resolution done by the Java code during execution.

You're right that these logs happen only when the class is successfully 
loaded/resolved. If we add similar logs for failures, will that address 
your needs? The syntax would be something like

 ????? -Xlog:class+load+failure=debug

BTW, the bug report mention "What each ClassLoaders' classpath was", but 
custom class loader doesn't necessarily have the notion of "a class path".


Thanks.
- Ioi

On 10/22/19 8:42 AM, Adam Farley8 wrote:
> Hi David,
>
> I didn't, no. Thanks for pointing it out. :)
>
> I see this tells us where the class comes from, much like
> "-verbose:class".
>
> So it's useful when a class can be successfully loaded, but
> doesn't tell us which classloaders tried to load the class,
> nor where they looked, etc.
>
> Something I could have done a better job conveying was that
> the core question this debugging is meant to answer is:
>
> "Why didn't OpenJDK load the class I wanted it to?"
>
> "-Xlog:class+load" seems very useful for finding where a
> class came from, which answers the "loading the wrong version
> of a class" problem, but does not seem to give us
> information in the case of class loading failure.
>
> Also, thanks for moving the bug to the correct component. :)
>
> Best Regards
>
> Adam Farley
> IBM Runtimes
>
>
> David Holmes <david.holmes at oracle.com> wrote on 22/10/2019 14:12:55:
>
>> From: David Holmes <david.holmes at oracle.com>
>> To: Adam Farley8 <adam.farley at uk.ibm.com>, Java Core Libs <core-
>> libs-dev at openjdk.java.net>
>> Date: 22/10/2019 14:14
>> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
>> for Specific Classes
>>
>> Hi Adam,
>>
>> Did you look at the logging available from the VM: -Xlog:class+load?
>>
>> BTW I moved the bug you filed to the correct component.
>>
>> Cheers,
>> David
>>
>> On 22/10/2019 8:40 pm, Adam Farley8 wrote:
>>> Hey All,
>>>
>>> This one goes out to anyone who's struggled to figure out
>>> why OpenJDK isn't loading their class.
>>>
>>> The requirement is for OpenJDK to give more detailed
>>> information while loading user-specified classes (e.g. the
>>> one OpenJDK is failing to load). Some debug information is
>>> available while the loading is in-progress, and more is
>>> available after the fact, but it seems there is not a way
>>> to monitor what the ClassLoaders are actually doing without
>>> the use of debugging tools.
>>>
>>> For your approval: a formal write-up of the problem (as
>>> I understand it), and a draft webrev containing the
>>> proposed solution.
>>>
>>> Tests will be developed and added if/when the issue is
>>> accepted as a problem, and a solution has been selected.
>>>
>>> Please review and opine.
>>>
>>> Bug: https://urldefense.proofpoint.com/v2/url?
> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232773&d=DwICaQ&c=jf_iaSHvJObTbx-
>> siA1ZOg&r=P5m8KWUXJf-
>>
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=WEfc_wG4s2o_lhOKcZOykIG0RNybBiMMVbKIzmrlY3k&e=
>>> Webrev: https://urldefense.proofpoint.com/v2/url?
> u=http-3A__cr.openjdk.java.net_-7Eafarley_8232773_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-
>> siA1ZOg&r=P5m8KWUXJf-
>>
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=jDSMDaCpBBZcYMU-
>> IUqDh8PoCyl1Jk1G-QGIPKGjgeY&e=
>>> Thanks for your time. :)
>>>
>>> Best Regards
>>>
>>> Adam Farley
>>> IBM Runtimes
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with
> number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>


From vladimir.kozlov at oracle.com  Tue Oct 22 16:38:42 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 22 Oct 2019 09:38:42 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
Message-ID: <6b0b5b46-a5af-adc2-4119-7991f76d2350@oracle.com>

HotSpot changes seem fine to me.

Thanks,
Vladimir

On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote:
> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
> 
> This change implements jlink plugins, and associated changes in the VM
> and libraries, to support the following new jlink options:
> 
>    - --vendor-bug-url=<vendor-bug-url> overrides the vendor bug URL baked
>      into the build.  The value of the system property "java.vendor.url.bug"
>      will be <vendor-bug-url>.
> 
>    - --vendor-vm-bug-url=<vendor-vm-bug-url> overrides the vendor VM bug
>      URL baked into the build.  This value will be displayed in VM error
>      logs.
> 
>    - --vendor-version=<vendor-version> overrides the vendor version string
>      baked into the build, if any.  The value of the system property
>      "java.vendor.version" will be <vendor-version>.  This value will be
>      displayed in the output of java --version.
> 
>    - --add-options=<options> prepends the specified <options> string,
>      which may include whitespace, before any other options when invoking
>      the VM in the resulting image.
> 
> The vendor-information plugins work by using the JDK?s internal ASM
> library to redefine static fields in the java.lang.VersionProps class.
> The VM reads the vendor-version and vendor-vm-bug-url strings from that
> class during startup.
> 
> The add-options plugin works by storing the requested options in an
> internal resource, /java.base/jdk/internal/vm/options.  The VM loads that
> resource from the lib/modules jimage file during startup and prepends any
> options found there to those given on the command line.
> 
> Passes tier1-3 and JCK on {linux,macos,windows}-x64.
> 
> Thanks,
> - Mark
> 

From lance.andersen at oracle.com  Tue Oct 22 17:00:41 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 22 Oct 2019 13:00:41 -0400
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
Message-ID: <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>


> On Oct 18, 2019, at 7:18 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 16/10/2019 18:06, Lance Andersen wrote:
>> Hi all,
>> 
>> Please review this fix to ZipFileInputStream::skip when specifying a negative value to the skip method when accessing a STORED entry, https://bugs.openjdk.java.net/browse/JDK-8231451 <https://bugs.openjdk.java.net/browse/JDK-8231451>.  Prior to this fix, you could move past the beginning of the STORED entry.
>> 
>> I also added a release note, https://bugs.openjdk.java.net/browse/JDK-8232384 <https://bugs.openjdk.java.net/browse/JDK-8232384>, to help clarify the behavior of these methods when a negative value is specified.
>> 
>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8231451/webrev.00/index.html>
>> 
> This seems to introduce inconsistency in that an attempt to seek beyond EOF will return the number of bytes skipped or 0 where as attempting to seek to before the start will throw IOException. It might be a corner case but a better alternative might be to seek to position 0, returning the number of bytes that were (negatively) skipped to get to 0.
> 

Per your suggestion, I tweaked the patch to move to BOF when the negative skip value goes beyond BOF.  I updated the release note as well.

webrev can be found at: http://cr.openjdk.java.net/~lancea/8231451/webrev.01/index.html <http://cr.openjdk.java.net/~lancea/8231451/webrev.01/index.html>

mach 5  jdk1 - jdk3 tiers  continue to pass.

Best
Lance


> -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 lois.foltan at oracle.com  Tue Oct 22 17:09:31 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 22 Oct 2019 13:09:31 -0400
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <177392ac-e157-f726-a3b4-8d551414782c@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
 <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
 <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>
 <2dbde280-086a-4eae-9f8a-8c2652c30ce0@oracle.com>
 <177392ac-e157-f726-a3b4-8d551414782c@oracle.com>
Message-ID: <44c42376-e03d-015b-cf39-3f112af1e1bd@oracle.com>

On 10/22/2019 11:03 AM, Claes Redestad wrote:
>
>
> On 2019-10-22 15:55, David Holmes wrote:
>>>> With your change interface I's registerNatives default method is 
>>>> invoked successfully.? I don't think this is a major backward 
>>>> compatibilty issue but we should have someone from core-libs okay 
>>>> the removal of the method from Object before committing.? In 
>>>> addition, can you add this test as part of your change?? I think it 
>>>> would be okay to put it in open/test/hotspot/jtreg/runtime/8024804 
>>>> which contains an existing registerNatives test.
>>>
>>> Yeah, *not* throwing an IAE on this feels like an unintentional bug 
>>> fix.
>>> :-)
>>
>> Yes it is a somewhat surprising aspect of default method resolution, 
>> but methods in the class hierarchy must be considered ahead of any 
>> default method - even inaccessible ones.
>>
>>> We're relaxing a very subtle interaction, so I think compatibility
>>> issues with existing code is non-existing. 
>>
>> I don't think there is a compatibility issue here because we don't in 
>> general have to maintain error compatibility. However as it is a 
>> change in behaviour it does warrant a CSR request just so the 
>> compatibility argument is captured/recorded.
>>
>
> Filed and drafted a CSR: https://bugs.openjdk.java.net/browse/JDK-8232801

Hi Claes,

You have my review for webrev .03.? Thanks for adding the test case.? I 
agree with David that a CSR is warranted.? Only minor comment I have on 
it is that in a couple of places you use "IllegalArgumentError" instead 
of "IllegalAccessError".

Thanks,
Lois

>
>
> Thanks!
>
> /Claes


From claes.redestad at oracle.com  Tue Oct 22 17:19:44 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 22 Oct 2019 19:19:44 +0200
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <44c42376-e03d-015b-cf39-3f112af1e1bd@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
 <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
 <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>
 <2dbde280-086a-4eae-9f8a-8c2652c30ce0@oracle.com>
 <177392ac-e157-f726-a3b4-8d551414782c@oracle.com>
 <44c42376-e03d-015b-cf39-3f112af1e1bd@oracle.com>
Message-ID: <dc76dfc4-4a6f-8aae-f775-90d21c54eb5b@oracle.com>



On 2019-10-22 19:09, Lois Foltan wrote:
>>
>> Filed and drafted a CSR: https://bugs.openjdk.java.net/browse/JDK-8232801
> 
> Hi Claes,
> 
> You have my review for webrev .03. 

Thanks!

> Thanks for adding the test case.? I 
> agree with David that a CSR is warranted.? Only minor comment I have on 
> it is that in a couple of places you use "IllegalArgumentError" instead 
> of "IllegalAccessError".

Fixed.

/Claes

From bob.vandette at oracle.com  Tue Oct 22 17:31:55 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 22 Oct 2019 13:31:55 -0400
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
Message-ID: <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>

In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE?

- jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
+ jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);

This will require some minor changes to jvmFlags.hpp

  34 struct JVMFlag {
  35   enum Flags {
  36     // latest value origin
  37     DEFAULT          = 0,
  38     COMMAND_LINE     = 1,
  39     ENVIRON_VAR      = 2,
  40     CONFIG_FILE      = 3,
  41     MANAGEMENT       = 4,
  42     ERGONOMIC        = 5,
  43     ATTACH_ON_DEMAND = 6,
  44     INTERNAL         = 7,

+  45     RESOURCE         = 8,

  46 

-  47      LAST_VALUE_ORIGIN = INTERNAL,
 + 47     LAST_VALUE_ORIGIN = RESOURCE,

Bob.


> On Oct 21, 2019, at 11:22 PM, mark.reinhold at oracle.com wrote:
> 
> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
> 
> This change implements jlink plugins, and associated changes in the VM
> and libraries, to support the following new jlink options:
> 
>  - --vendor-bug-url=<vendor-bug-url> overrides the vendor bug URL baked
>    into the build.  The value of the system property "java.vendor.url.bug"
>    will be <vendor-bug-url>.
> 
>  - --vendor-vm-bug-url=<vendor-vm-bug-url> overrides the vendor VM bug
>    URL baked into the build.  This value will be displayed in VM error
>    logs.
> 
>  - --vendor-version=<vendor-version> overrides the vendor version string
>    baked into the build, if any.  The value of the system property
>    "java.vendor.version" will be <vendor-version>.  This value will be
>    displayed in the output of java --version.
> 
>  - --add-options=<options> prepends the specified <options> string,
>    which may include whitespace, before any other options when invoking
>    the VM in the resulting image.
> 
> The vendor-information plugins work by using the JDK?s internal ASM
> library to redefine static fields in the java.lang.VersionProps class.
> The VM reads the vendor-version and vendor-vm-bug-url strings from that
> class during startup.
> 
> The add-options plugin works by storing the requested options in an
> internal resource, /java.base/jdk/internal/vm/options.  The VM loads that
> resource from the lib/modules jimage file during startup and prepends any
> options found there to those given on the command line.
> 
> Passes tier1-3 and JCK on {linux,macos,windows}-x64.
> 
> Thanks,
> - Mark


From Alan.Bateman at oracle.com  Tue Oct 22 18:25:39 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Oct 2019 19:25:39 +0100
Subject: 8231602: Deprecate Thread.suspend/resume for removal
Message-ID: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>

I brought up the issue of deprecating, for removal, 
Thread.suspend/resume a few weeks ago [1]. Mark said "Got for it", no 
other replies or objections.

Here's the webrev with the changes to deprecate-for-removal 
Thread.suspend/resume, ThreadGroup.suspend/resume, and 
ThreadGroup.allowThreadSuspsion:
 ?? http://cr.openjdk.java.net/~alanb/8231602/webrev/index.html

The resulting javadoc is clear that the method is deprecated for removal 
and there is already text and a link to a supporting document so I don't 
think any more is needed.

The CSR is here, I think Stuart plans to look at it.
 ?? https://bugs.openjdk.java.net/browse/JDK-8232655

-Alan

[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062571.html

From Alan.Bateman at oracle.com  Tue Oct 22 18:37:32 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Oct 2019 19:37:32 +0100
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
 <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>
Message-ID: <fe6bf497-b192-256b-8542-2face7386931@oracle.com>

On 22/10/2019 18:00, Lance Andersen wrote:
>
> Per your suggestion, I tweaked the patch to move to BOF when the 
> negative skip value goes beyond BOF. ?I updated the release note as well.
>
> webrev can be found at: 
> http://cr.openjdk.java.net/~lancea/8231451/webrev.01/index.html
>
I assume skip(Long.MAX_VALUE) will cause n+pos to overflow and it will 
skip backwards rather than to the end. It might be simpler to read/audit 
if you separate the negative skip case.

-Alan

From andy.herrick at oracle.com  Tue Oct 22 18:50:04 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 22 Oct 2019 14:50:04 -0400
Subject: RFR: JDK-8232723: make the resource file main.wxs over-ridable
Message-ID: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

use createResource() to get an over-ridable resource.

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

[2] http://cr.openjdk.java.net/~herrick/8232723/webrev.01

/Andy


From alexey.semenyuk at oracle.com  Tue Oct 22 18:57:08 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 22 Oct 2019 14:57:08 -0400
Subject: RFR: JDK-8232723: make the resource file main.wxs over-ridable
In-Reply-To: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>
References: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>
Message-ID: <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>

Looks good.

It would be good to have a test for this change as a part of this fix or 
as a follow up CR.

- Alexey

On 10/22/2019 2:50 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> use createResource() to get an over-ridable resource.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232723
>
> [2] http://cr.openjdk.java.net/~herrick/8232723/webrev.01
>
> /Andy
>


From mark.reinhold at oracle.com  Tue Oct 22 19:22:32 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 22 Oct 2019 12:22:32 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
Message-ID: <20191022122232.395077958@eggemoggin.niobe.net>

2019/10/22 10:31:55 -0700, bob.vandette at oracle.com:
> In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE?
> 
> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);
> 
> This will require some minor changes to jvmFlags.hpp
> 
>   34 struct JVMFlag {
>   35   enum Flags {
>   36     // latest value origin
>   37     DEFAULT          = 0,
>   38     COMMAND_LINE     = 1,
>   39     ENVIRON_VAR      = 2,
>   40     CONFIG_FILE      = 3,
>   41     MANAGEMENT       = 4,
>   42     ERGONOMIC        = 5,
>   43     ATTACH_ON_DEMAND = 6,
>   44     INTERNAL         = 7,
> 
> +  45     RESOURCE         = 8,
> 
>   46 
> 
> -  47      LAST_VALUE_ORIGIN = INTERNAL,
>  + 47     LAST_VALUE_ORIGIN = RESOURCE,

Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin
to handle the RESOURCE case (which is easy).

Is ?RESOURCE? the best name here?  Sounds awfully generic.  How about
?JIMAGE? or ?JIMAGE_RESOURCE??

- Mark

From mark.reinhold at oracle.com  Tue Oct 22 19:25:17 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 22 Oct 2019 12:25:17 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <eb40ba74-f3a9-2127-959b-8673aedd85e6@oracle.com>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <eb40ba74-f3a9-2127-959b-8673aedd85e6@oracle.com>
Message-ID: <20191022122517.305808697@eggemoggin.niobe.net>

2019/10/22 7:15:10 -0700, alan.bateman at oracle.com:
> On 22/10/2019 04:22, mark.reinhold at oracle.com wrote:
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
> 
> I've read through the code for the new jlink plugins and the changes to 
> VersionProps and it looks good.
> 
> An alternative for VersionProps would have been to generate a helper 
> class at link time rather than extending the static initilizer to set 
> the fields. That would allow the VENDOR* fields to be final (but I don't 
> think it makes too much difference and it may be a bit more complicated 
> due to having 4 plugins contributing code).

Yes, that would?ve been more complex, and the finality of these fields
isn?t critical.

> The need for a plugin per CLI option may be motivation to explore (in 
> the future) having a single plugin expose multiple options.

Agreed.

Thanks,
- Mark

From andy.herrick at oracle.com  Tue Oct 22 19:34:24 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 22 Oct 2019 15:34:24 -0400
Subject: RFR: JDK-8232723: make the resource file main.wxs over-ridable
In-Reply-To: <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>
References: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>
 <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>
Message-ID: <ea1fe4f2-70d3-e140-4599-419a85752c6c@oracle.com>

There really aren't any tests for overridable resources in packages, the 
mechanism is only tested by testing the one resource that is 
overriddable in app-image build, the app icon.

This the second resources overridable in windows packages, (the 
post-install script is the other).

On Linux (other than icons) there seem to be 3 overridable resources, 
and on macos there seem to be 4 each for dmg and pkg packages.

In most cases, even though the automation can create packages with the 
overridden resources, we will not be able to automatically verify the 
custom resources are used.

This is a good project for our upcoming test sprint: To develop 
automated tests that generate packages with each of these resources 
overridden, and instructions to manually verify the custom resource was 
used.

/Andy

On 10/22/2019 2:57 PM, Alexey Semenyuk wrote:
> Looks good.
>
> It would be good to have a test for this change as a part of this fix 
> or as a follow up CR.
>
> - Alexey
>
> On 10/22/2019 2:50 PM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> use createResource() to get an over-ridable resource.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232723
>>
>> [2] http://cr.openjdk.java.net/~herrick/8232723/webrev.01
>>
>> /Andy
>>
>

From bob.vandette at oracle.com  Tue Oct 22 19:43:42 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 22 Oct 2019 15:43:42 -0400
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191022122232.395077958@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
 <20191022122232.395077958@eggemoggin.niobe.net>
Message-ID: <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>



> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote:
> 
> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com:
>> In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE?
>> 
>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);
>> 
>> This will require some minor changes to jvmFlags.hpp
>> 
>>  34 struct JVMFlag {
>>  35   enum Flags {
>>  36     // latest value origin
>>  37     DEFAULT          = 0,
>>  38     COMMAND_LINE     = 1,
>>  39     ENVIRON_VAR      = 2,
>>  40     CONFIG_FILE      = 3,
>>  41     MANAGEMENT       = 4,
>>  42     ERGONOMIC        = 5,
>>  43     ATTACH_ON_DEMAND = 6,
>>  44     INTERNAL         = 7,
>> 
>> +  45     RESOURCE         = 8,
>> 
>>  46 
>> 
>> -  47      LAST_VALUE_ORIGIN = INTERNAL,
>> + 47     LAST_VALUE_ORIGIN = RESOURCE,
> 
> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin
> to handle the RESOURCE case (which is easy).
> 
> Is ?RESOURCE? the best name here?  Sounds awfully generic.  How about
> ?JIMAGE? or ?JIMAGE_RESOURCE??


JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.

Bob.

> 
> - Mark


From mandy.chung at oracle.com  Tue Oct 22 20:25:35 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 22 Oct 2019 13:25:35 -0700
Subject: 8231602: Deprecate Thread.suspend/resume for removal
In-Reply-To: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>
References: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>
Message-ID: <92c4c6b5-d067-3d30-f8e1-9e837a0ce986@oracle.com>

Looks fine to me.

Mandy

On 10/22/19 11:25 AM, Alan Bateman wrote:
> I brought up the issue of deprecating, for removal, 
> Thread.suspend/resume a few weeks ago [1]. Mark said "Got for it", no 
> other replies or objections.
>
> Here's the webrev with the changes to deprecate-for-removal 
> Thread.suspend/resume, ThreadGroup.suspend/resume, and 
> ThreadGroup.allowThreadSuspsion:
> ?? http://cr.openjdk.java.net/~alanb/8231602/webrev/index.html
>
> The resulting javadoc is clear that the method is deprecated for 
> removal and there is already text and a link to a supporting document 
> so I don't think any more is needed.
>
> The CSR is here, I think Stuart plans to look at it.
> ?? https://bugs.openjdk.java.net/browse/JDK-8232655
>
> -Alan
>
> [1] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062571.html


From alexander.matveev at oracle.com  Tue Oct 22 21:10:06 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 22 Oct 2019 14:10:06 -0700
Subject: RFR: JDK-8232723: make the resource file main.wxs over-ridable
In-Reply-To: <ea1fe4f2-70d3-e140-4599-419a85752c6c@oracle.com>
References: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>
 <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>
 <ea1fe4f2-70d3-e140-4599-419a85752c6c@oracle.com>
Message-ID: <b5ec7bd5-2a18-3ced-f309-5ecf71f3a971@oracle.com>

Looks good.

On 10/22/2019 12:34 PM, Andy Herrick wrote:
> There really aren't any tests for overridable resources in packages, 
> the mechanism is only tested by testing the one resource that is 
> overriddable in app-image build, the app icon.
>
> This the second resources overridable in windows packages, (the 
> post-install script is the other).
>
> On Linux (other than icons) there seem to be 3 overridable resources, 
> and on macos there seem to be 4 each for dmg and pkg packages.
>
> In most cases, even though the automation can create packages with the 
> overridden resources, we will not be able to automatically verify the 
> custom resources are used.
>
> This is a good project for our upcoming test sprint: To develop 
> automated tests that generate packages with each of these resources 
> overridden, and instructions to manually verify the custom resource 
> was used.
>
> /Andy
>
> On 10/22/2019 2:57 PM, Alexey Semenyuk wrote:
>> Looks good.
>>
>> It would be good to have a test for this change as a part of this fix 
>> or as a follow up CR.
>>
>> - Alexey
>>
>> On 10/22/2019 2:50 PM, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> use createResource() to get an over-ridable resource.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232723
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8232723/webrev.01
>>>
>>> /Andy
>>>
>>


From mandy.chung at oracle.com  Tue Oct 22 21:12:18 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 22 Oct 2019 14:12:18 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
Message-ID: <a26a4f81-f923-06f2-a118-84dd0d09a4cf@oracle.com>



On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote:
> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
>

Looks good to me.? One minor comment:

AddResourcePlugin isn't really a FILTER, probably best to add a new 
category for new resource file.?? jlink hardcodes the order of the 
categories that determines the order of the plugins to be executed (I 
see the existing implementation could be cleaned up in the future). ? I 
think we didn't want to the options resource to be filtered by 
--exclude-resources plugin and so the add-options plugin should run 
after all filter plugins.

Mandy

From alexey.semenyuk at oracle.com  Tue Oct 22 21:14:13 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 22 Oct 2019 17:14:13 -0400
Subject: RFR: JDK-8232073: [deb] RuntimePackageTest should not have shared
 folder after install
In-Reply-To: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
Message-ID: <1e06d69b-e0c0-aaf9-f0bb-c5a69b9f266f@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

Additionally:
- fixes for [3], [4], [5] and [6]? bugs.
- removed unused l10n strings from Windows resource files.
- replaced `throw new 
ConfigException(I18N.getString("error.parameters-null"), 
I18N.getString("error.parameters-null.advice"))` with 
`Objects.requireNonNull(params);`. There is no point to localize 
internal jpackage errors.
- add `Win64`? attribute with value `yes` to all Component elements 
generated for application image files. Explicit tagging of components 
64bit would make sense in case somebody would like to override default 
jpackage settings and make 32bit msi installers.
- added a step to call user provided .wsh after msi package is created 
but before it is embedded in exe installer. Can be use to sign msi 
before it get embedded in exe installer.

The patch is based on [7].

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8232073/webrev.00/

[3] https://bugs.openjdk.java.net/browse/JDK-8232029

[4] https://bugs.openjdk.java.net/browse/JDK-8232646

[5] https://bugs.openjdk.java.net/browse/JDK-8136879

[6] https://bugs.openjdk.java.net/browse/JDK-8232728

[7] http://cr.openjdk.java.net/~asemenyuk/8231972/webrev.00

From alexander.matveev at oracle.com  Tue Oct 22 21:29:55 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 22 Oct 2019 14:29:55 -0700
Subject: RFR: JDK-8232186: Add verification for pkg and dmg tests
Message-ID: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Removed --mac-app-store-category.
- Added Hello.java test app to support file association on OS X.
- Modified Hello.java to write output file to user home location if 
working directory is not writable.
- Fixed MacHelper:getInstallationDirectory(). It was returning extra 
/Applications when --install-dir is specified.
- Fixed SigningPackageTest to use path returned by withExplodedDmg 
correctly.
- Added install/uninstall support for pkg and dmg to manage_packages.sh.
- Fixed replaceFileName(), otherwise on OS X it was not replacing file 
name correctly, since file name does not have extension.
- Added NameWithSpaceTest.
- Removed OptionsTest which is covered by other tests.

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

[2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/

Thanks,
Alexander

From mandy.chung at oracle.com  Tue Oct 22 21:52:40 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 22 Oct 2019 14:52:40 -0700
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <177392ac-e157-f726-a3b4-8d551414782c@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
 <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
 <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>
 <2dbde280-086a-4eae-9f8a-8c2652c30ce0@oracle.com>
 <177392ac-e157-f726-a3b4-8d551414782c@oracle.com>
Message-ID: <df68a77c-11e3-0f4d-13fd-665d7967d599@oracle.com>



On 10/22/19 8:03 AM, Claes Redestad wrote:
> http://cr.openjdk.java.net/~redestad/8232613/open.03

Looks good to me.

> Filed and drafted a CSR: https://bugs.openjdk.java.net/browse/JDK-8232801
>

I think it'd be good to include the IAE message as an example.

Is there a CSR that documents the previous behavior?? If so, it'd be 
useful to link them.

Mandy

From david.holmes at oracle.com  Tue Oct 22 22:18:56 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Oct 2019 08:18:56 +1000
Subject: 8231602: Deprecate Thread.suspend/resume for removal
In-Reply-To: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>
References: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>
Message-ID: <ffc729d8-0083-948b-cfda-c254dbedb5dd@oracle.com>

All looks good to me! :)

Thanks,
David

On 23/10/2019 4:25 am, Alan Bateman wrote:
> I brought up the issue of deprecating, for removal, 
> Thread.suspend/resume a few weeks ago [1]. Mark said "Got for it", no 
> other replies or objections.
> 
> Here's the webrev with the changes to deprecate-for-removal 
> Thread.suspend/resume, ThreadGroup.suspend/resume, and 
> ThreadGroup.allowThreadSuspsion:
>  ?? http://cr.openjdk.java.net/~alanb/8231602/webrev/index.html
> 
> The resulting javadoc is clear that the method is deprecated for removal 
> and there is already text and a link to a supporting document so I don't 
> think any more is needed.
> 
> The CSR is here, I think Stuart plans to look at it.
>  ?? https://bugs.openjdk.java.net/browse/JDK-8232655
> 
> -Alan
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062571.html 
> 

From mark.reinhold at oracle.com  Tue Oct 22 22:36:28 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 22 Oct 2019 15:36:28 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
 <20191022122232.395077958@eggemoggin.niobe.net>
 <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>
Message-ID: <20191022153628.417897318@eggemoggin.niobe.net>

2019/10/22 12:43:42 -0700, bob.vandette at oracle.com:
>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote:
>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com:
>>> In arguments.cpp, could you use a new JVMFlag to declare options
>>> that came from this resource as RESOURCE?
>>> 
>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);
>>> 
>>> This will require some minor changes to jvmFlags.hpp
>>> 
>>> ...
>> 
>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin
>> to handle the RESOURCE case (which is easy).
>> 
>> Is ?RESOURCE? the best name here?  Sounds awfully generic.  How about
>> ?JIMAGE? or ?JIMAGE_RESOURCE??
> 
> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.

JIMAGE_RESOURCE it is, then.  Relative patch below; original webrev
updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/).

- Mark


----

# HG changeset patch
# Parent  efca1844245ad7351418ef41efc86c5055ac3edf
Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options

diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -2203,7 +2203,7 @@
   set_mode_flags(_mixed);
 
   // Parse args structure generated from java.base vm options resource
-  jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
+  jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE);
   if (result != JNI_OK) {
     return result;
   }
diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp
--- a/src/hotspot/share/runtime/flags/jvmFlag.cpp
+++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp
@@ -697,6 +697,8 @@
       st->print("attach"); break;
     case INTERNAL:
       st->print("internal"); break;
+    case JIMAGE_RESOURCE:
+      st->print("jimage"); break;
   }
   st->print("}");
 }
diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp
--- a/src/hotspot/share/runtime/flags/jvmFlag.hpp
+++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp
@@ -44,8 +44,9 @@
     ERGONOMIC        = 5,
     ATTACH_ON_DEMAND = 6,
     INTERNAL         = 7,
+    JIMAGE_RESOURCE  = 8,
 
-    LAST_VALUE_ORIGIN = INTERNAL,
+    LAST_VALUE_ORIGIN = JIMAGE_RESOURCE,
     VALUE_ORIGIN_BITS = 4,
     VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS),
 

From mark.reinhold at oracle.com  Tue Oct 22 22:37:38 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 22 Oct 2019 15:37:38 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <a26a4f81-f923-06f2-a118-84dd0d09a4cf@oracle.com>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <a26a4f81-f923-06f2-a118-84dd0d09a4cf@oracle.com>
Message-ID: <20191022153738.224816243@eggemoggin.niobe.net>

2019/10/22 14:12:18 -0700, mandy.chung at oracle.com:
> On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote:
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
> 
> Looks good to me. One minor comment:
> 
> AddResourcePlugin isn't really a FILTER, probably best to add a new 
> category for new resource file. jlink hardcodes the order of the 
> categories that determines the order of the plugins to be executed (I 
> see the existing implementation could be cleaned up in the future).  I 
> think we didn't want to the options resource to be filtered by 
> --exclude-resources plugin and so the add-options plugin should run 
> after all filter plugins.

Good point -- that makes sense.

Relative patch below; original webrev updated in place.

Thanks,
- Mark

----

# HG changeset patch
# Parent  43f160bda3c7a2a7009df91afa37469760d42333
Addendum 2 (jlink ADDER): 8232080: jlink plugins for vendor information and run-time options

diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java
--- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java
+++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java
@@ -50,6 +50,7 @@
 
     static {
         CATEGORIES_ORDER.add(Category.FILTER);
+        CATEGORIES_ORDER.add(Category.ADDER);
         CATEGORIES_ORDER.add(Category.TRANSFORMER);
         CATEGORIES_ORDER.add(Category.MODULEINFO_TRANSFORMER);
         CATEGORIES_ORDER.add(Category.SORTER);
diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java
--- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java
+++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java
@@ -58,7 +58,7 @@
 
     @Override
     public Category getType() {
-        return Category.FILTER;
+        return Category.ADDER;
     }
 
     @Override
diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java
--- a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java
+++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java
@@ -39,6 +39,7 @@
      * Order of categories matches the plugin sort order.
      * <ol>
      * <li>FILTER: Filter in/out resources or files.</li>
+     * <li>ADDER: Add resources or files.</li>
      * <li>TRANSFORMER: Transform resources or files(eg: refactoring, bytecode
      * manipulation).</li>
      * <li>MODULEINFO_TRANSFORMER: Transform only module-info.class</li>
@@ -52,6 +53,7 @@
      */
     public enum Category {
         FILTER("FILTER"),
+        ADDER("ADDER"),
         TRANSFORMER("TRANSFORMER"),
         MODULEINFO_TRANSFORMER("MODULEINFO_TRANSFORMER"),
         SORTER("SORTER"),

From bob.vandette at oracle.com  Tue Oct 22 22:42:51 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 22 Oct 2019 18:42:51 -0400
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191022153628.417897318@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
 <20191022122232.395077958@eggemoggin.niobe.net>
 <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>
 <20191022153628.417897318@eggemoggin.niobe.net>
Message-ID: <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com>

Hotspot changes look good to me.

Bob.


> On Oct 22, 2019, at 6:36 PM, mark.reinhold at oracle.com wrote:
> 
> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com:
>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote:
>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com:
>>>> In arguments.cpp, could you use a new JVMFlag to declare options
>>>> that came from this resource as RESOURCE?
>>>> 
>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);
>>>> 
>>>> This will require some minor changes to jvmFlags.hpp
>>>> 
>>>> ...
>>> 
>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin
>>> to handle the RESOURCE case (which is easy).
>>> 
>>> Is ?RESOURCE? the best name here?  Sounds awfully generic.  How about
>>> ?JIMAGE? or ?JIMAGE_RESOURCE??
>> 
>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.
> 
> JIMAGE_RESOURCE it is, then.  Relative patch below; original webrev
> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/).
> 
> - Mark
> 
> 
> ----
> 
> # HG changeset patch
> # Parent  efca1844245ad7351418ef41efc86c5055ac3edf
> Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options
> 
> diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
> --- a/src/hotspot/share/runtime/arguments.cpp
> +++ b/src/hotspot/share/runtime/arguments.cpp
> @@ -2203,7 +2203,7 @@
>   set_mode_flags(_mixed);
> 
>   // Parse args structure generated from java.base vm options resource
> -  jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
> +  jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE);
>   if (result != JNI_OK) {
>     return result;
>   }
> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp
> --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp
> +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp
> @@ -697,6 +697,8 @@
>       st->print("attach"); break;
>     case INTERNAL:
>       st->print("internal"); break;
> +    case JIMAGE_RESOURCE:
> +      st->print("jimage"); break;
>   }
>   st->print("}");
> }
> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp
> --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp
> +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp
> @@ -44,8 +44,9 @@
>     ERGONOMIC        = 5,
>     ATTACH_ON_DEMAND = 6,
>     INTERNAL         = 7,
> +    JIMAGE_RESOURCE  = 8,
> 
> -    LAST_VALUE_ORIGIN = INTERNAL,
> +    LAST_VALUE_ORIGIN = JIMAGE_RESOURCE,
>     VALUE_ORIGIN_BITS = 4,
>     VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS),
> 


From alexander.matveev at oracle.com  Tue Oct 22 22:44:30 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 22 Oct 2019 15:44:30 -0700
Subject: RFR: JDK-8232073: [deb] RuntimePackageTest should not have shared
 folder after install
In-Reply-To: <1e06d69b-e0c0-aaf9-f0bb-c5a69b9f266f@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
 <1e06d69b-e0c0-aaf9-f0bb-c5a69b9f266f@oracle.com>
Message-ID: <97212a67-1d31-42f3-c1c9-b210b3fa8280@oracle.com>

Hi Alexey,

Looks good.

Thanks,
Alexander

On 10/22/2019 2:14 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally:
> - fixes for [3], [4], [5] and [6]? bugs.
> - removed unused l10n strings from Windows resource files.
> - replaced `throw new 
> ConfigException(I18N.getString("error.parameters-null"), 
> I18N.getString("error.parameters-null.advice"))` with 
> `Objects.requireNonNull(params);`. There is no point to localize 
> internal jpackage errors.
> - add `Win64`? attribute with value `yes` to all Component elements 
> generated for application image files. Explicit tagging of components 
> 64bit would make sense in case somebody would like to override default 
> jpackage settings and make 32bit msi installers.
> - added a step to call user provided .wsh after msi package is created 
> but before it is embedded in exe installer. Can be use to sign msi 
> before it get embedded in exe installer.
>
> The patch is based on [7].
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232073
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8232073/webrev.00/
>
> [3] https://bugs.openjdk.java.net/browse/JDK-8232029
>
> [4] https://bugs.openjdk.java.net/browse/JDK-8232646
>
> [5] https://bugs.openjdk.java.net/browse/JDK-8136879
>
> [6] https://bugs.openjdk.java.net/browse/JDK-8232728
>
> [7] http://cr.openjdk.java.net/~asemenyuk/8231972/webrev.00


From vladimir.kozlov at oracle.com  Tue Oct 22 22:44:55 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 22 Oct 2019 15:44:55 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
 <20191022122232.395077958@eggemoggin.niobe.net>
 <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>
 <20191022153628.417897318@eggemoggin.niobe.net>
 <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com>
Message-ID: <8B9D1BE8-531E-433A-AC6B-FE8088AD11C2@oracle.com>

+1

Thanks
Vladimir

> On Oct 22, 2019, at 3:42 PM, Bob Vandette <bob.vandette at oracle.com> wrote:
> 
> Hotspot changes look good to me.
> 
> Bob.
> 
> 
>> On Oct 22, 2019, at 6:36 PM, mark.reinhold at oracle.com wrote:
>> 
>> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com:
>>>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote:
>>>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com:
>>>>> In arguments.cpp, could you use a new JVMFlag to declare options
>>>>> that came from this resource as RESOURCE?
>>>>> 
>>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
>>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);
>>>>> 
>>>>> This will require some minor changes to jvmFlags.hpp
>>>>> 
>>>>> ...
>>>> 
>>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin
>>>> to handle the RESOURCE case (which is easy).
>>>> 
>>>> Is ?RESOURCE? the best name here?  Sounds awfully generic.  How about
>>>> ?JIMAGE? or ?JIMAGE_RESOURCE??
>>> 
>>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.
>> 
>> JIMAGE_RESOURCE it is, then.  Relative patch below; original webrev
>> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/).
>> 
>> - Mark
>> 
>> 
>> ----
>> 
>> # HG changeset patch
>> # Parent  efca1844245ad7351418ef41efc86c5055ac3edf
>> Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options
>> 
>> diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
>> --- a/src/hotspot/share/runtime/arguments.cpp
>> +++ b/src/hotspot/share/runtime/arguments.cpp
>> @@ -2203,7 +2203,7 @@
>>  set_mode_flags(_mixed);
>> 
>>  // Parse args structure generated from java.base vm options resource
>> -  jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
>> +  jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE);
>>  if (result != JNI_OK) {
>>    return result;
>>  }
>> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp
>> --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp
>> +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp
>> @@ -697,6 +697,8 @@
>>      st->print("attach"); break;
>>    case INTERNAL:
>>      st->print("internal"); break;
>> +    case JIMAGE_RESOURCE:
>> +      st->print("jimage"); break;
>>  }
>>  st->print("}");
>> }
>> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp
>> --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp
>> +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp
>> @@ -44,8 +44,9 @@
>>    ERGONOMIC        = 5,
>>    ATTACH_ON_DEMAND = 6,
>>    INTERNAL         = 7,
>> +    JIMAGE_RESOURCE  = 8,
>> 
>> -    LAST_VALUE_ORIGIN = INTERNAL,
>> +    LAST_VALUE_ORIGIN = JIMAGE_RESOURCE,
>>    VALUE_ORIGIN_BITS = 4,
>>    VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS),
>> 
> 


From david.holmes at oracle.com  Tue Oct 22 22:50:29 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Oct 2019 08:50:29 +1000
Subject: RFR: 8232613: Move Object.registerNatives into HotSpot
In-Reply-To: <df68a77c-11e3-0f4d-13fd-665d7967d599@oracle.com>
References: <52c2fe99-0e13-1976-996d-f9e5a0a120fa@oracle.com>
 <ee7dd075-e373-eb69-8551-dafbe86b95c4@oracle.com>
 <207cf237-2181-230f-23fb-f04951dfdb20@oracle.com>
 <582e7210-4219-b8ce-1af2-8c0740e9f30a@redhat.com>
 <070a514a-16d0-00df-727c-ec8680ab101a@oracle.com>
 <8f69b24f-6a8a-9e53-1ee9-6e9c14ec0c81@redhat.com>
 <0fccb5cf-928a-8809-1d14-957ffe2c388e@oracle.com>
 <05f0d393-f63e-f001-6f5c-fcafe7250e49@oracle.com>
 <da6ed98a-b02b-fba8-337f-8f74316e3968@oracle.com>
 <2dbde280-086a-4eae-9f8a-8c2652c30ce0@oracle.com>
 <177392ac-e157-f726-a3b4-8d551414782c@oracle.com>
 <df68a77c-11e3-0f4d-13fd-665d7967d599@oracle.com>
Message-ID: <60acca42-8a07-e683-71e6-d058be7c17e8@oracle.com>

On 23/10/2019 7:52 am, Mandy Chung wrote:
> 
> 
> On 10/22/19 8:03 AM, Claes Redestad wrote:
>> http://cr.openjdk.java.net/~redestad/8232613/open.03
> 
> Looks good to me.
> 
>> Filed and drafted a CSR: https://bugs.openjdk.java.net/browse/JDK-8232801
>>
> 
> I think it'd be good to include the IAE message as an example.
> 
> Is there a CSR that documents the previous behavior?? If so, it'd be 
> useful to link them.

The "behaviour" is just the way method resolution works, so no CSR for 
that. By removing a method from a super class it affects the potential 
result of the method resolution process.

David

> Mandy

From david.holmes at oracle.com  Tue Oct 22 22:58:35 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Oct 2019 08:58:35 +1000
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
 <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
Message-ID: <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>

On 23/10/2019 2:10 am, Ioi Lam wrote:
> Hi Adam,
> 
> The HotSpot logging option:
> 
>  ????? -Xlog:class+load=debug
> 
> will show the class loader, super class, interfaces, size of the 
> classfile, etc.
> 
> A related option:
> 
>  ????? -Xlog:class+resolve=debug
> 
> shows all the class resolution done by the Java code during execution.
> 
> You're right that these logs happen only when the class is successfully 
> loaded/resolved. If we add similar logs for failures, will that address 
> your needs? The syntax would be something like
> 
>  ????? -Xlog:class+load+failure=debug

Not sure that is meaningful as it isn't an error for a particular loader 
to not find a class, it's only an error for the entire loading process 
to fail to find it and that's already reported by the 
ClassNotFoundException. Any errors with the class after it has been 
found (LinkageErrors etc) should be clearly reported.

I'm not sure anything can really address the "why wasn't my class 
found?" question as the VM can't know where you thought it should be found.

Perhaps one aspect of the class loading/resolution/initialization 
process that can lead to confusion here is that if a class fails to 
execute its static initialization then it is marked as Erroneous and all 
subsequent attempts to use that class result in NoClassDefFoundError 
being thrown. If the original ExceptionInInitializerError got swallowed 
somewhere then that can cause great confusion as to why the later NCDFE 
occurs. The VM logging should help in that case - though I'd have to 
confirm that (if it doesn't that should be fixed).

David
-----

> BTW, the bug report mention "What each ClassLoaders' classpath was", but 
> custom class loader doesn't necessarily have the notion of "a class path".
> 
> 
> Thanks.
> - Ioi
> 
> On 10/22/19 8:42 AM, Adam Farley8 wrote:
>> Hi David,
>>
>> I didn't, no. Thanks for pointing it out. :)
>>
>> I see this tells us where the class comes from, much like
>> "-verbose:class".
>>
>> So it's useful when a class can be successfully loaded, but
>> doesn't tell us which classloaders tried to load the class,
>> nor where they looked, etc.
>>
>> Something I could have done a better job conveying was that
>> the core question this debugging is meant to answer is:
>>
>> "Why didn't OpenJDK load the class I wanted it to?"
>>
>> "-Xlog:class+load" seems very useful for finding where a
>> class came from, which answers the "loading the wrong version
>> of a class" problem, but does not seem to give us
>> information in the case of class loading failure.
>>
>> Also, thanks for moving the bug to the correct component. :)
>>
>> Best Regards
>>
>> Adam Farley
>> IBM Runtimes
>>
>>
>> David Holmes <david.holmes at oracle.com> wrote on 22/10/2019 14:12:55:
>>
>>> From: David Holmes <david.holmes at oracle.com>
>>> To: Adam Farley8 <adam.farley at uk.ibm.com>, Java Core Libs <core-
>>> libs-dev at openjdk.java.net>
>>> Date: 22/10/2019 14:14
>>> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
>>> for Specific Classes
>>>
>>> Hi Adam,
>>>
>>> Did you look at the logging available from the VM: -Xlog:class+load?
>>>
>>> BTW I moved the bug you filed to the correct component.
>>>
>>> Cheers,
>>> David
>>>
>>> On 22/10/2019 8:40 pm, Adam Farley8 wrote:
>>>> Hey All,
>>>>
>>>> This one goes out to anyone who's struggled to figure out
>>>> why OpenJDK isn't loading their class.
>>>>
>>>> The requirement is for OpenJDK to give more detailed
>>>> information while loading user-specified classes (e.g. the
>>>> one OpenJDK is failing to load). Some debug information is
>>>> available while the loading is in-progress, and more is
>>>> available after the fact, but it seems there is not a way
>>>> to monitor what the ClassLoaders are actually doing without
>>>> the use of debugging tools.
>>>>
>>>> For your approval: a formal write-up of the problem (as
>>>> I understand it), and a draft webrev containing the
>>>> proposed solution.
>>>>
>>>> Tests will be developed and added if/when the issue is
>>>> accepted as a problem, and a solution has been selected.
>>>>
>>>> Please review and opine.
>>>>
>>>> Bug: https://urldefense.proofpoint.com/v2/url?
>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232773&d=DwICaQ&c=jf_iaSHvJObTbx- 
>>
>>> siA1ZOg&r=P5m8KWUXJf-
>>>
>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=WEfc_wG4s2o_lhOKcZOykIG0RNybBiMMVbKIzmrlY3k&e= 
>>
>>>> Webrev: https://urldefense.proofpoint.com/v2/url?
>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8232773_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx- 
>>
>>> siA1ZOg&r=P5m8KWUXJf-
>>>
>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=jDSMDaCpBBZcYMU- 
>>
>>> IUqDh8PoCyl1Jk1G-QGIPKGjgeY&e=
>>>> Thanks for your time. :)
>>>>
>>>> Best Regards
>>>>
>>>> Adam Farley
>>>> IBM Runtimes
>>>>
>>>>
>>>> Unless stated otherwise above:
>>>> IBM United Kingdom Limited - Registered in England and Wales with
>> number
>>>> 741598.
>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>> 3AU
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
>> 3AU
>>
> 

From mandy.chung at oracle.com  Tue Oct 22 23:30:52 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 22 Oct 2019 16:30:52 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191022153738.224816243@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <a26a4f81-f923-06f2-a118-84dd0d09a4cf@oracle.com>
 <20191022153738.224816243@eggemoggin.niobe.net>
Message-ID: <1934b0f7-10a9-7374-a479-31087363db75@oracle.com>

On 10/22/19 3:37 PM, mark.reinhold at oracle.com wrote:
> 2019/10/22 14:12:18 -0700, mandy.chung at oracle.com:
>> On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote:
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
>>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
>> Looks good to me. One minor comment:
>>
>> AddResourcePlugin isn't really a FILTER, probably best to add a new
>> category for new resource file. jlink hardcodes the order of the
>> categories that determines the order of the plugins to be executed (I
>> see the existing implementation could be cleaned up in the future).  I
>> think we didn't want to the options resource to be filtered by
>> --exclude-resources plugin and so the add-options plugin should run
>> after all filter plugins.
> Good point -- that makes sense.
>
> Relative patch below; original webrev updated in place.

Looks good.

Mandy


From Alan.Bateman at oracle.com  Wed Oct 23 07:25:17 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Oct 2019 08:25:17 +0100
Subject: 8205132: Remove Thread.countStackFrames()
Message-ID: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>


Thread::countStackFrames has been deprecated for 20+ years and has been 
marked for-removal since Java SE 9. I'd like to remove it for Java SE 
14. It's was never a well-defined method and I've been unable to find 
anything that uses it. The StackWalker API is a much better solution for 
code that is interested in the number of stack frames.

The changes to remove this method are here:
 ?? http://cr.openjdk.java.net/~alanb/8205132/webrev/

The CSR will need a Reviewer:
 ?? https://bugs.openjdk.java.net/browse/JDK-8232654

-Alan

From fujie at loongson.cn  Wed Oct 23 07:16:57 2019
From: fujie at loongson.cn (Jie Fu)
Date: Wed, 23 Oct 2019 15:16:57 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are
 not reproducable
Message-ID: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>

Hi all,

JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232864
Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/

To find out how to reproduce this bug, please refer to the JBS.

To keep things sorted in a deterministic order, current implementation 
seems to be dependent on a default trace file [1] 
(default_jli_trace.txt, which is generated during building the jdk image 
[2]).
However, not all images will generate such a trace file.
For example, when cds is disabled, default_jli_trace.txt won't be 
generated at all.
If the trace file doesn't exist, classes generated by 
GenerateJLIClassesPlugin.java will not be sorted in a deterministic order.

Testing:
 ?- make test TEST="tier1 tier2 tier3" CONF=server-release

Could you please review it and give me some advice?

Thanks a lot.
Best regards,
Jie

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/70e6b0d8db13/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java#l58
[2] 
http://hg.openjdk.java.net/jdk/jdk/file/70e6b0d8db13/make/GenerateLinkOptData.gmk#l54



From Alan.Bateman at oracle.com  Wed Oct 23 07:57:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Oct 2019 08:57:18 +0100
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
Message-ID: <3e455b03-4383-10eb-8613-2ac1fd364449@oracle.com>

On 23/10/2019 08:16, Jie Fu wrote:
> Hi all,
>
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232864
> Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/
>
> To find out how to reproduce this bug, please refer to the JBS.
>
> To keep things sorted in a deterministic order, current implementation 
> seems to be dependent on a default trace file [1] 
> (default_jli_trace.txt, which is generated during building the jdk 
> image [2]).
> However, not all images will generate such a trace file.
> For example, when cds is disabled, default_jli_trace.txt won't be 
> generated at all.
> If the trace file doesn't exist, classes generated by 
> GenerateJLIClassesPlugin.java will not be sorted in a deterministic order.
JLinkReproducibleTest is the test to check that jlink creates 
reproducable images. Would this test have caught this if it were run 
with CDS disables? I'm just wondering if we need to add more run modes.

-Alan


From chris.hegarty at oracle.com  Wed Oct 23 09:15:51 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 23 Oct 2019 10:15:51 +0100
Subject: 8231602: Deprecate Thread.suspend/resume for removal
In-Reply-To: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>
References: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>
Message-ID: <E5D697CF-3B68-42BE-892E-CE3D897C0DF6@oracle.com>


> On 22 Oct 2019, at 19:25, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> ...
> Here's the webrev with the changes to deprecate-for-removal Thread.suspend/resume, ThreadGroup.suspend/resume, and ThreadGroup.allowThreadSuspsion:
>    http://cr.openjdk.java.net/~alanb/8231602/webrev/index.html


This look ok.

The CSR makes reference to Project Loom. I assume that this advancement
effort of ordinarily deprecated methods to terminally deprecated
methods, is in part, related to the recent discussion on loom-dev [1]:

  "The Thread API does come with baggage (ThreadGroup, TCCL, ...) but it
   may not be too bad when you consider that most developers don't use
   the Thread API directly. In addition, we can degrade and/or eliminate
   at least some of this baggage over time, starting with the deprecated
   features."

While orthogonal to this JIRA issue, 8231602 says: "It's time to dial
this up to forRemoval=true so these methods can be removed in a future
release." - Is there a planned release where these methods will be
removed? If so, what is that release?

-Chris.

[1] https://mail.openjdk.java.net/pipermail/loom-dev/2019-October/000796.html


From Alan.Bateman at oracle.com  Wed Oct 23 09:34:32 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Oct 2019 10:34:32 +0100
Subject: 8231602: Deprecate Thread.suspend/resume for removal
In-Reply-To: <E5D697CF-3B68-42BE-892E-CE3D897C0DF6@oracle.com>
References: <7419276f-f7de-3e10-0bcd-e0a97b7b5f49@oracle.com>
 <E5D697CF-3B68-42BE-892E-CE3D897C0DF6@oracle.com>
Message-ID: <6eaf98ac-e294-6b60-098a-aa986b2c6ddb@oracle.com>

On 23/10/2019 10:15, Chris Hegarty wrote:
> :
> While orthogonal to this JIRA issue, 8231602 says: "It's time to dial
> this up to forRemoval=true so these methods can be removed in a future
> release." - Is there a planned release where these methods will be
> removed? If so, what is that release?
>
TBD. We probably should have marked these methods for removal when the 
opportunity first arose in Java SE 9.

-Alan

From fujie at loongson.cn  Wed Oct 23 09:52:33 2019
From: fujie at loongson.cn (Jie Fu)
Date: Wed, 23 Oct 2019 17:52:33 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <3e455b03-4383-10eb-8613-2ac1fd364449@oracle.com>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <3e455b03-4383-10eb-8613-2ac1fd364449@oracle.com>
Message-ID: <c898d343-e79e-b00c-39b3-a26a83242605@loongson.cn>

Hi Alan,

Thanks for looking at this.

On 2019/10/23 ??3:57, Alan Bateman wrote:
> Would this test have caught this if it were run with CDS disables? 

Yes. This bug was found while we were debugging the CDS feature on our 
mips platform.


> I'm just wondering if we need to add more run modes. 

Glad to hear that.

Thanks a lot.
Best regards,
Jie


From chris.hegarty at oracle.com  Wed Oct 23 10:02:49 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 23 Oct 2019 11:02:49 +0100
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
Message-ID: <833EED24-5DA9-45F0-B72D-31C9BB340320@oracle.com>


> On 23 Oct 2019, at 08:25, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> Thread::countStackFrames has been deprecated for 20+ years and has been marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. It's was never a well-defined method and I've been unable to find anything that uses it. The StackWalker API is a much better solution for code that is interested in the number of stack frames.
> 
> The changes to remove this method are here:
>    http://cr.openjdk.java.net/~alanb/8205132/webrev/

Looks good to me.

Given that Java SE 9 released on 21st September 2017, and there has been Java SE 10, 11, 12, and 13, since then. I think it is reasonable to remove this particular method now, in Java SE 14.

> The CSR will need a Reviewer:
>    https://bugs.openjdk.java.net/browse/JDK-8232654

I?ve added myself as reviewer.

-Chris.

From claes.redestad at oracle.com  Wed Oct 23 10:49:12 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 23 Oct 2019 12:49:12 +0200
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
Message-ID: <f78414b6-8889-aa40-93c5-21ab71b77598@oracle.com>

Hi,

ideally the build step to generate default_jli_trace.txt should be
done independently of where the CDS feature is compiled in, but the
fix looks good regardless.

/Claes

On 2019-10-23 09:16, Jie Fu wrote:
> Hi all,
> 
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232864
> Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/
> 
> To find out how to reproduce this bug, please refer to the JBS.
> 
> To keep things sorted in a deterministic order, current implementation 
> seems to be dependent on a default trace file [1] 
> (default_jli_trace.txt, which is generated during building the jdk image 
> [2]).
> However, not all images will generate such a trace file.
> For example, when cds is disabled, default_jli_trace.txt won't be 
> generated at all.
> If the trace file doesn't exist, classes generated by 
> GenerateJLIClassesPlugin.java will not be sorted in a deterministic order.
> 
> Testing:
>  ?- make test TEST="tier1 tier2 tier3" CONF=server-release
> 
> Could you please review it and give me some advice?
> 
> Thanks a lot.
> Best regards,
> Jie
> 
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/70e6b0d8db13/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java#l58 
> 
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/file/70e6b0d8db13/make/GenerateLinkOptData.gmk#l54 
> 
> 
> 

From jai.forums2013 at gmail.com  Wed Oct 23 11:24:28 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 23 Oct 2019 16:54:28 +0530
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads
 to a CRC failure in the generated jar file
Message-ID: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>

Can I please get a review and a sponsor for a potential fix for
JDK-8232879[1]? The patch is available as a webrev at [2].

What's happening in there is that the
jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the
one arg write(byte b) method and calling the super.write(b) and then
doing a crc.update. The super.write(b)
(java.util.zip.DeflaterOutputStream in this case) actually internally
calls the 3 arg write(b, offset, length) which is overriding by this
jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream. In its
implementation of write(b, offset, length), in addition to (rightly)
calling super.write(b, offset, length), this method also updates the CRC
(again). So this ends up updating the CRC multiple times when the single
arg write is invoked.

The patch now removes this overridden implementation of write(b) in the
DeflatingEntryOutputStream so that the call is handled by the
java.util.zip.DeflaterOutputStream. Although there's no @implNote on
java.util.zip.DeflaterOutputStream#write(byte b) static that it's
(always) going to call the 3 arg write(b, offset, length) method, the
implementation as of now does indeed do that. So I guess, its probably
OK to rely on that knowledge and get rid of this overridden write(b)
method instead of coming up with a bit more complicated fix.

The patch also includes a jtreg testcase which reproduces this issues
and verifies the fix.

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

[2] https://cr.openjdk.java.net/~jpai/webrev/8232879/1/webrev/

-Jaikiran



From david.holmes at oracle.com  Wed Oct 23 12:00:25 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Oct 2019 22:00:25 +1000
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
Message-ID: <aa7dd20a-18ef-63e9-921e-529a4c5beeb7@oracle.com>

Looks good Alan!

I'm guessing there may be a JCK update required somewhere to go with this.

Thanks,
David

On 23/10/2019 5:25 pm, Alan Bateman wrote:
> 
> Thread::countStackFrames has been deprecated for 20+ years and has been 
> marked for-removal since Java SE 9. I'd like to remove it for Java SE 
> 14. It's was never a well-defined method and I've been unable to find 
> anything that uses it. The StackWalker API is a much better solution for 
> code that is interested in the number of stack frames.
> 
> The changes to remove this method are here:
>  ?? http://cr.openjdk.java.net/~alanb/8205132/webrev/
> 
> The CSR will need a Reviewer:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8232654
> 
> -Alan

From christoph.langer at sap.com  Wed Oct 23 12:57:06 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 23 Oct 2019 12:57:06 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
Message-ID: <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi,

I've picked up Ralf's patch and cleaned it up a little bit. But apart from some comment changes it should be the same as his original version. So, what happens is that the windows 'canonicalize" function will only delegate to 'wcanonicalize' from now on.  Furthermore,  'canonicalizeWithPrefix' along with some auxiliary stuff could be removed completely.

Can I please get a review for this, as I'm planning on doing further cleanup around canonicalization.

New webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232168.0/

Thanks
Christoph

> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-
> bounces at openjdk.java.net> On Behalf Of Alan Bateman
> Sent: Freitag, 18. Oktober 2019 12:41
> To: Schmelter, Ralf <ralf.schmelter at sap.com>; David Holmes
> <david.holmes at oracle.com>; hotspot-runtime-dev at openjdk.java.net; Java
> Core Libs <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows
> 
> On 16/10/2019 09:28, Schmelter, Ralf wrote:
> > Hi David,
> >
> > the canonicalize() method is never used by java.io or any Java code.
> Currently it is used by the hotspot in classloader.cpp (which I use in the test)
> and in libinstrument in InvocationAdapter.c. There is no way to test it in core-
> libs. One can argue if the canonicalize method is in the right file, but that
> should be a separate discussion.
> >
> I plan to review this, I just haven't had time yet. You are right that
> there is technical debt here, include dependency in the JPLIS agent
> which crept in when java.lang.instrument was updated to support
> augmenting of the boot class path.
> 
> -Alan

From Alan.Bateman at oracle.com  Wed Oct 23 13:16:23 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Oct 2019 14:16:23 +0100
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <371cf47e-476b-8a1d-b466-a0acbae158f8@oracle.com>

On 23/10/2019 13:57, Langer, Christoph wrote:
> Hi,
>
> I've picked up Ralf's patch and cleaned it up a little bit. But apart from some comment changes it should be the same as his original version. So, what happens is that the windows 'canonicalize" function will only delegate to 'wcanonicalize' from now on.  Furthermore,  'canonicalizeWithPrefix' along with some auxiliary stuff could be removed completely.
>
> Can I please get a review for this, as I'm planning on doing further cleanup around canonicalization.
>
I have this on my list to look at. I think we'll need to figure out a 
path to separate the usages (the JPLIS agent usage is technical debt, we 
should have addressed that issue a long time ago).

-Alan

From andy.herrick at oracle.com  Wed Oct 23 13:25:43 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 23 Oct 2019 09:25:43 -0400
Subject: RFR: JDK-8232723: make the resource file main.wxs over-ridable
In-Reply-To: <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>
References: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>
 <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>
Message-ID: <8b738391-d67b-2ad3-0a43-c508f7a438dd@oracle.com>

revised to add test webrev.02 at [3]

[3] http://cr.openjdk.java.net/~herrick/8232723/webrev.02

/Andy

On 10/22/2019 2:57 PM, Alexey Semenyuk wrote:
> Looks good.
>
> It would be good to have a test for this change as a part of this fix 
> or as a follow up CR.
>
> - Alexey
>
> On 10/22/2019 2:50 PM, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> use createResource() to get an over-ridable resource.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232723
>>
>> [2] http://cr.openjdk.java.net/~herrick/8232723/webrev.01
>>
>> /Andy
>>
>

From christoph.langer at sap.com  Wed Oct 23 13:26:16 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 23 Oct 2019 13:26:16 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <371cf47e-476b-8a1d-b466-a0acbae158f8@oracle.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <371cf47e-476b-8a1d-b466-a0acbae158f8@oracle.com>
Message-ID: <AM6PR02MB48013938E41FEB97A8FCD5028A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Alan,

> I have this on my list to look at. I think we'll need to figure out a
> path to separate the usages (the JPLIS agent usage is technical debt, we
> should have addressed that issue a long time ago).

I agree that it's a good thing to explore how the different usages of calls to canonicalize could be disentangled. However, can't we defer that to another item? This one seems like a straightforward bugfix to me, with some cleanup attached. And I've prepared some more cleanup in that area already which is dependent on this fix - so I'd appreciate if this wouldn't be procrastinated too much :) 

Thanks
Christoph


From daniel.daugherty at oracle.com  Wed Oct 23 14:34:32 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 23 Oct 2019 10:34:32 -0400
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
Message-ID: <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>

On 10/23/19 3:25 AM, Alan Bateman wrote:
>
> Thread::countStackFrames has been deprecated for 20+ years and has 
> been marked for-removal since Java SE 9. I'd like to remove it for 
> Java SE 14. It's was never a well-defined method and I've been unable 
> to find anything that uses it. The StackWalker API is a much better 
> solution for code that is interested in the number of stack frames.
>
> The changes to remove this method are here:
> ?? http://cr.openjdk.java.net/~alanb/8205132/webrev/

make/hotspot/symbols/symbols-unix
 ??? No comments.

src/hotspot/share/include/jvm.h
 ??? No comments.

src/hotspot/share/prims/jvm.cpp
 ??? No comments.

src/java.base/share/classes/java/lang/Thread.java
 ??? No comments.

src/java.base/share/native/libjava/Thread.c
 ??? No comments.

test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java
 ??? No comments.

Thumbs up.

Dan


>
> The CSR will need a Reviewer:
> ?? https://bugs.openjdk.java.net/browse/JDK-8232654
>
> -Alan


From seth.lytle at gmail.com  Wed Oct 23 15:25:53 2019
From: seth.lytle at gmail.com (seth lytle)
Date: Wed, 23 Oct 2019 11:25:53 -0400
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
Message-ID: <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>

With respect to "unable to find anything that uses it", a quick search
of the code that I have access to shows some usage, though everything
I looked at in any depth is either a test or a proxy, so there will be
source code changes required. I've never thought about what the right
way to handle proxying a deprecated method is.

I've wanted to use it a couple times - if it was fast and
approximately accurate, it would be useful. As it's been deprecated,
I've never investigated whether the those assumptions are true.




On Wed, Oct 23, 2019 at 10:34 AM Daniel D. Daugherty
<daniel.daugherty at oracle.com> wrote:
>
> On 10/23/19 3:25 AM, Alan Bateman wrote:
> >
> > Thread::countStackFrames has been deprecated for 20+ years and has
> > been marked for-removal since Java SE 9. I'd like to remove it for
> > Java SE 14. It's was never a well-defined method and I've been unable
> > to find anything that uses it. The StackWalker API is a much better
> > solution for code that is interested in the number of stack frames.
> >
> > The changes to remove this method are here:
> >    http://cr.openjdk.java.net/~alanb/8205132/webrev/
>
> make/hotspot/symbols/symbols-unix
>      No comments.
>
> src/hotspot/share/include/jvm.h
>      No comments.
>
> src/hotspot/share/prims/jvm.cpp
>      No comments.
>
> src/java.base/share/classes/java/lang/Thread.java
>      No comments.
>
> src/java.base/share/native/libjava/Thread.c
>      No comments.
>
> test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java
>      No comments.
>
> Thumbs up.
>
> Dan
>
>
> >
> > The CSR will need a Reviewer:
> >    https://bugs.openjdk.java.net/browse/JDK-8232654
> >
> > -Alan
>

From Alan.Bateman at oracle.com  Wed Oct 23 15:57:56 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Oct 2019 16:57:56 +0100
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
 <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
Message-ID: <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>

On 23/10/2019 16:25, seth lytle wrote:
> With respect to "unable to find anything that uses it", a quick search
> of the code that I have access to shows some usage, though everything
> I looked at in any depth is either a test or a proxy, so there will be
> source code changes required. I've never thought about what the right
> way to handle proxying a deprecated method is.
>
Is this maintained code (or tests)? I find it hard to see how anything 
could depend on it. The deprecated warning has been there since 1998, 
the for-removal warning since JDK 9, so I assume the warnings are being 
ignored.

-Alan

From andy.herrick at oracle.com  Wed Oct 23 17:07:08 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 23 Oct 2019 13:07:08 -0400
Subject: RFR: JDK-8232186: Add verification for pkg and dmg tests
In-Reply-To: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>
References: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>
Message-ID: <2b6673e4-9b73-9e89-d46c-9bd0c7a72678@oracle.com>

looks ok to me

/ANdy

On 10/22/2019 5:29 PM, Alexander Matveev wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Removed --mac-app-store-category.
> - Added Hello.java test app to support file association on OS X.
> - Modified Hello.java to write output file to user home location if 
> working directory is not writable.
> - Fixed MacHelper:getInstallationDirectory(). It was returning extra 
> /Applications when --install-dir is specified.
> - Fixed SigningPackageTest to use path returned by withExplodedDmg 
> correctly.
> - Added install/uninstall support for pkg and dmg to manage_packages.sh.
> - Fixed replaceFileName(), otherwise on OS X it was not replacing file 
> name correctly, since file name does not have extension.
> - Added NameWithSpaceTest.
> - Removed OptionsTest which is covered by other tests.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232186
>
> [2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/
>
> Thanks,
> Alexander

From mandy.chung at oracle.com  Wed Oct 23 17:24:34 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 23 Oct 2019 10:24:34 -0700
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
Message-ID: <45c76eb9-9d4c-709a-16bf-9bd87a933616@oracle.com>



On 10/23/19 12:25 AM, Alan Bateman wrote:
>
> Thread::countStackFrames has been deprecated for 20+ years and has 
> been marked for-removal since Java SE 9. I'd like to remove it for 
> Java SE 14. It's was never a well-defined method and I've been unable 
> to find anything that uses it. The StackWalker API is a much better 
> solution for code that is interested in the number of stack frames.
>
> The changes to remove this method are here:
> ?? http://cr.openjdk.java.net/~alanb/8205132/webrev/
>

Looks good.

> The CSR will need a Reviewer:
> ?? https://bugs.openjdk.java.net/browse/JDK-8232654
>

Reviewed.

Mandy

From andy.herrick at oracle.com  Wed Oct 23 17:29:17 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 23 Oct 2019 13:29:17 -0400
Subject: RFR: JDK-8232723: make the resource file main.wxs over-ridable
In-Reply-To: <8b738391-d67b-2ad3-0a43-c508f7a438dd@oracle.com>
References: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>
 <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>
 <8b738391-d67b-2ad3-0a43-c508f7a438dd@oracle.com>
Message-ID: <f8805e62-3115-c8dc-3e66-362bcfbd0366@oracle.com>

revised test (webrev.03 [4]) as per feedback from Alexey.

[4] http://cr.openjdk.java.net/~herrick/8232723/webrev.03

/Andy

On 10/23/2019 9:25 AM, Andy Herrick wrote:
> revised to add test webrev.02 at [3]
>
> [3] http://cr.openjdk.java.net/~herrick/8232723/webrev.02
>
> /Andy
>
> On 10/22/2019 2:57 PM, Alexey Semenyuk wrote:
>> Looks good.
>>
>> It would be good to have a test for this change as a part of this fix 
>> or as a follow up CR.
>>
>> - Alexey
>>
>> On 10/22/2019 2:50 PM, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> use createResource() to get an over-ridable resource.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232723
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8232723/webrev.01
>>>
>>> /Andy
>>>
>>

From alexey.semenyuk at oracle.com  Wed Oct 23 17:35:32 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 23 Oct 2019 13:35:32 -0400
Subject: RFR: JDK-8232723: make the resource file main.wxs over-ridable
In-Reply-To: <f8805e62-3115-c8dc-3e66-362bcfbd0366@oracle.com>
References: <6d59b5cb-4f52-1e1f-8e6f-ae18b86b6e9f@oracle.com>
 <1f5788de-2426-c4bf-ebda-fec4bf1a7f64@oracle.com>
 <8b738391-d67b-2ad3-0a43-c508f7a438dd@oracle.com>
 <f8805e62-3115-c8dc-3e66-362bcfbd0366@oracle.com>
Message-ID: <1ed62dc1-32bc-7a60-0feb-8f2b250f5798@oracle.com>

Looks good.

- Alexey

On 10/23/2019 1:29 PM, Andy Herrick wrote:
> revised test (webrev.03 [4]) as per feedback from Alexey.
>
> [4] http://cr.openjdk.java.net/~herrick/8232723/webrev.03
>
> /Andy
>
> On 10/23/2019 9:25 AM, Andy Herrick wrote:
>> revised to add test webrev.02 at [3]
>>
>> [3] http://cr.openjdk.java.net/~herrick/8232723/webrev.02
>>
>> /Andy
>>
>> On 10/22/2019 2:57 PM, Alexey Semenyuk wrote:
>>> Looks good.
>>>
>>> It would be good to have a test for this change as a part of this 
>>> fix or as a follow up CR.
>>>
>>> - Alexey
>>>
>>> On 10/22/2019 2:50 PM, Andy Herrick wrote:
>>>> Please review the jpackage fix for bug [1] at [2].
>>>>
>>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>>> repository (jpackage).
>>>>
>>>> use createResource() to get an over-ridable resource.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232723
>>>>
>>>> [2] http://cr.openjdk.java.net/~herrick/8232723/webrev.01
>>>>
>>>> /Andy
>>>>
>>>


From lance.andersen at oracle.com  Wed Oct 23 18:06:59 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 23 Oct 2019 14:06:59 -0400
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <fe6bf497-b192-256b-8542-2face7386931@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
 <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>
 <fe6bf497-b192-256b-8542-2face7386931@oracle.com>
Message-ID: <2E75AAD1-960A-4D75-A400-88FEDBD1D38E@oracle.com>


> On Oct 22, 2019, at 2:37 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 22/10/2019 18:00, Lance Andersen wrote:
>> 
>> Per your suggestion, I tweaked the patch to move to BOF when the negative skip value goes beyond BOF.  I updated the release note as well.
>> 
>> webrev can be found at: http://cr.openjdk.java.net/~lancea/8231451/webrev.01/index.html
>> 
> I assume skip(Long.MAX_VALUE) will cause n+pos to overflow and it will skip backwards rather than to the end.

That is correct.  If you prefer it to skip to the end, I will adjust accordingly.
> It might be simpler to read/audit if you separate the negative skip case.
I can do that as well.

Best
Lance
> 
> -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 calvin.cheung at oracle.com  Wed Oct 23 18:21:03 2019
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 23 Oct 2019 11:21:03 -0700
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <7851ceb0-2dba-4749-5ed8-c91404d2fae2@oracle.com>

Hi Christoph,

The changes look good.

I agree that other mentioned items (the JPLIS agent usage and moving the 
canonicalize function into hotspot) could be done in separate RFEs.

thanks,

Calvin

On 10/23/19 5:57 AM, Langer, Christoph wrote:
> Hi,
>
> I've picked up Ralf's patch and cleaned it up a little bit. But apart from some comment changes it should be the same as his original version. So, what happens is that the windows 'canonicalize" function will only delegate to 'wcanonicalize' from now on.  Furthermore,  'canonicalizeWithPrefix' along with some auxiliary stuff could be removed completely.
>
> Can I please get a review for this, as I'm planning on doing further cleanup around canonicalization.
>
> New webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232168.0/
>
> Thanks
> Christoph
>
>> -----Original Message-----
>> From: hotspot-runtime-dev <hotspot-runtime-dev-
>> bounces at openjdk.java.net> On Behalf Of Alan Bateman
>> Sent: Freitag, 18. Oktober 2019 12:41
>> To: Schmelter, Ralf <ralf.schmelter at sap.com>; David Holmes
>> <david.holmes at oracle.com>; hotspot-runtime-dev at openjdk.java.net; Java
>> Core Libs <core-libs-dev at openjdk.java.net>
>> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows
>>
>> On 16/10/2019 09:28, Schmelter, Ralf wrote:
>>> Hi David,
>>>
>>> the canonicalize() method is never used by java.io or any Java code.
>> Currently it is used by the hotspot in classloader.cpp (which I use in the test)
>> and in libinstrument in InvocationAdapter.c. There is no way to test it in core-
>> libs. One can argue if the canonicalize method is in the right file, but that
>> should be a separate discussion.
>> I plan to review this, I just haven't had time yet. You are right that
>> there is technical debt here, include dependency in the JPLIS agent
>> which crept in when java.lang.instrument was updated to support
>> augmenting of the boot class path.
>>
>> -Alan

From mandy.chung at oracle.com  Wed Oct 23 18:37:49 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 23 Oct 2019 11:37:49 -0700
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
Message-ID: <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>



On 10/23/19 12:16 AM, Jie Fu wrote:
> Hi all,
>
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232864
> Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/
>
speciesTypes, invokerTypes, callSiteTypes and dmhMethods are sorted
when the trace config is present (done in readTraceConfig).

An alternative to (re)sort the collections in the transform method
is to refactor initialize and readTraceConfig methods such that
these collections are ensured sorted (maybe consider adding
a builder class).

Can you also extend JLinkReproducibleTest to add the case when
the default trace config is not present?

Mandy



From mark.reinhold at oracle.com  Wed Oct 23 19:07:11 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 23 Oct 2019 12:07:11 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191022153628.417897318@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
 <20191022122232.395077958@eggemoggin.niobe.net>
 <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>
 <20191022153628.417897318@eggemoggin.niobe.net>
Message-ID: <20191023120711.232005374@eggemoggin.niobe.net>

2019/10/22 15:36:28 -0700, mark.reinhold at oracle.com:
> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com:
>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote:
>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com:
>>>> In arguments.cpp, could you use a new JVMFlag to declare options
>>>> that came from this resource as RESOURCE?
>>>> 
>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);
>>>> 
>>>> This will require some minor changes to jvmFlags.hpp
>>>> 
>>>> ...
>>> 
>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin
>>> to handle the RESOURCE case (which is easy).
>>> 
>>> Is ?RESOURCE? the best name here?  Sounds awfully generic.  How about
>>> ?JIMAGE? or ?JIMAGE_RESOURCE??
>> 
>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.
> 
> JIMAGE_RESOURCE it is, then.  Relative patch below; original webrev
> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/).

Addendum: To keep things sane for JFR and the serviceability agent,
I had to propagate this change through to those subsystems.

Relative patch below; original webrev updated in place
(https://cr.openjdk.java.net/~mr/rev/8232080/).

Okay?

- Mark

----

# HG changeset patch
# Parent  d3f05e3b0d76e1a74a10cee180d8953d3045b6c8
Addendum 3 (propagate JIMAGE_RESOURCE): 8232080: jlink plugins for vendor information and run-time options

diff --git a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
--- a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
+++ b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
@@ -134,6 +134,7 @@
     case JVMFlag::ERGONOMIC: return "Ergonomic";
     case JVMFlag::ATTACH_ON_DEMAND: return "Attach on demand";
     case JVMFlag::INTERNAL: return "Internal";
+    case JVMFlag::JIMAGE_RESOURCE: return "JImage resource";
     default: ShouldNotReachHere(); return "";
   }
 }
diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
--- a/src/hotspot/share/runtime/vmStructs.cpp
+++ b/src/hotspot/share/runtime/vmStructs.cpp
@@ -2612,6 +2612,7 @@
   declare_constant(JVMFlag::ERGONOMIC)                                    \
   declare_constant(JVMFlag::ATTACH_ON_DEMAND)                             \
   declare_constant(JVMFlag::INTERNAL)                                     \
+  declare_constant(JVMFlag::JIMAGE_RESOURCE)                              \
   declare_constant(JVMFlag::VALUE_ORIGIN_MASK)                            \
   declare_constant(JVMFlag::ORIG_COMMAND_LINE)
 
diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
@@ -35,7 +35,8 @@
   MANAGEMENT ("Management"),
   ERGONOMIC ("Ergonomic"),
   ATTACH_ON_DEMAND ("Attach on demand"),
-  INTERNAL ("Internal");
+  INTERNAL ("Internal"),
+  JIMAGE_RESOURCE ("JImage");
 
   private final String value;
 
diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
@@ -114,6 +114,7 @@
   public static int    Flags_ERGONOMIC;
   public static int    Flags_ATTACH_ON_DEMAND;
   public static int    Flags_INTERNAL;
+  public static int    Flags_JIMAGE_RESOURCE;
   private static int   Flags_VALUE_ORIGIN_MASK;
   private static int   Flags_ORIG_COMMAND_LINE;
   /** This is only present in a non-core build */
@@ -200,6 +201,8 @@
             return "attach";
         } else if (origin == Flags_INTERNAL) {
             return "internal";
+        } else if (origin == Flags_JIMAGE_RESOURCE) {
+            return "jimage";
         } else {
             throw new IllegalStateException(
                 "Unknown flag origin " + origin + " is detected in " + name);
@@ -484,6 +487,7 @@
     Flags_ERGONOMIC = db.lookupIntConstant("JVMFlag::ERGONOMIC").intValue();
     Flags_ATTACH_ON_DEMAND = db.lookupIntConstant("JVMFlag::ATTACH_ON_DEMAND").intValue();
     Flags_INTERNAL = db.lookupIntConstant("JVMFlag::INTERNAL").intValue();
+    Flags_JIMAGE_RESOURCE = db.lookupIntConstant("JVMFlag::JIMAGE").intValue();
     Flags_VALUE_ORIGIN_MASK = db.lookupIntConstant("JVMFlag::VALUE_ORIGIN_MASK").intValue();
     Flags_ORIG_COMMAND_LINE = db.lookupIntConstant("JVMFlag::ORIG_COMMAND_LINE").intValue();
     oopSize  = db.lookupIntConstant("oopSize").intValue();

From bob.vandette at oracle.com  Wed Oct 23 19:37:56 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 23 Oct 2019 15:37:56 -0400
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <20191023120711.232005374@eggemoggin.niobe.net>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
 <20191022122232.395077958@eggemoggin.niobe.net>
 <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>
 <20191022153628.417897318@eggemoggin.niobe.net>
 <20191023120711.232005374@eggemoggin.niobe.net>
Message-ID: <A00CFD08-A726-478C-8A78-1E963D479996@oracle.com>



> On Oct 23, 2019, at 3:07 PM, mark.reinhold at oracle.com wrote:
> 
> 2019/10/22 15:36:28 -0700, mark.reinhold at oracle.com:
>> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com:
>>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote:
>>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com:
>>>>> In arguments.cpp, could you use a new JVMFlag to declare options
>>>>> that came from this resource as RESOURCE?
>>>>> 
>>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL);
>>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE);
>>>>> 
>>>>> This will require some minor changes to jvmFlags.hpp
>>>>> 
>>>>> ...
>>>> 
>>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin
>>>> to handle the RESOURCE case (which is easy).
>>>> 
>>>> Is ?RESOURCE? the best name here?  Sounds awfully generic.  How about
>>>> ?JIMAGE? or ?JIMAGE_RESOURCE??
>>> 
>>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE  works for me.
>> 
>> JIMAGE_RESOURCE it is, then.  Relative patch below; original webrev
>> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/).
> 
> Addendum: To keep things sane for JFR and the serviceability agent,
> I had to propagate this change through to those subsystems.
> 
> Relative patch below; original webrev updated in place
> (https://cr.openjdk.java.net/~mr/rev/8232080/).
> 
> Okay?

Looks good.  I?m sure you did this but I scanned the entire JDK sources and didn?t see any other uses of JVMFlag:: that would need to be updated.

Bob.


> 
> - Mark
> 
> ----
> 
> # HG changeset patch
> # Parent  d3f05e3b0d76e1a74a10cee180d8953d3045b6c8
> Addendum 3 (propagate JIMAGE_RESOURCE): 8232080: jlink plugins for vendor information and run-time options
> 
> diff --git a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
> --- a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
> +++ b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
> @@ -134,6 +134,7 @@
>     case JVMFlag::ERGONOMIC: return "Ergonomic";
>     case JVMFlag::ATTACH_ON_DEMAND: return "Attach on demand";
>     case JVMFlag::INTERNAL: return "Internal";
> +    case JVMFlag::JIMAGE_RESOURCE: return "JImage resource";
>     default: ShouldNotReachHere(); return "";
>   }
> }
> diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
> --- a/src/hotspot/share/runtime/vmStructs.cpp
> +++ b/src/hotspot/share/runtime/vmStructs.cpp
> @@ -2612,6 +2612,7 @@
>   declare_constant(JVMFlag::ERGONOMIC)                                    \
>   declare_constant(JVMFlag::ATTACH_ON_DEMAND)                             \
>   declare_constant(JVMFlag::INTERNAL)                                     \
> +  declare_constant(JVMFlag::JIMAGE_RESOURCE)                              \
>   declare_constant(JVMFlag::VALUE_ORIGIN_MASK)                            \
>   declare_constant(JVMFlag::ORIG_COMMAND_LINE)
> 
> diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
> --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
> +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java
> @@ -35,7 +35,8 @@
>   MANAGEMENT ("Management"),
>   ERGONOMIC ("Ergonomic"),
>   ATTACH_ON_DEMAND ("Attach on demand"),
> -  INTERNAL ("Internal");
> +  INTERNAL ("Internal"),
> +  JIMAGE_RESOURCE ("JImage");
> 
>   private final String value;
> 
> diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
> --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
> +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
> @@ -114,6 +114,7 @@
>   public static int    Flags_ERGONOMIC;
>   public static int    Flags_ATTACH_ON_DEMAND;
>   public static int    Flags_INTERNAL;
> +  public static int    Flags_JIMAGE_RESOURCE;
>   private static int   Flags_VALUE_ORIGIN_MASK;
>   private static int   Flags_ORIG_COMMAND_LINE;
>   /** This is only present in a non-core build */
> @@ -200,6 +201,8 @@
>             return "attach";
>         } else if (origin == Flags_INTERNAL) {
>             return "internal";
> +        } else if (origin == Flags_JIMAGE_RESOURCE) {
> +            return "jimage";
>         } else {
>             throw new IllegalStateException(
>                 "Unknown flag origin " + origin + " is detected in " + name);
> @@ -484,6 +487,7 @@
>     Flags_ERGONOMIC = db.lookupIntConstant("JVMFlag::ERGONOMIC").intValue();
>     Flags_ATTACH_ON_DEMAND = db.lookupIntConstant("JVMFlag::ATTACH_ON_DEMAND").intValue();
>     Flags_INTERNAL = db.lookupIntConstant("JVMFlag::INTERNAL").intValue();
> +    Flags_JIMAGE_RESOURCE = db.lookupIntConstant("JVMFlag::JIMAGE").intValue();
>     Flags_VALUE_ORIGIN_MASK = db.lookupIntConstant("JVMFlag::VALUE_ORIGIN_MASK").intValue();
>     Flags_ORIG_COMMAND_LINE = db.lookupIntConstant("JVMFlag::ORIG_COMMAND_LINE").intValue();
>     oopSize  = db.lookupIntConstant("oopSize").intValue();


From lance.andersen at oracle.com  Wed Oct 23 19:47:51 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 23 Oct 2019 15:47:51 -0400
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
Message-ID: <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>

Hi Jaikiran,

I will take a look and once we are good with the review, I can sponsor it.

Best
Lance
> On Oct 23, 2019, at 7:24 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Can I please get a review and a sponsor for a potential fix for
> JDK-8232879[1]? The patch is available as a webrev at [2].
> 
> What's happening in there is that the
> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the
> one arg write(byte b) method and calling the super.write(b) and then
> doing a crc.update. The super.write(b)
> (java.util.zip.DeflaterOutputStream in this case) actually internally
> calls the 3 arg write(b, offset, length) which is overriding by this
> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream. In its
> implementation of write(b, offset, length), in addition to (rightly)
> calling super.write(b, offset, length), this method also updates the CRC
> (again). So this ends up updating the CRC multiple times when the single
> arg write is invoked.
> 
> The patch now removes this overridden implementation of write(b) in the
> DeflatingEntryOutputStream so that the call is handled by the
> java.util.zip.DeflaterOutputStream. Although there's no @implNote on
> java.util.zip.DeflaterOutputStream#write(byte b) static that it's
> (always) going to call the 3 arg write(b, offset, length) method, the
> implementation as of now does indeed do that. So I guess, its probably
> OK to rely on that knowledge and get rid of this overridden write(b)
> method instead of coming up with a bit more complicated fix.
> 
> The patch also includes a jtreg testcase which reproduces this issues
> and verifies the fix.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8232879
> 
> [2] https://cr.openjdk.java.net/~jpai/webrev/8232879/1/webrev/
> 
> -Jaikiran
> 
> 

 <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 mark.reinhold at oracle.com  Wed Oct 23 20:25:52 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 23 Oct 2019 13:25:52 -0700
Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and
 run-time options
In-Reply-To: <A00CFD08-A726-478C-8A78-1E963D479996@oracle.com>
References: <20191021202253.825695282@eggemoggin.niobe.net>
 <EED99FD2-8191-40D8-B60A-45396E1F0006@oracle.com>
 <20191022122232.395077958@eggemoggin.niobe.net>
 <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com>
 <20191022153628.417897318@eggemoggin.niobe.net>
 <20191023120711.232005374@eggemoggin.niobe.net>
 <A00CFD08-A726-478C-8A78-1E963D479996@oracle.com>
Message-ID: <20191023132552.159905052@eggemoggin.niobe.net>

2019/10/23 12:37:56 -0700, bob.vandette at oracle.com:
>> On Oct 23, 2019, at 3:07 PM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> Addendum: To keep things sane for JFR and the serviceability agent,
>> I had to propagate this change through to those subsystems.
>> 
>> Relative patch below; original webrev updated in place
>> (https://cr.openjdk.java.net/~mr/rev/8232080/).
>> 
>> Okay?
> 
> Looks good.  I?m sure you did this but I scanned the entire JDK
> sources and didn?t see any other uses of JVMFlag:: that would need to
> be updated.

Yep, I did that, and didn?t see anything else either.

Thanks,
- Mark

From Alan.Bateman at oracle.com  Wed Oct 23 20:58:01 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Oct 2019 21:58:01 +0100
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <2E75AAD1-960A-4D75-A400-88FEDBD1D38E@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
 <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>
 <fe6bf497-b192-256b-8542-2face7386931@oracle.com>
 <2E75AAD1-960A-4D75-A400-88FEDBD1D38E@oracle.com>
Message-ID: <e9ac1780-d5f9-aad9-31f2-c5b2b191c162@oracle.com>

On 23/10/2019 19:06, Lance Andersen wrote:
>
>> On Oct 22, 2019, at 2:37 PM, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>> I assume skip(Long.MAX_VALUE) will cause n+pos to overflow and it 
>> will skip backwards rather than to the end.
>
> That is correct. ?If you prefer it to skip to the end, I will adjust 
> accordingly.
It would be surprising to specify a positive value and have it skip 
backwards so I think this should be fixed.

-Alan

From peter.levart at gmail.com  Wed Oct 23 21:09:54 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 23 Oct 2019 23:09:54 +0200
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <OF700BE5C9.50229F68-ON49258490.0037CB9A-49258490.00388773@notes.na.collabserv.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <14b28640-cd16-c672-c4bb-754116e882da@gmail.com>
 <OF700BE5C9.50229F68-ON49258490.0037CB9A-49258490.00388773@notes.na.collabserv.com>
Message-ID: <caf652eb-ed8d-ca93-b4a6-add1e6d46d56@gmail.com>

Hi Ogata,

I finally managed to find some time to experiment with this. To measure 
invocation performance I created the following JMH benchmark [1]. It 
measures the invocation speed of instance and static methods using either:
- direct invocation (bytecodes)
- invocation via constant Method instance
- invocation via variable Method instance

Here are the results using unmodified JDK 14 build (baseline):

Benchmark???????????????????????????????????????? Mode? Cnt Score?? 
Error? Units
ReflectionSpeedBenchmark.instanceDirect?????????? avgt?? 10?? 2.272 ? 
0.002? ns/op
ReflectionSpeedBenchmark.instanceReflectiveConst? avgt?? 10? 16.609 ? 
0.162? ns/op
ReflectionSpeedBenchmark.instanceReflectiveVar??? avgt?? 10? 16.715 ? 
0.163? ns/op
ReflectionSpeedBenchmark.staticDirect???????????? avgt?? 10?? 2.275 ? 
0.012? ns/op
ReflectionSpeedBenchmark.staticReflectiveConst??? avgt?? 10? 16.351 ? 
0.330? ns/op
ReflectionSpeedBenchmark.staticReflectiveVar????? avgt?? 10? 16.259 ? 
0.196? ns/op

Your webrev.04 [2] has a slight (~ 6%) improvement for constant Method 
instance (i.e. assigned to static final field):

Benchmark???????????????????????????????????????? Mode? Cnt Score?? 
Error? Units
ReflectionSpeedBenchmark.instanceDirect?????????? avgt?? 10?? 2.273 ? 
0.003? ns/op
ReflectionSpeedBenchmark.instanceReflectiveConst? avgt?? 10? 15.628 ? 
0.115? ns/op
ReflectionSpeedBenchmark.instanceReflectiveVar??? avgt?? 10? 16.706 ? 
0.144? ns/op
ReflectionSpeedBenchmark.staticDirect???????????? avgt?? 10?? 2.277 ? 
0.008? ns/op
ReflectionSpeedBenchmark.staticReflectiveConst??? avgt?? 10? 15.285 ? 
0.109? ns/op
ReflectionSpeedBenchmark.staticReflectiveVar????? avgt?? 10? 16.600 ? 
0.222? ns/op

Now I have prepared another variant [3] that replaces 
DelegatingMethodAccessorImpl with SlowFastMethodAccessorImpl and 
produces the following result:

Benchmark???????????????????????????????????????? Mode? Cnt Score?? 
Error? Units
ReflectionSpeedBenchmark.instanceDirect?????????? avgt?? 10?? 2.371 ? 
0.027? ns/op
ReflectionSpeedBenchmark.instanceReflectiveConst? avgt?? 10?? 7.161 ? 
0.066? ns/op
ReflectionSpeedBenchmark.instanceReflectiveVar??? avgt?? 10? 16.501 ? 
0.154? ns/op
ReflectionSpeedBenchmark.staticDirect???????????? avgt?? 10?? 2.373 ? 
0.017? ns/op
ReflectionSpeedBenchmark.staticReflectiveConst??? avgt?? 10?? 6.971 ? 
0.103? ns/op
ReflectionSpeedBenchmark.staticReflectiveVar????? avgt?? 10? 15.893 ? 
0.110? ns/op

This is more than twice as fast as the baseline for constant Method 
instances while not degrading performance for variable Method instances.


[1] 
http://cr.openjdk.java.net/~plevart/jdk-dev/8229871_Method.methodAccessor/ReflectionSpeedBenchmark.java
[2] http://cr.openjdk.java.net/~ogatak/8229871/webrev.04/
[3] 
http://cr.openjdk.java.net/~plevart/jdk-dev/8229871_Method.methodAccessor/webrev.01/


Could you spin this one [3] on your SPECjbb2015 benchmark to see if it 
still performs favorably?


Regards, Peter

On 10/11/19 12:17 PM, Kazunori Ogata wrote:
> Hi Peter,
>
> Thank you for the comment and suggestion of the fix.
>
> I tried to pick up your change w.r.t. methodAccessor:
> https://cr.openjdk.java.net/~ogatak/8229871/webrev.04/
>
>
> Regarding micro benchmark, my original motivation of this change is to
> improve performance of Class.getMethods(), which calls Method.copy() for
> each declared method to create a copy of Method[].
>
> I measured my simple microbench:
> https://cr.openjdk.java.net/~ogatak/8229871/GetMethodsBench.java
>
> Base code: Elapsed time = 4808 ms
> webrev.01: Elapsed time = 4536 ms  (+   6%)
> webrev.02: Elapsed time = 2331 ms  (+106%)
> webrev.04: Elapsed time = 3746 ms  (+ 28%)
>
> I'll measure larger benchmark and try to think if we can reduce the
> overhead of memory barrier.
>
>
> Regards,
> Ogata
>
>
> Peter Levart <peter.levart at gmail.com> wrote on 2019/10/09 16:44:13:
>
>> From: Peter Levart <peter.levart at gmail.com>
>> To: Kazunori Ogata <OGATAK at jp.ibm.com>, core-libs-dev at openjdk.java.net
>> Date: 2019/10/09 16:44
>> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of
>> Method.copy() and leafCopy()
>>
>> Hi Ogata,
>>
>> May I just add that volatile field ensured that MethodAccessor object
> was
>> correctly published. DelegatingMethodAccessortImpl is not safe to be
>> published via data race because it contains plain `delegate` field
>> initialized in the constructor. In addition, the object that is first
>> assigned to that field is NativeMethodAccessorImpl which has plain
>> `parent` field. You can get NPE when invoking the Method.invoke from
>> multuiple threads if Method.methodAccessor is not volatile.
>>
>> In addition, It would be nice to have two microbenchmarks exercising:
>> a) Method copy performance
>> b) Method invocation performance
>>
>> Regards, Peter
>>
>> P.S. When exploring the possibility of an alternative MethodAccessor
>> implementation (using MethodHandle(s)):
>>
>>
> http://cr.openjdk.java.net/~plevart/jdk-dev/6824466_MHReflectionAccessors/
>> webrev.00.2/
>>
>> ...I found out that it was possible to re-arrange the play between
>> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and generated
>> MethodAccessor in such a way that the DelegatingMethodAccessortImpl
>> becomes safe to be published via data race. This allowed for
>> Method.methodAccessor field to become plain field. In addition this
> field
>> can be made @Stable which further optimizes access to MethodAccessor
>> instance when Method instance can be constant-folded, which showed in
>> special microbenchmarks.
>>
>> So perhaps you could try to use above implementation (just changes to
>> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and part of
>> Reflection factory but without MH* stuff) and measure it against current
>> and your implementation (which as shown above has a data-race flaw).
>> On 10/8/19 12:23 PM, Kazunori Ogata wrote:
>> Hi all,
>>
>> I posted two changes and got reply that performance evaluation is
> needed.
>> I found that making Method.methodAccessor non-volatile (webrev.02) is
>> better than avoid copying methodAccessor value when it is null
>> (webrev.01), as shown below.
>>
>> So I'd like to ask review of the former change.  I updated weberv using
>> the latest code base (though there was no difference from webrev.02):
>>
>> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.03/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
>>
>>
>> For this performance evaluation, I calculated 75 percentile of 9 runs of
>> SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers.  I
>> bound a JVM to a NUMA node and set the number of GC threads to the same
> as
>> the number of physical cores.  These tuning reduced run-to-run
> fluctuation
>> on POWER (as usual...).
>>
>> SPECjbb2015:
>>    webrev.02:  critical jOPS +1.6%, max jOPS +0.2%
>>    webrev.01:  critical jOPS +0.4%, max jOPS +0.2%
>>
>>
>> For DaCapo, some benchmark still improved performance and some degraded,
>> but the geometric mean of all benchmarks were small:
>>    weberv.02: +0.3%
>>    weberv.01: +0.2%
>>
>> The difference of improvement/degradation between the two changes in
> each
>> benchmark were less than 0.8%.
>>
>> The range of improvement/degradation in each benchmark were:
>>    webrev.02: between +2.4% and -1.0%
>>    webrev.01: between +1.6% and -1.8%
>>
>>
>> So I think webrev.02 (i.e., making methodAccessor non-volatile) is a
> good
>> change, since it improved SPECjbb critical jOPS by 1.6%.
>>
>>
>> Regards,
>> Ogata
>>
>>
>> Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39:
>>
>> From: Kazunori Ogata/Japan/IBM
>> To: Mandy Chung <mandy.chung at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Date: 2019/08/27 15:41
>> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() and
>> leafCopy()
>> Hi Mandy,
>>
>> Let me post interim results of the performance evaluation, though I'm
>> still measuring benchmarks and analyzing them.
>>
>> For SPECjbb2015, skipping storing null (webrev.01) was faster than
>> making
>> methodAccessor non-volatile (webrev.02).  The improvements of each of
>> the
>> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%,
>> respectively.  This is only an average of six runs.
>>
>> For DaCapo, the results were mixed.  In some benchmark, both of the
>> changes degraded performance.  In some others, webrev.01 was better, but
>
>> weberv.02 was better in some others.
>>
>> I'll continue evaluation, but it is helpful if you could give me some
>> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015.
>>
>> Regards,
>> Ogata
>>
>> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41:
>>
>> From: Kazunori Ogata/Japan/IBM
>> To: Mandy Chung <mandy.chung at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Date: 2019/08/21 20:02
>> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy()
>> and leafCopy()
>> Hi Mandy,
>>
>> Thank you for reviewing the webrev.  I updated it to add a space after
>> "if" and also put four spaces for indentation (it was three).
>>
>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.01/
>>
>> Thank you so much for checking the history of fieldAccessor.  I was
>> surprised that fieldAccessor was made non-volatile in JDK5, but
>> methodAccessor was left as volatile for 15 years after that...
>>
>> I agree we need benchmark data.  My simple micro benchmark that
>> repeats
>> invoking Class.getMethods() improved performance by 70% when it made
>> non-
>> volatile (as shown in the following webrev).  I'll try to run larger
>> benchmarks, such as SPECjbb2015, to see real impact.
>>
>> http://cr.openjdk.java.net/~ogatak/8229871/webrev.02/
>>
>> Regards,
>> Ogata
>>
>> Mandy Chung <mandy.chung at oracle.com> wrote on 2019/08/21 01:21:42:
>>
>> From: Mandy Chung <mandy.chung at oracle.com>
>> To: Kazunori Ogata <OGATAK at jp.ibm.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Date: 2019/08/21 01:21
>> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of
>> Method.copy() and leafCopy()
>>
>> Hi Ogata,
>>
>> The patch looks okay.  Nit: please add a space between if and (.
>>
>> About volatile methodAccessor field, I checked the history.  Both
>> fieldAccessor and methodAccessor were started as volatile and the
>> fieldAccessor declaration was updated due to JDK-5044412.   As you
>> observe, I think the methodAccessor field could be made
>> non-volatile.
>> OTOH that might impact when it's inflated to spin bytecode for this
>> method invocation.  I don't know how importance to keep its volatile
>> vs
>> non-volatile in practice without doing benchmarking/real application
>> testing.
>>
>> Mandy
>>
>> On 8/19/19 2:51 AM, Kazunori Ogata wrote:
>> Hi,
>>
>> May I have review for "JDK-8229871: Imporve performance of
>> Method.copy()
>> and leafCopy()"?
>>
>> Method.copy() and leafCopy() creates a copy of a Method object
>> with
>> sharing MethodAccessor object. Since the methodAccessor field is a
>> volatile variable, copying this field needs memory fence to ensure
>> the
>> field is visible to all threads on the weak memory platforms such
>> as POWER
>> and ARM.
>>
>> When the methodAccessor of the root object is null (i.e., not
>> initialized
>> yet), we do not need to copy the null value because this field of
>> the
>> copied object has been initialized to null in the constructor. We
>> can
>> reduce overhead of the memory fence only when the root's
>> methodAccessor is
>> non-null. This change improved performance by 5.8% using a micro
>> benchmark
>> that repeatedly invokes Class.getMethods().
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229871
>>
>> Webrev: http://cr.openjdk.java.net/~ogatak/8229871/webrev.00/
>>
>>
>> By the way, why Method.methodAccessor is volatile, while
>> Field.fieldAccessor and Field.overrideFieldAccessor are not
>> volatile?  I
>> know the use of volatile reduces probability of creating
>> duplicated method
>> accessor, but the chance still exists.  I couldn't find the
>> difference
>> between Method and Field classes to make Method.methodAccessor
>> volatile.
>> If we can make it non-volatile, it is more preferable than a quick
>> hack
>> above.
>>
>>
>> Regards,
>> Ogata
>>
>>
>>
>


From christoph.langer at sap.com  Wed Oct 23 21:30:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 23 Oct 2019 21:30:39 +0000
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
Message-ID: <AM6PR02MB4801BFDE60B7EAAF182D47278A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Jaikiran,

thanks for proposing this patch. I just had a look and think the fix in ZipFileSystem.java is the right thing to do.

As for the test: That could be simplified a bit.

For the path to the test file, you could simply do: final Path jarPath = Paths.get("zipfs-crc-test.jar");
The test is run in the scratch directory of jtreg, so no reason to go to java.io.tmpdir.

You can also skip deletion of this test file in the finally block, as the jtreg scratch directories will be wiped by jtreg eventually.

For the existence check of the test file in line 62, you can simply use Files.exists.

As for creating the zipfs Filesystem (line 68), you can simply use FileSystems.newFileSystem(Path, Map), no need to mess around with URIs.

Line 96, where construct the input stream and then in 97, the ZipInputStream, I suggest you either put both into the try statement or you use ZipInputStream zis = new ZipInputStream(Files.newInputStream(jarPath)) and then rely on ZipInputStream cascading the close.

And my last suggestion: you could statically import Assert.assertEquals to shorten lines 105 and 106.

Thanks
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Jaikiran Pai
> Sent: Mittwoch, 23. Oktober 2019 13:24
> To: core-libs-dev at openjdk.java.net
> Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads
> to a CRC failure in the generated jar file
> 
> Can I please get a review and a sponsor for a potential fix for
> JDK-8232879[1]? The patch is available as a webrev at [2].
> 
> What's happening in there is that the
> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the
> one arg write(byte b) method and calling the super.write(b) and then
> doing a crc.update. The super.write(b)
> (java.util.zip.DeflaterOutputStream in this case) actually internally
> calls the 3 arg write(b, offset, length) which is overriding by this
> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream. In its
> implementation of write(b, offset, length), in addition to (rightly)
> calling super.write(b, offset, length), this method also updates the CRC
> (again). So this ends up updating the CRC multiple times when the single
> arg write is invoked.
> 
> The patch now removes this overridden implementation of write(b) in the
> DeflatingEntryOutputStream so that the call is handled by the
> java.util.zip.DeflaterOutputStream. Although there's no @implNote on
> java.util.zip.DeflaterOutputStream#write(byte b) static that it's
> (always) going to call the 3 arg write(b, offset, length) method, the
> implementation as of now does indeed do that. So I guess, its probably
> OK to rely on that knowledge and get rid of this overridden write(b)
> method instead of coming up with a bit more complicated fix.
> 
> The patch also includes a jtreg testcase which reproduces this issues
> and verifies the fix.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8232879
> 
> [2] https://cr.openjdk.java.net/~jpai/webrev/8232879/1/webrev/
> 
> -Jaikiran
> 


From seth.lytle at gmail.com  Wed Oct 23 22:00:08 2019
From: seth.lytle at gmail.com (seth lytle)
Date: Wed, 23 Oct 2019 18:00:08 -0400
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
 <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
 <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>
Message-ID: <CAJtn+AdkQpV_7PZszOAx82iyVKmwOqMyp3TT8w5x9mjNyA+P5A@mail.gmail.com>

At least a couple appear to be recently active, though I don't have
current access. Maybe an IDE generates boilerplate for proxies and
ignores deprecation ?

is the speed of the StackWalker approach to counting frames comparable
to the current native method ?






On Wed, Oct 23, 2019 at 11:57 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 23/10/2019 16:25, seth lytle wrote:
> > With respect to "unable to find anything that uses it", a quick search
> > of the code that I have access to shows some usage, though everything
> > I looked at in any depth is either a test or a proxy, so there will be
> > source code changes required. I've never thought about what the right
> > way to handle proxying a deprecated method is.
> >
> Is this maintained code (or tests)? I find it hard to see how anything
> could depend on it. The deprecated warning has been there since 1998,
> the for-removal warning since JDK 9, so I assume the warnings are being
> ignored.
>
> -Alan

From fujie at loongson.cn  Thu Oct 24 01:03:29 2019
From: fujie at loongson.cn (Jie Fu)
Date: Thu, 24 Oct 2019 09:03:29 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <f78414b6-8889-aa40-93c5-21ab71b77598@oracle.com>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <f78414b6-8889-aa40-93c5-21ab71b77598@oracle.com>
Message-ID: <3942f876-3c5a-8d47-f53a-88f29e544531@loongson.cn>

Thanks Claes for your review and comments.

On 2019/10/23 ??6:49, Claes Redestad wrote:
> Hi,
>
> ideally the build step to generate default_jli_trace.txt should be
> done independently of where the CDS feature is compiled in, but the
> fix looks good regardless.
>
> /Claes
>
> On 2019-10-23 09:16, Jie Fu wrote:
>> Hi all,
>>
>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232864
>> Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/
>>
>> To find out how to reproduce this bug, please refer to the JBS.
>>
>> To keep things sorted in a deterministic order, current 
>> implementation seems to be dependent on a default trace file [1] 
>> (default_jli_trace.txt, which is generated during building the jdk 
>> image [2]).
>> However, not all images will generate such a trace file.
>> For example, when cds is disabled, default_jli_trace.txt won't be 
>> generated at all.
>> If the trace file doesn't exist, classes generated by 
>> GenerateJLIClassesPlugin.java will not be sorted in a deterministic 
>> order.
>>
>> Testing:
>> ??- make test TEST="tier1 tier2 tier3" CONF=server-release
>>
>> Could you please review it and give me some advice?
>>
>> Thanks a lot.
>> Best regards,
>> Jie
>>
>> [1] 
>> http://hg.openjdk.java.net/jdk/jdk/file/70e6b0d8db13/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java#l58 
>>
>> [2] 
>> http://hg.openjdk.java.net/jdk/jdk/file/70e6b0d8db13/make/GenerateLinkOptData.gmk#l54 
>>
>>
>>


From fujie at loongson.cn  Thu Oct 24 01:05:50 2019
From: fujie at loongson.cn (Jie Fu)
Date: Thu, 24 Oct 2019 09:05:50 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
Message-ID: <f25ab4a7-dcd1-c258-0d6c-20a065420424@loongson.cn>

Thanks Mandy for your review and comments.

I'll try to construct a reproducer. Thanks.

On 2019/10/24 ??2:37, Mandy Chung wrote:
>
>
> On 10/23/19 12:16 AM, Jie Fu wrote:
>> Hi all,
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232864
>> Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/
>>
> speciesTypes, invokerTypes, callSiteTypes and dmhMethods are sorted
> when the trace config is present (done in readTraceConfig).
>
> An alternative to (re)sort the collections in the transform method
> is to refactor initialize and readTraceConfig methods such that
> these collections are ensured sorted (maybe consider adding
> a builder class).
>
> Can you also extend JLinkReproducibleTest to add the case when
> the default trace config is not present?
>
> Mandy
>
>

From alexey.semenyuk at oracle.com  Thu Oct 24 01:59:00 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 23 Oct 2019 21:59:00 -0400
Subject: RFR: JDK-8230612: Debian packaging ignores version and release in
 custom control file
In-Reply-To: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
Message-ID: <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8230612/webrev.00


From alexey.semenyuk at oracle.com  Thu Oct 24 02:00:13 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 23 Oct 2019 22:00:13 -0400
Subject: RFR: JDK-8223323: Adjust jpackage makefiles
In-Reply-To: <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
References: <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
Message-ID: <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8223323/webrev.00


From jai.forums2013 at gmail.com  Thu Oct 24 02:46:10 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 24 Oct 2019 08:16:10 +0530
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <AM6PR02MB4801BFDE60B7EAAF182D47278A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
 <AM6PR02MB4801BFDE60B7EAAF182D47278A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <a22dffc3-8916-061c-b1b2-9396f8ee8f9e@gmail.com>

Hello Christoph,

Thank you for the very detailed review. Comments inline.

On 24/10/19 3:00 AM, Langer, Christoph wrote:
>
> For the path to the test file, you could simply do: final Path jarPath = Paths.get("zipfs-crc-test.jar");
> The test is run in the scratch directory of jtreg, so no reason to go to java.io.tmpdir.

Thank you. I wasn't aware of jtreg scratch dir. Does it get used for
every test or is there something specific to the location/type of this
test? The updated webrev now uses the above construct.

> You can also skip deletion of this test file in the finally block, as the jtreg scratch directories will be wiped by jtreg eventually.
>
> For the existence check of the test file in line 62, you can simply use Files.exists.

Indeed. Updated in new webrev.


> As for creating the zipfs Filesystem (line 68), you can simply use FileSystems.newFileSystem(Path, Map), no need to mess around with URIs.
The FileSystems.newFileSystem(Path, Map) doesn't exist in Java 11[1]. Of
course, this specific test will be run against latest upstream, where
this new method exists. I actually copied over that usage from my Java
11 reproducer. But given that this issue isn't about creating the
FileSystem itself, I have taken your advice and changed this line in the
new webrev.
>
> Line 96, where construct the input stream and then in 97, the ZipInputStream, I suggest you either put both into the try statement or you use ZipInputStream zis = new ZipInputStream(Files.newInputStream(jarPath)) and then rely on ZipInputStream cascading the close.
Done - updated in new webrev.
>
> And my last suggestion: you could statically import Assert.assertEquals to shorten lines 105 and 106.

Done - updated in new webrev.

The updated webrev is here
https://cr.openjdk.java.net/~jpai/webrev/8232879/2/webrev/

[1]
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/FileSystems.html

-Jaikiran




From jai.forums2013 at gmail.com  Thu Oct 24 02:47:02 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 24 Oct 2019 08:17:02 +0530
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
 <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>
Message-ID: <c41e32d1-6a57-6adf-5e13-b98bd6abc299@gmail.com>

Thank you Lance.

-Jaikiran

On 24/10/19 1:17 AM, Lance Andersen wrote:
> Hi Jaikiran,
>
> I will take a look and once we are good with the review, I can sponsor it.
>
> Best
> Lance
>> On Oct 23, 2019, at 7:24 AM, Jaikiran Pai <jai.forums2013 at gmail.com
>> <mailto:jai.forums2013 at gmail.com>> wrote:
>>
>> Can I please get a review and a sponsor for a potential fix for
>> JDK-8232879[1]? The patch is available as a webrev at [2].
>>
>> What's happening in there is that the
>> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the
>> one arg write(byte b) method and calling the super.write(b) and then
>> doing a crc.update. The super.write(b)
>> (java.util.zip.DeflaterOutputStream in this case) actually internally
>> calls the 3 arg write(b, offset, length) which is overriding by this
>> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream. In its
>> implementation of write(b, offset, length), in addition to (rightly)
>> calling super.write(b, offset, length), this method also updates the CRC
>> (again). So this ends up updating the CRC multiple times when the single
>> arg write is invoked.
>>
>> The patch now removes this overridden implementation of write(b) in the
>> DeflatingEntryOutputStream so that the call is handled by the
>> java.util.zip.DeflaterOutputStream. Although there's no @implNote on
>> java.util.zip.DeflaterOutputStream#write(byte b) static that it's
>> (always) going to call the 3 arg write(b, offset, length) method, the
>> implementation as of now does indeed do that. So I guess, its probably
>> OK to rely on that knowledge and get rid of this overridden write(b)
>> method instead of coming up with a bit more complicated fix.
>>
>> The patch also includes a jtreg testcase which reproduces this issues
>> and verifies the fix.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232879
>>
>> [2] https://cr.openjdk.java.net/~jpai/webrev/8232879/1/webrev/
>>
>> -Jaikiran
>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering?
> 1 Network Drive?
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From martinrb at google.com  Thu Oct 24 03:24:25 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 23 Oct 2019 20:24:25 -0700
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
 <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
 <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
Message-ID: <CA+kOe0_uO9KTjah0JFSvRzceODMg0+-4ZZ_xZ-Sxq8hpA21ykA@mail.gmail.com>

On Tue, Oct 22, 2019 at 3:58 PM David Holmes <david.holmes at oracle.com>
wrote:

>
> Perhaps one aspect of the class loading/resolution/initialization
> process that can lead to confusion here is that if a class fails to
> execute its static initialization then it is marked as Erroneous and all
> subsequent attempts to use that class result in NoClassDefFoundError
> being thrown. If the original ExceptionInInitializerError got swallowed
> somewhere then that can cause great confusion as to why the later NCDFE
> occurs. The VM logging should help in that case - though I'd have to
> confirm that (if it doesn't that should be fixed).
>

I had a need to debug an error in a <clinit> this week and was again
frustrated by the difficulty.
Classes falling into Erroneous state are rare so it seems reasonable to
save the exception as a cause for the subsequent NCDFE (probably can't fix
the misleading name of the exception)
I couldn't find a way to get hotspot to report the stack trace of all
exceptions that are thrown; -Xlog:exceptions=trace does not .

I was also frustrated that a StackOverflowError failed to report the name
of the thread and the stack size that was exceeded.  But
-Xlog:threads*=trace helped there.

From fujie at loongson.cn  Thu Oct 24 04:04:28 2019
From: fujie at loongson.cn (Jie Fu)
Date: Thu, 24 Oct 2019 12:04:28 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
Message-ID: <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>

Hi Mandy,

Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.01/

The JLinkReproducibleTest had been extended to test the case when the 
default trace file is not present.

If you're OK with the change, could you please sponsor it?

Thanks a lot.
Best regards,
Jie

On 2019/10/24 ??2:37, Mandy Chung wrote:
> Can you also extend JLinkReproducibleTest to add the case when
> the default trace config is not present?

From david.holmes at oracle.com  Thu Oct 24 04:19:49 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 24 Oct 2019 14:19:49 +1000
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <CA+kOe0_uO9KTjah0JFSvRzceODMg0+-4ZZ_xZ-Sxq8hpA21ykA@mail.gmail.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
 <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
 <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
 <CA+kOe0_uO9KTjah0JFSvRzceODMg0+-4ZZ_xZ-Sxq8hpA21ykA@mail.gmail.com>
Message-ID: <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com>

Hi Martin,

This is going a bit OT I think ...

On 24/10/2019 1:24 pm, Martin Buchholz wrote:
> 
> 
> On Tue, Oct 22, 2019 at 3:58 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
> 
>     Perhaps one aspect of the class loading/resolution/initialization
>     process that can lead to confusion here is that if a class fails to
>     execute its static initialization then it is marked as Erroneous and
>     all
>     subsequent attempts to use that class result in NoClassDefFoundError
>     being thrown. If the original ExceptionInInitializerError got swallowed
>     somewhere then that can cause great confusion as to why the later NCDFE
>     occurs. The VM logging should help in that case - though I'd have to
>     confirm that (if it doesn't that should be fixed).
> 
> 
> I had a need to debug an error in a <clinit> this week and was again 
> frustrated by the difficulty.
> Classes falling into Erroneous state are rare so it seems reasonable to 
> save the exception as a cause for the subsequent NCDFE (probably can't 
> fix the misleading name of the exception)

So as you know such a request existed:

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

and was closed as it was considered that TraceExceptions (now 
-Xlog:exceptions) would provide the additional information. As noted in 
that bug there are also semantic issues about recording the cause of an 
exception in thread B, with an exception object that was thrown in 
thread A. So unless someone comes up with a very convincing argument, or 
else it prepared to do the work, I don't see that being re-opened.

> I couldn't find a way to get hotspot to report the stack trace of all 
> exceptions that are thrown; -Xlog:exceptions=trace does not .

-Xlog:exceptions shows where the exception is thrown and how it proceeds 
up the stack. It doesn't print the full stacktrace. That seems like a 
logging request for the Throwable constructor, or fillInStackTrace, to 
me, rather than trying to have the VM do it. IIRC we store minimal VM 
information in the backTrace which is expanded when needed into the full 
StacktraceElements array.
> I was also frustrated that a StackOverflowError failed to report the 
> name of the thread and the stack size that was exceeded.? But 
> -Xlog:threads*=trace helped there.

The issue there is that SOE instances are allocated natively without 
executing any Java code (as we have run out of the Java stack) so we 
can't (easily) create a String message for the exception. However 
-Xlog:exceptions could be expanded to report that information at the 
point we throw the SOE. I filed - JDK-8232923.

Cheers,
David

From brent.christian at oracle.com  Thu Oct 24 04:42:14 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 23 Oct 2019 21:42:14 -0700
Subject: RFR: 8226297: Dual-pivot quicksort improvements
In-Reply-To: <b5379549-2d67-9c3c-ab8a-56accd5477db@oracle.com>
References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com>
 <392719f4-d67c-f900-0f2d-6c9f826a5392@oracle.com>
 <1a031e52-b824-65bc-1ec1-c6d80a231cd9@oracle.com>
 <1570573112.22458835@f475.i.mail.ru>
 <b5379549-2d67-9c3c-ab8a-56accd5477db@oracle.com>
Message-ID: <2fa64524-6d9d-6b24-0a86-00d3a0512d1b@oracle.com>

Hi,

I've created a webrev of the latest test changes that Vladimir sent me:

http://cr.openjdk.java.net/~bchristi/8226297/webrev09-testUpdate/

(I also created an incremental webrev[1] along the way, in case that's 
helpful to anyone).

I have just a few comments:

test/jdk/java/util/Arrays/Sorting.java

* I found some instances of "FloatPointing", which I've already changed 
to "FloatingPoint". :)

--

      // Array lengths used in a long run (default)
      private static final int[] LONG_RUN_LENGTHS = {
-        1, 2, 3, 5, 8, 13, 21, 34, 55, 100, 1000, 10000, 100000, 1000000 };
+        1, 3, 8, 21, 55, 100, 1_000, 10_000, 100_000 };

      // Array lengths used in a short run
      private static final int[] SHORT_RUN_LENGTHS = {
-        1, 2, 3, 21, 55, 1000, 10000 };
+        1, 8, 55, 100, 10_000 };

Vladimir, can you tell me why some of the length values have been removed?

--

1570     private static enum TypeConverter {
...
1637         abstract void convert(Object src, Object dst);

The 'src' argument to convert is always cast to an int[].  Can it be 
made an int[] in the method signature, instead of Object ?  I can make 
the change if that sounds good.

Other than those, this is pretty much ready to go.

Thanks,
-Brent

1. http://cr.openjdk.java.net/~bchristi/8226297/webrev09-incremental/

On 10/8/19 5:41 PM, Brent Christian wrote:
> Hi, Vladimir
> 
> On 10/8/19 3:18 PM, Vladimir Yaroslavskiy wrote:
>>
>> The following renaming changes are important
>> and should be kept. My explanation is here
>  > ...
> 
> Thanks for the explanation - much appreciated.
> 
>> * Other changes, like failed -> fail, i++ -> ++i,
>> and TypeConverter, FloatBuilder, DoubleBuilder, SortedBuilder
>> to be non-static can be reverted.
>>
>> I can revert them, if you agree.
> 
> That would be great, thanks.
> 
>> ??? * I like that the various DualPivotQuickSort methods are tested
>> ??? directly (via SortingHelper). I'd prefer that we also continue 
>> testing
>> ??? direct calls to Arrays.sort(), as that's what users will call. What
>> ??? would be the best way to add that back in? (Maybe a SortingHelper
>> ??? variant that calls Arrays.sort()?).
>>
>> I will add direct calls to Arrays.sort() and Arrays.parallelSort() also.
> 
> Great, thank you.
> 
>> ??? * Having the test operation depend on setting various values to the
>> ??? static 'sortingHelper' field seems brittle to me. This could be a 
>> good
>> ??? opportunity to convert from static to instance methods, make
>> ??? 'sortingHelper' and 'name' member variables, and create separate
>> ??? Sorting
>> ??? objects for each SortingHelper. Such a refactoring is not strictly
>> ??? necessary, but I think it would be nice to have.
>>
>>
>> Good idea, I will implement it and send you update version very soon.
> 
> Sounds good!
> 
>>> ??? test/jdk/java/util/Arrays/FailedFloat.java
>>>
>>> ??? Is this test necessary, given the addition of
>>> ??? testFloatNegativeZero() in
>>> ??? Sorting.java ?
>>
>> Not necessary, because testFloatNegativeZero() covers this case.
>> This class was created to reproduce bug when float-pointing zeros
>> and NaNs are sorted.
>>
>> Please remove FailedFloat.java. It makes sense to add the source of 
>> this class to 8226297.
> 
> Done and done.
> 
> -Brent

From mandy.chung at oracle.com  Thu Oct 24 05:12:47 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 23 Oct 2019 22:12:47 -0700
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
 <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>
Message-ID: <2f4b97f6-3839-87ae-44d2-70f03bef9945@oracle.com>

Hi Jie,

The new test looks good, thanks.

About the GenerateJLIClassesPlugin change, I mentioned the alternative 
way to implement it.?? I think you can avoid the resorting in the case 
when the trace config file is present.?? I'd like to see the initialize 
method builds a sorted speciesTypes, invokerTypes, callSiteTypes and 
dmhMethods.?? The readTraceConfig method already creates them as 
TreeMap/TreeSet.?? Some refactoring or using a builder class should 
achieve this.

Mandy

On 10/23/19 9:04 PM, Jie Fu wrote:
>
> Hi Mandy,
>
> Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.01/
>
> The JLinkReproducibleTest had been extended to test the case when the 
> default trace file is not present.
>
> If you're OK with the change, could you please sponsor it?
>
> Thanks a lot.
> Best regards,
> Jie
>
> On 2019/10/24 ??2:37, Mandy Chung wrote:
>> Can you also extend JLinkReproducibleTest to add the case when
>> the default trace config is not present?


From fujie at loongson.cn  Thu Oct 24 06:21:28 2019
From: fujie at loongson.cn (Jie Fu)
Date: Thu, 24 Oct 2019 14:21:28 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <2f4b97f6-3839-87ae-44d2-70f03bef9945@oracle.com>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
 <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>
 <2f4b97f6-3839-87ae-44d2-70f03bef9945@oracle.com>
Message-ID: <fb835ceb-6a5b-2803-22e0-50da6d19d3ca@loongson.cn>

Hi Mandy,

Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.02/
It seems better now.

If you're OK with the change, could you please sponsor it?

Thanks a lot.
Best regards,
Jie

On 2019/10/24 ??1:12, Mandy Chung wrote:
> About the GenerateJLIClassesPlugin change, I mentioned the alternative 
> way to implement it.?? I think you can avoid the resorting in the case 
> when the trace config file is present.?? I'd like to see the 
> initialize method builds a sorted speciesTypes, invokerTypes, 
> callSiteTypes and dmhMethods.?? The readTraceConfig method already 
> creates them as TreeMap/TreeSet.?? Some refactoring or using a builder 
> class should achieve this. 

Very cool suggestions. Thanks.

Done.



From Alan.Bateman at oracle.com  Thu Oct 24 08:21:48 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Oct 2019 09:21:48 +0100
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <CAJtn+AdkQpV_7PZszOAx82iyVKmwOqMyp3TT8w5x9mjNyA+P5A@mail.gmail.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
 <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
 <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>
 <CAJtn+AdkQpV_7PZszOAx82iyVKmwOqMyp3TT8w5x9mjNyA+P5A@mail.gmail.com>
Message-ID: <2faf36a1-f1b9-5c1f-dabf-30caa457ad48@oracle.com>

On 23/10/2019 23:00, seth lytle wrote:
> At least a couple appear to be recently active, though I don't have
> current access. Maybe an IDE generates boilerplate for proxies and
> ignores deprecation ?
>
> is the speed of the StackWalker approach to counting frames comparable
> to the current native method ?
>
countStackFrames has always been ill-defined, and it requires the thread 
to be suspended. We've been directly people to StackWalker and several 
releases so best to try it yourself and come back with your results/issues.

-Alan

From amy.lu at oracle.com  Thu Oct 24 08:49:40 2019
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 24 Oct 2019 16:49:40 +0800
Subject: [JDK 14] RFR 8232922: Add
 java/math/BigInteger/largeMemory/SymmetricRangeTests.java to
 ProblemList-Xcomp
Message-ID: <324f135c-a1df-0804-1672-208d008a5e9b@oracle.com>

java/math/BigInteger/largeMemory/SymmetricRangeTests.java

Please review the patch to add above test to ProblemList-Xcomp.txt while 
JDK-8232840 is being investigated/fixed.

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

Thanks,
Amy

--- old/test/jdk/ProblemList-Xcomp.txt??? 2019-10-24 11:09:40.000000000 
+0800
+++ new/test/jdk/ProblemList-Xcomp.txt??? 2019-10-24 11:09:40.000000000 
+0800
@@ -29,3 +29,4 @@

 ?java/lang/invoke/MethodHandles/CatchExceptionTest.java 8146623 generic-all
 ?java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java 8216317 solaris-all
+java/math/BigInteger/largeMemory/SymmetricRangeTests.java 8232840 
generic-all


From vlv.spb.ru at mail.ru  Thu Oct 24 11:30:22 2019
From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=)
Date: Thu, 24 Oct 2019 14:30:22 +0300
Subject: =?UTF-8?B?UmVbMl06IFJGUjogODIyNjI5NzogRHVhbC1waXZvdCBxdWlja3NvcnQgaW1w?=
 =?UTF-8?B?cm92ZW1lbnRz?=
In-Reply-To: <2fa64524-6d9d-6b24-0a86-00d3a0512d1b@oracle.com>
References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com>
 <b5379549-2d67-9c3c-ab8a-56accd5477db@oracle.com>
 <2fa64524-6d9d-6b24-0a86-00d3a0512d1b@oracle.com>
Message-ID: <1571916622.27188505@f495.i.mail.ru>

Hi?Brent,

See my comments inline

>Oct 24? 2019, 7:42 +03:00 ?? Brent Christian <brent.christian at oracle.com>:
>
>Hi,
>
>I've created a webrev of the latest test changes that Vladimir sent me:
>
>http://cr.openjdk.java.net/~bchristi/8226297/webrev09-testUpdate/
>
>(I also created an incremental webrev[1] along the way, in case that's 
>helpful to anyone).
>
>I have just a few comments:
>
>test/jdk/java/util/Arrays/Sorting.java
>
>* I found some instances of "FloatPointing", which I've already changed 
>to "FloatingPoint". :)
>
>--
Thank you for correction.
>
>??????// Array lengths used in a long run (default)
>??????private static final int[] LONG_RUN_LENGTHS = {
>-        1, 2, 3, 5, 8, 13, 21, 34, 55, 100, 1000, 10000, 100000, 1000000 };
>+        1, 3, 8, 21, 55, 100, 1_000, 10_000, 100_000 };
>
>??????// Array lengths used in a short run
>??????private static final int[] SHORT_RUN_LENGTHS = {
>-        1, 2, 3, 21, 55, 1000, 10000 };
>+        1, 8, 55, 100, 10_000 };
>
>Vladimir, can you tell me why some of the length values have been removed?
>
>--

Different sorting algorithms are invoked depending on input size. Insertion
sort is run on small arrays, but, for example, sizes 5 and 8 are similar for
insertion sort. Therefore, the list contains few small sizes only. Larger
sizes are used for Quicksort, merging sort, parallel sort.
There was requirement to have fast runs (short and long) as much as possible.
Testing with 1M elements took almost all time, but didn't invoke new functionality.
I removed 1M and time of long run was down from 10 min to 2.5 min, short run
takes about 5-7 sec instead of 15-20 sec.
As a result, I achieved reasonable testing time with coverage of all cases,
excluding checks like, throw new IllegalArgumentException("Unknown type of array...
>
>1570     private static enum TypeConverter {
>...
>1637         abstract void convert(Object src, Object dst);
>
>The 'src' argument to convert is always cast to an int[].  Can it be 
>made an int[] in the method signature, instead of Object ?  I can make 
>the change if that sounds good.
Good catch! Please, switch to?void convert(int[] a, Object dst)
and remove?int[] a = (int[]) src; from all implementation methods.

And could you also please delete unnecessary code?

Lines 1509-1510:

if (src instanceof int[]) {
? ? ?copy((int[]) dst, (int[]) src);
in method?private void copy(Object dst, Object src)

and then whole method?at lines 1520-1522:
private void copy(int[] dst, int[] src)

Method copy is invoked on float/double arrays only,
not necessary to compare with int[].

Thanks,
Vladimir
>
>Other than those, this is pretty much ready to go.
>
>Thanks,
>-Brent
>
>1.  http://cr.openjdk.java.net/~bchristi/8226297/webrev09-incremental/
>
>On 10/8/19 5:41 PM, Brent Christian wrote:
>> Hi, Vladimir
>> 
>> On 10/8/19 3:18 PM, Vladimir Yaroslavskiy wrote:
>>>
>>> The following renaming changes are important
>>> and should be kept. My explanation is here
>>  > ...
>> 
>> Thanks for the explanation - much appreciated.
>> 
>>> * Other changes, like failed -> fail, i++ -> ++i,
>>> and TypeConverter, FloatBuilder, DoubleBuilder, SortedBuilder
>>> to be non-static can be reverted.
>>>
>>> I can revert them, if you agree.
>> 
>> That would be great, thanks.
>> 
>>> ??? * I like that the various DualPivotQuickSort methods are tested
>>> ??? directly (via SortingHelper). I'd prefer that we also continue testing
>>> ??? direct calls to Arrays.sort(), as that's what users will call. What
>>> ??? would be the best way to add that back in? (Maybe a SortingHelper
>>> ??? variant that calls Arrays.sort()?).
>>>
>>> I will add direct calls to Arrays.sort() and Arrays.parallelSort() also.
>> 
>> Great, thank you.
>> 
>>> ??? * Having the test operation depend on setting various values to the
>>> ??? static 'sortingHelper' field seems brittle to me. This could be a good
>>> ??? opportunity to convert from static to instance methods, make
>>> ??? 'sortingHelper' and 'name' member variables, and create separate
>>> ??? Sorting
>>> ??? objects for each SortingHelper. Such a refactoring is not strictly
>>> ??? necessary, but I think it would be nice to have.
>>>
>>> Good idea, I will implement it and send you update version very soon.
>> 
>> Sounds good!
>> 
>>>> ??? test/jdk/java/util/Arrays/FailedFloat.java
>>>>
>>>> ??? Is this test necessary, given the addition of
>>>> ??? testFloatNegativeZero() in
>>>> ??? Sorting.java ?
>>>
>>> Not necessary, because testFloatNegativeZero() covers this case.
>>> This class was created to reproduce bug when float-pointing zeros
>>> and NaNs are sorted.
>>>
>>> Please remove FailedFloat.java. It makes sense to add the source of 
>>> this class to  8226297 .
>> 
>> Done and done.
>> 
>> -Brent

From vlv.spb.ru at mail.ru  Thu Oct 24 12:11:21 2019
From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=)
Date: Thu, 24 Oct 2019 15:11:21 +0300
Subject: =?UTF-8?B?Q2hlY2tpbmcgaW5zdGFuY2VvZiBpbiBEdWFsUGl2b3RRdWlja3NvcnQ=?=
Message-ID: <1571919081.256114976@f562.i.mail.ru>

Hi Brent,

Looking at coverage of DualPivotQuicksort class, I found that
cases of unexpected type of given array are not invoked at all
(mentioned in my previous email).

I think that these "else" can be removed, because method
compute() of private classes are invoked from DualPivotQuicksort
class only and we can guarantee valid array types (int[], .. , double[]).

If you agree, could you please, remove such cases?

Replace lines 4147-4148:

throw new IllegalArgumentException(
    "Unknown type of array: " + a.getClass().getName());

by return null;

remove lines 4099-4101:

} else {
    throw new IllegalArgumentException(
        "Unknown type of array: " + dst.getClass().getName());

and remove lines 4030-4033:

} else {
    throw new IllegalArgumentException(
        "Unknown type of array: " + a.getClass().getName());

-----

And doe the same for Sorting class: remove 12 cases
fail("Unknown type of array: " + ....

Thank you,
Vladimir

From andy.herrick at oracle.com  Thu Oct 24 12:48:41 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 24 Oct 2019 08:48:41 -0400
Subject: RFR: JDK-8223323: Adjust jpackage makefiles
In-Reply-To: <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
References: <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
 <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
Message-ID: <4075052f-8092-5ceb-c823-ef7c3a672f01@oracle.com>

Looks good to me.

/Andy

On 10/23/2019 10:00 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223323
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8223323/webrev.00
>

From christoph.langer at sap.com  Thu Oct 24 15:25:30 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 24 Oct 2019 15:25:30 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <7851ceb0-2dba-4749-5ed8-c91404d2fae2@oracle.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <7851ceb0-2dba-4749-5ed8-c91404d2fae2@oracle.com>
Message-ID: <PR1PR02MB4810DA2F323657A1C4F6FF0F8A6A0@PR1PR02MB4810.eurprd02.prod.outlook.com>

Thanks, Calvin for the review.

Alan, unless you have severe objections I'd push this tomorrow after running another night of tests with this patch and run doing jdk-submit. Is that ok with you?

Thanks
Christoph

> -----Original Message-----
> From: Calvin Cheung <calvin.cheung at oracle.com>
> Sent: Mittwoch, 23. Oktober 2019 20:21
> To: Langer, Christoph <christoph.langer at sap.com>; Alan Bateman
> <Alan.Bateman at oracle.com>; hotspot-runtime-dev at openjdk.java.net; Java
> Core Libs <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows
> 
> Hi Christoph,
> 
> The changes look good.
> 
> I agree that other mentioned items (the JPLIS agent usage and moving the
> canonicalize function into hotspot) could be done in separate RFEs.
> 
> thanks,
> 
> Calvin
> 
> On 10/23/19 5:57 AM, Langer, Christoph wrote:
> > Hi,
> >
> > I've picked up Ralf's patch and cleaned it up a little bit. But apart from some
> comment changes it should be the same as his original version. So, what
> happens is that the windows 'canonicalize" function will only delegate to
> 'wcanonicalize' from now on.  Furthermore,  'canonicalizeWithPrefix' along
> with some auxiliary stuff could be removed completely.
> >
> > Can I please get a review for this, as I'm planning on doing further cleanup
> around canonicalization.
> >
> > New webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232168.0/
> >
> > Thanks
> > Christoph
> >
> >> -----Original Message-----
> >> From: hotspot-runtime-dev <hotspot-runtime-dev-
> >> bounces at openjdk.java.net> On Behalf Of Alan Bateman
> >> Sent: Freitag, 18. Oktober 2019 12:41
> >> To: Schmelter, Ralf <ralf.schmelter at sap.com>; David Holmes
> >> <david.holmes at oracle.com>; hotspot-runtime-dev at openjdk.java.net;
> Java
> >> Core Libs <core-libs-dev at openjdk.java.net>
> >> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on
> Windows
> >>
> >> On 16/10/2019 09:28, Schmelter, Ralf wrote:
> >>> Hi David,
> >>>
> >>> the canonicalize() method is never used by java.io or any Java code.
> >> Currently it is used by the hotspot in classloader.cpp (which I use in the
> test)
> >> and in libinstrument in InvocationAdapter.c. There is no way to test it in
> core-
> >> libs. One can argue if the canonicalize method is in the right file, but that
> >> should be a separate discussion.
> >> I plan to review this, I just haven't had time yet. You are right that
> >> there is technical debt here, include dependency in the JPLIS agent
> >> which crept in when java.lang.instrument was updated to support
> >> augmenting of the boot class path.
> >>
> >> -Alan

From igor.ignatyev at oracle.com  Thu Oct 24 15:33:26 2019
From: igor.ignatyev at oracle.com (Igor Ignatev)
Date: Thu, 24 Oct 2019 08:33:26 -0700
Subject: [JDK 14] RFR 8232922: Add
 java/math/BigInteger/largeMemory/SymmetricRangeTests.java to
 ProblemList-Xcomp
In-Reply-To: <324f135c-a1df-0804-1672-208d008a5e9b@oracle.com>
References: <324f135c-a1df-0804-1672-208d008a5e9b@oracle.com>
Message-ID: <900608D3-CBC2-4745-9386-AF7E8F8F0E7D@oracle.com>

LGTM

? Igor

> On Oct 24, 2019, at 1:49 AM, Amy Lu <amy.lu at oracle.com> wrote:
> 
> ?java/math/BigInteger/largeMemory/SymmetricRangeTests.java
> 
> Please review the patch to add above test to ProblemList-Xcomp.txt while JDK-8232840 is being investigated/fixed.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8232922
> 
> Thanks,
> Amy
> 
> --- old/test/jdk/ProblemList-Xcomp.txt    2019-10-24 11:09:40.000000000 +0800
> +++ new/test/jdk/ProblemList-Xcomp.txt    2019-10-24 11:09:40.000000000 +0800
> @@ -29,3 +29,4 @@
> 
>  java/lang/invoke/MethodHandles/CatchExceptionTest.java 8146623 generic-all
>  java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java 8216317 solaris-all
> +java/math/BigInteger/largeMemory/SymmetricRangeTests.java 8232840 generic-all
> 


From joe.darcy at oracle.com  Thu Oct 24 15:35:02 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 24 Oct 2019 08:35:02 -0700
Subject: [JDK 14] RFR 8232922: Add
 java/math/BigInteger/largeMemory/SymmetricRangeTests.java to
 ProblemList-Xcomp
In-Reply-To: <900608D3-CBC2-4745-9386-AF7E8F8F0E7D@oracle.com>
References: <324f135c-a1df-0804-1672-208d008a5e9b@oracle.com>
 <900608D3-CBC2-4745-9386-AF7E8F8F0E7D@oracle.com>
Message-ID: <979cbcba-10c2-15a5-d9bc-a759b77406f2@oracle.com>

+1

-Joe

On 10/24/2019 8:33 AM, Igor Ignatev wrote:
> LGTM
>
> ? Igor
>
>> On Oct 24, 2019, at 1:49 AM, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> ?java/math/BigInteger/largeMemory/SymmetricRangeTests.java
>>
>> Please review the patch to add above test to ProblemList-Xcomp.txt while JDK-8232840 is being investigated/fixed.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8232922
>>
>> Thanks,
>> Amy
>>
>> --- old/test/jdk/ProblemList-Xcomp.txt    2019-10-24 11:09:40.000000000 +0800
>> +++ new/test/jdk/ProblemList-Xcomp.txt    2019-10-24 11:09:40.000000000 +0800
>> @@ -29,3 +29,4 @@
>>
>>   java/lang/invoke/MethodHandles/CatchExceptionTest.java 8146623 generic-all
>>   java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java 8216317 solaris-all
>> +java/math/BigInteger/largeMemory/SymmetricRangeTests.java 8232840 generic-all
>>

From Alan.Bateman at oracle.com  Thu Oct 24 15:39:03 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Oct 2019 16:39:03 +0100
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <PR1PR02MB4810DA2F323657A1C4F6FF0F8A6A0@PR1PR02MB4810.eurprd02.prod.outlook.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <7851ceb0-2dba-4749-5ed8-c91404d2fae2@oracle.com>
 <PR1PR02MB4810DA2F323657A1C4F6FF0F8A6A0@PR1PR02MB4810.eurprd02.prod.outlook.com>
Message-ID: <15a35661-aadd-4075-6420-0494d538ed1c@oracle.com>

On 24/10/2019 16:25, Langer, Christoph wrote:
> Thanks, Calvin for the review.
>
> Alan, unless you have severe objections I'd push this tomorrow after running another night of tests with this patch and run doing jdk-submit. Is that ok with you?
>
I would like to review this change. Would you mind holding off for a few 
days until I can find time?

-Alan

From christoph.langer at sap.com  Thu Oct 24 15:41:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 24 Oct 2019 15:41:23 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <15a35661-aadd-4075-6420-0494d538ed1c@oracle.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <7851ceb0-2dba-4749-5ed8-c91404d2fae2@oracle.com>
 <PR1PR02MB4810DA2F323657A1C4F6FF0F8A6A0@PR1PR02MB4810.eurprd02.prod.outlook.com>
 <15a35661-aadd-4075-6420-0494d538ed1c@oracle.com>
Message-ID: <PR1PR02MB481021D5524A7ED51A16186E8A6A0@PR1PR02MB4810.eurprd02.prod.outlook.com>

> I would like to review this change. Would you mind holding off for a few
> days until I can find time?

OK, sure. Then I'll wait for you.

Cheers
Christoph


From seth.lytle at gmail.com  Thu Oct 24 16:32:39 2019
From: seth.lytle at gmail.com (seth lytle)
Date: Thu, 24 Oct 2019 12:32:39 -0400
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <2faf36a1-f1b9-5c1f-dabf-30caa457ad48@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
 <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
 <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>
 <CAJtn+AdkQpV_7PZszOAx82iyVKmwOqMyp3TT8w5x9mjNyA+P5A@mail.gmail.com>
 <2faf36a1-f1b9-5c1f-dabf-30caa457ad48@oracle.com>
Message-ID: <CAJtn+Ae_sU3P0wEFkgaheiZp096_qL5SfUD-W-e1tAAX7waLYg@mail.gmail.com>

The use case that's always interested me is checking to see if a
callback to a recursive method (eg during parsing) is "too deep" so
you can bail out (eg, to a non-recursive one or using message
passing). For that purpose, it's already suspended and the native
method is close to what I'd like if it wasn't deprecated.

You started this discussion by claiming that "The StackWalker API is a
much better solution for code that is interested in the number of
stack frames". Seems like a benchmark is a critical part of that
claim. The stack walker approach looked 8x-ish slower for deep stacks
(eg, 1000 and 5000), which is about what I expected given all the
unnecessary object allocations. The walker API also seemed more prone
to stack overflows, but I didn't take the time to quantify that.
Here's one example run (java 11 with defaults):

Benchmark             (stackDepth)  Mode  Cnt  Score   Error  Units
StackWalkerJmh.count          1000  avgt    3  0.030 ? 0.002  ms/op
StackWalkerJmh.count          5000  avgt    3  0.151 ? 0.015  ms/op


Benchmark            (stackDepth)  Mode  Cnt  Score   Error  Units
StackWalkerJmh.walk          1000  avgt    3  0.261 ? 0.027  ms/op
StackWalkerJmh.walk          5000  avgt    3  1.313 ? 1.131  ms/op


    @Benchmark
    public int walk() { return recStackWalker(stackDepth); }
    private static int recStackWalker(int depth) {
        return depth == 0 ? getWalker() : recStackWalker(depth-1);
    }
    private static int getWalker() {
        Count cc = new Count();
        StackWalker.getInstance().forEach(x -> cc.count++);
        return cc.count;
    }
    static class Count { int count; }
    @Benchmark
    public int count() { return recStackTrace(stackDepth); }
    private static int recStackTrace(int depth) {
        return depth == 0 ? getDepth() : recStackTrace(depth-1);
    }
    private static int getDepth() {
        return Thread.currentThread().countStackFrames();
    }



What would be even more useful than stack depth would be an estimate
of the number of bytes remaining in the stack, esp if it was fast. Any
chance that that could get added to the stack walker API ?









On Thu, Oct 24, 2019 at 4:21 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 23/10/2019 23:00, seth lytle wrote:
> > At least a couple appear to be recently active, though I don't have
> > current access. Maybe an IDE generates boilerplate for proxies and
> > ignores deprecation ?
> >
> > is the speed of the StackWalker approach to counting frames comparable
> > to the current native method ?
> >
> countStackFrames has always been ill-defined, and it requires the thread
> to be suspended. We've been directly people to StackWalker and several
> releases so best to try it yourself and come back with your results/issues.
>
> -Alan

From brian.burkhalter at oracle.com  Thu Oct 24 17:48:30 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 24 Oct 2019 10:48:30 -0700
Subject: [JDK 14] RFR 8232922: Add
 java/math/BigInteger/largeMemory/SymmetricRangeTests.java to
 ProblemList-Xcomp
In-Reply-To: <979cbcba-10c2-15a5-d9bc-a759b77406f2@oracle.com>
References: <324f135c-a1df-0804-1672-208d008a5e9b@oracle.com>
 <900608D3-CBC2-4745-9386-AF7E8F8F0E7D@oracle.com>
 <979cbcba-10c2-15a5-d9bc-a759b77406f2@oracle.com>
Message-ID: <C58CB0C0-67A3-49DA-B7DE-453A0DE74571@oracle.com>

+1

Brian

> On Oct 24, 2019, at 8:35 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> +1
> 
> -Joe
> 
> On 10/24/2019 8:33 AM, Igor Ignatev wrote:
>> LGTM
>> 
>> ? Igor
>> 
>>> On Oct 24, 2019, at 1:49 AM, Amy Lu <amy.lu at oracle.com> wrote:
>>> 
>>> ?java/math/BigInteger/largeMemory/SymmetricRangeTests.java
>>> 
>>> Please review the patch to add above test to ProblemList-Xcomp.txt while JDK-8232840 is being investigated/fixed.
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232922
>>> 
>>> Thanks,
>>> Amy
>>> 
>>> --- old/test/jdk/ProblemList-Xcomp.txt    2019-10-24 11:09:40.000000000 +0800
>>> +++ new/test/jdk/ProblemList-Xcomp.txt    2019-10-24 11:09:40.000000000 +0800
>>> @@ -29,3 +29,4 @@
>>> 
>>>  java/lang/invoke/MethodHandles/CatchExceptionTest.java 8146623 generic-all
>>>  java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java 8216317 solaris-all
>>> +java/math/BigInteger/largeMemory/SymmetricRangeTests.java 8232840 generic-all
>>> 


From hboehm at google.com  Thu Oct 24 18:07:08 2019
From: hboehm at google.com (Hans Boehm)
Date: Thu, 24 Oct 2019 11:07:08 -0700
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <CAJtn+Ae_sU3P0wEFkgaheiZp096_qL5SfUD-W-e1tAAX7waLYg@mail.gmail.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
 <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
 <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>
 <CAJtn+AdkQpV_7PZszOAx82iyVKmwOqMyp3TT8w5x9mjNyA+P5A@mail.gmail.com>
 <2faf36a1-f1b9-5c1f-dabf-30caa457ad48@oracle.com>
 <CAJtn+Ae_sU3P0wEFkgaheiZp096_qL5SfUD-W-e1tAAX7waLYg@mail.gmail.com>
Message-ID: <CAMOCf+jfsomcr9Z9NdWz4n=5J3ay1UKVwU5VXsN40=O4t2jMhg@mail.gmail.com>

Do you really want the number of bytes left? It seems a bit cleaner and
more portable to me to phrase such APIs as returning the fraction of the
available resource (e.g. virtual address space for this thread's stack)
that's currently in use. That way you're independent of machine
idiosyncrasies like stack frame sizes.


On Thu, Oct 24, 2019 at 9:33 AM seth lytle <seth.lytle at gmail.com> wrote:

> The use case that's always interested me is checking to see if a
> callback to a recursive method (eg during parsing) is "too deep" so
> you can bail out (eg, to a non-recursive one or using message
> passing). For that purpose, it's already suspended and the native
> method is close to what I'd like if it wasn't deprecated.
>
> You started this discussion by claiming that "The StackWalker API is a
> much better solution for code that is interested in the number of
> stack frames". Seems like a benchmark is a critical part of that
> claim. The stack walker approach looked 8x-ish slower for deep stacks
> (eg, 1000 and 5000), which is about what I expected given all the
> unnecessary object allocations. The walker API also seemed more prone
> to stack overflows, but I didn't take the time to quantify that.
> Here's one example run (java 11 with defaults):
>
> Benchmark             (stackDepth)  Mode  Cnt  Score   Error  Units
> StackWalkerJmh.count          1000  avgt    3  0.030 ? 0.002  ms/op
> StackWalkerJmh.count          5000  avgt    3  0.151 ? 0.015  ms/op
>
>
> Benchmark            (stackDepth)  Mode  Cnt  Score   Error  Units
> StackWalkerJmh.walk          1000  avgt    3  0.261 ? 0.027  ms/op
> StackWalkerJmh.walk          5000  avgt    3  1.313 ? 1.131  ms/op
>
>
>     @Benchmark
>     public int walk() { return recStackWalker(stackDepth); }
>     private static int recStackWalker(int depth) {
>         return depth == 0 ? getWalker() : recStackWalker(depth-1);
>     }
>     private static int getWalker() {
>         Count cc = new Count();
>         StackWalker.getInstance().forEach(x -> cc.count++);
>         return cc.count;
>     }
>     static class Count { int count; }
>     @Benchmark
>     public int count() { return recStackTrace(stackDepth); }
>     private static int recStackTrace(int depth) {
>         return depth == 0 ? getDepth() : recStackTrace(depth-1);
>     }
>     private static int getDepth() {
>         return Thread.currentThread().countStackFrames();
>     }
>
>
>
> What would be even more useful than stack depth would be an estimate
> of the number of bytes remaining in the stack, esp if it was fast. Any
> chance that that could get added to the stack walker API ?
>
>
>
>
>
>
>
>
>
> On Thu, Oct 24, 2019 at 4:21 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >
> > On 23/10/2019 23:00, seth lytle wrote:
> > > At least a couple appear to be recently active, though I don't have
> > > current access. Maybe an IDE generates boilerplate for proxies and
> > > ignores deprecation ?
> > >
> > > is the speed of the StackWalker approach to counting frames comparable
> > > to the current native method ?
> > >
> > countStackFrames has always been ill-defined, and it requires the thread
> > to be suspended. We've been directly people to StackWalker and several
> > releases so best to try it yourself and come back with your
> results/issues.
> >
> > -Alan
>

From mandy.chung at oracle.com  Thu Oct 24 19:34:13 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 24 Oct 2019 12:34:13 -0700
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <CAJtn+Ae_sU3P0wEFkgaheiZp096_qL5SfUD-W-e1tAAX7waLYg@mail.gmail.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
 <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
 <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>
 <CAJtn+AdkQpV_7PZszOAx82iyVKmwOqMyp3TT8w5x9mjNyA+P5A@mail.gmail.com>
 <2faf36a1-f1b9-5c1f-dabf-30caa457ad48@oracle.com>
 <CAJtn+Ae_sU3P0wEFkgaheiZp096_qL5SfUD-W-e1tAAX7waLYg@mail.gmail.com>
Message-ID: <db60e4aa-823b-d754-1583-f0937cf2dbfe@oracle.com>

There is cost to examine the stack frames.? The StackWalker API allows 
you to fetch the stack frames one batch at a time to avoid unnecessary 
deoptimization to frames that are not traversed.? In addition,it can 
specify to include/exclude the hidden frames and/or reflection 
implementation-specific frames.

It is true that there is more setup to do for StackWalker to count the 
frames.?? It's possible to provide a specialized stack walker 
implementation to optimize getting the stack depth where the object 
allocation can be eliminated (e.g. StackWalker::getCallerClass uses a 
specialized implementation for performance).? However, the stack depth 
is just a workaround for you.

BTW, you can call Stream::count to count the stack frames:
 ??? StackWalker.getInstance().walk(s -> { return s.count(); })

Mandy

On 10/24/19 9:32 AM, seth lytle wrote:
> The use case that's always interested me is checking to see if a
> callback to a recursive method (eg during parsing) is "too deep" so
> you can bail out (eg, to a non-recursive one or using message
> passing). For that purpose, it's already suspended and the native
> method is close to what I'd like if it wasn't deprecated.
>
> You started this discussion by claiming that "The StackWalker API is a
> much better solution for code that is interested in the number of
> stack frames". Seems like a benchmark is a critical part of that
> claim. The stack walker approach looked 8x-ish slower for deep stacks
> (eg, 1000 and 5000), which is about what I expected given all the
> unnecessary object allocations. The walker API also seemed more prone
> to stack overflows, but I didn't take the time to quantify that.
> Here's one example run (java 11 with defaults):
>
> Benchmark             (stackDepth)  Mode  Cnt  Score   Error  Units
> StackWalkerJmh.count          1000  avgt    3  0.030 ? 0.002  ms/op
> StackWalkerJmh.count          5000  avgt    3  0.151 ? 0.015  ms/op
>
>
> Benchmark            (stackDepth)  Mode  Cnt  Score   Error  Units
> StackWalkerJmh.walk          1000  avgt    3  0.261 ? 0.027  ms/op
> StackWalkerJmh.walk          5000  avgt    3  1.313 ? 1.131  ms/op
>
>
>      @Benchmark
>      public int walk() { return recStackWalker(stackDepth); }
>      private static int recStackWalker(int depth) {
>          return depth == 0 ? getWalker() : recStackWalker(depth-1);
>      }
>      private static int getWalker() {
>          Count cc = new Count();
>          StackWalker.getInstance().forEach(x -> cc.count++);
>          return cc.count;
>      }
>      static class Count { int count; }
>      @Benchmark
>      public int count() { return recStackTrace(stackDepth); }
>      private static int recStackTrace(int depth) {
>          return depth == 0 ? getDepth() : recStackTrace(depth-1);
>      }
>      private static int getDepth() {
>          return Thread.currentThread().countStackFrames();
>      }
>
>
>
> What would be even more useful than stack depth would be an estimate
> of the number of bytes remaining in the stack, esp if it was fast. Any
> chance that that could get added to the stack walker API ?
>
>
>
>
>
>
>
>
>
> On Thu, Oct 24, 2019 at 4:21 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 23/10/2019 23:00, seth lytle wrote:
>>> At least a couple appear to be recently active, though I don't have
>>> current access. Maybe an IDE generates boilerplate for proxies and
>>> ignores deprecation ?
>>>
>>> is the speed of the StackWalker approach to counting frames comparable
>>> to the current native method ?
>>>
>> countStackFrames has always been ill-defined, and it requires the thread
>> to be suspended. We've been directly people to StackWalker and several
>> releases so best to try it yourself and come back with your results/issues.
>>
>> -Alan


From Alan.Bateman at oracle.com  Thu Oct 24 19:41:23 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Oct 2019 20:41:23 +0100
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <CAJtn+Ae_sU3P0wEFkgaheiZp096_qL5SfUD-W-e1tAAX7waLYg@mail.gmail.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <4990bd03-d724-f441-46ae-537214b9a42d@oracle.com>
 <CAJtn+AcVpiy_9xJnD3v+vR4ge7iNzB07MEgHAUCQ6z5Y5g0Zhg@mail.gmail.com>
 <702b8f8f-6ca2-c187-840c-adbbcbcf3717@oracle.com>
 <CAJtn+AdkQpV_7PZszOAx82iyVKmwOqMyp3TT8w5x9mjNyA+P5A@mail.gmail.com>
 <2faf36a1-f1b9-5c1f-dabf-30caa457ad48@oracle.com>
 <CAJtn+Ae_sU3P0wEFkgaheiZp096_qL5SfUD-W-e1tAAX7waLYg@mail.gmail.com>
Message-ID: <4ef1d908-5fa4-6661-2c72-db1deb1efe75@oracle.com>

On 24/10/2019 17:32, seth lytle wrote:
> The use case that's always interested me is checking to see if a
> callback to a recursive method (eg during parsing) is "too deep" so
> you can bail out (eg, to a non-recursive one or using message
> passing). For that purpose, it's already suspended and the native
> method is close to what I'd like if it wasn't deprecated.
>
> You started this discussion by claiming that "The StackWalker API is a
> much better solution for code that is interested in the number of
> stack frames". Seems like a benchmark is a critical part of that
> claim. The stack walker approach looked 8x-ish slower for deep stacks
> (eg, 1000 and 5000), which is about what I expected given all the
> unnecessary object allocations. The walker API also seemed more prone
> to stack overflows, but I didn't take the time to quantify that.
> Here's one example run (java 11 with defaults):
Thread::countStackFrames is specified to throw 
IllegalThreadStateException when the thread is not suspended. The spec 
doesn't make an exception for the current thread. I just checked JDK 8 
and JDK 13 and Thread.currentThread().countStackFrames() throws the 
exception as specified. However, it seems the behavior flip flopped in 
the intervening releases due to changes to get it to work with 
Thread-SMR and then again when it was changed to use the TL handshake 
implementation. So I think you got lucky and the results would be 
different if there was thread suspension in the benchmark. Your initial 
paragraph mentions "already suspended" so maybe that is a different 
scenario.

It's good to push on StackWalker as there may be additional use-cases 
that need attention.


> :
>
> What would be even more useful than stack depth would be an estimate
> of the number of bytes remaining in the stack, esp if it was fast. Any
> chance that that could get added to the stack walker API ?
>
I don't think that needs a stack walk. It might be useful to start a new 
discussion to make a case for code that could potentially avoid SO. In 
the distant past there was a tiny number of cases in the JDK libraries 
that alloc'ed on the stack but it hasn't been needed in recent time 
(partly due to improvements in the stack banging and zones at the end of 
the stack, partly due to reduced use of the stack in the JNI methods).

-Alan

From alexander.matveev at oracle.com  Thu Oct 24 19:57:55 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 24 Oct 2019 12:57:55 -0700
Subject: RFR: JDK-8230612: Debian packaging ignores version and release in
 custom control file
In-Reply-To: <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
 <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
Message-ID: <b1c49180-3fad-ce7b-2b90-417a8d9eee15@oracle.com>

Looks good.

On 10/23/2019 6:59 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8230612
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8230612/webrev.00
>


From andy.herrick at oracle.com  Thu Oct 24 20:04:46 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 24 Oct 2019 16:04:46 -0400
Subject: RFR: JDK-8230612: Debian packaging ignores version and release in
 custom control file
In-Reply-To: <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
References: <da779006-33a4-ad88-70fb-a26e7846563e@oracle.com>
 <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
Message-ID: <c7da36e8-0abc-fd51-0188-2b1d263b0e30@oracle.com>

yes - this looks good.

/Andy

On 10/23/2019 9:59 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8230612
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8230612/webrev.00
>

From alexander.matveev at oracle.com  Thu Oct 24 20:52:01 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 24 Oct 2019 13:52:01 -0700
Subject: RFR: JDK-8223323: Adjust jpackage makefiles
In-Reply-To: <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
References: <1ed31b2f-15df-5c5c-39c2-0bef7b46d274@oracle.com>
 <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
Message-ID: <d790a92f-27ee-f86d-396b-39df084a6473@oracle.com>

Looks good.

On 10/23/2019 7:00 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223323
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8223323/webrev.00
>


From naoto.sato at oracle.com  Fri Oct 25 00:51:47 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 24 Oct 2019 17:51:47 -0700
Subject: [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
Message-ID: <4888a600-dfac-cd08-aa05-54255cdb4cfe@oracle.com>

Ping.

Naoto

On 10/9/19 3:39 PM, naoto.sato at oracle.com wrote:
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8231273
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
> 
> The webrev is huge, but majority of the changes is just to replace the 
> CLDR source locale data from version 35.1 to 36. The real code changes 
> are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
> handles aliases for currency/percent formats, and retrieves per-element 
> fallback strings for compact number patterns. Also relevant tests are 
> modified accordingly.
> 
> Naoto

From brent.christian at oracle.com  Fri Oct 25 05:28:39 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 24 Oct 2019 22:28:39 -0700
Subject: RFR: 8226297: Dual-pivot quicksort improvements
In-Reply-To: <1571916622.27188505@f495.i.mail.ru>
References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com>
 <b5379549-2d67-9c3c-ab8a-56accd5477db@oracle.com>
 <2fa64524-6d9d-6b24-0a86-00d3a0512d1b@oracle.com>
 <1571916622.27188505@f495.i.mail.ru>
Message-ID: <51760ebd-bb9f-cdfb-6c2e-61fa644e07c6@oracle.com>

Hi, Vladimir

Thanks for the explanation of the changes to LONG_RUN_LENGTHS and 
SHORT_RUN_LENGTHS.

I've incorporated the other suggested changes:
http://cr.openjdk.java.net/~bchristi/8226297/webrev10/

-Brent

On 10/24/19 4:30 AM, Vladimir Yaroslavskiy wrote:
> Hi?Brent,
> 
> See my comments inline
> 
>     Oct 24? 2019, 7:42 +03:00 ?? Brent Christian
>     <brent.christian at oracle.com>:
> 
>     Hi,
> 
>     I've created a webrev of the latest test changes that Vladimir sent me:
> 
>     http://cr.openjdk.java.net/~bchristi/8226297/webrev09-testUpdate/
> 
>     (I also created an incremental webrev[1] along the way, in case that's
>     helpful to anyone).
> 
>     I have just a few comments:
> 
>     test/jdk/java/util/Arrays/Sorting.java
> 
>     * I found some instances of "FloatPointing", which I've already changed
>     to "FloatingPoint". :)
> 
>     --
> 
> 
> Thank you for correction.
> 
> 
>      ??????// Array lengths used in a long run (default)
>      ??????private static final int[] LONG_RUN_LENGTHS = {
>     - 1, 2, 3, 5, 8, 13, 21, 34, 55, 100, 1000, 10000, 100000, 1000000 };
>     + 1, 3, 8, 21, 55, 100, 1_000, 10_000, 100_000 };
> 
>      ??????// Array lengths used in a short run
>      ??????private static final int[] SHORT_RUN_LENGTHS = {
>     - 1, 2, 3, 21, 55, 1000, 10000 };
>     + 1, 8, 55, 100, 10_000 };
> 
>     Vladimir, can you tell me why some of the length values have been
>     removed?
> 
>     --
> 
> 
> Different sorting algorithms are invoked depending on input size. Insertion
> sort is run on small arrays, but, for example, sizes 5 and 8 are similar for
> insertion sort. Therefore, the list contains few small sizes only. Larger
> sizes are used for Quicksort, merging sort, parallel sort.
> 
> There was requirement to have fast runs (short and long) as much as 
> possible.
> Testing with 1M elements took almost all time, but didn't invoke new 
> functionality.
> I removed 1M and time of long run was down from 10 min to 2.5 min, short run
> takes about 5-7 sec instead of 15-20 sec.
> 
> As a result, I achieved reasonable testing time with coverage of all cases,
> excluding checks like, throw new IllegalArgumentException("Unknown type 
> of array...
> 
> 
>     1570 private static enum TypeConverter {
>     ...
>     1637 abstract void convert(Object src, Object dst);
> 
>     The 'src' argument to convert is always cast to an int[]. Can it be
>     made an int[] in the method signature, instead of Object ? I can make
>     the change if that sounds good.
> 
> 
> Good catch! Please, switch to?void convert(int[] a, Object dst)
> and remove?int[] a = (int[]) src; from all implementation methods.
> 
> And could you also please delete unnecessary code?
> 
> Lines 1509-1510:
> 
> if (src instanceof int[]) {
>  ? ? ?copy((int[]) dst, (int[]) src);
> in method?private void copy(Object dst, Object src)
> 
> and then whole method?at lines 1520-1522:
> private void copy(int[] dst, int[] src)
> 
> Method copy is invoked on float/double arrays only,
> not necessary to compare with int[].
> 
> Thanks,
> Vladimir
> 
> 
>     Other than those, this is pretty much ready to go.
> 
>     Thanks,
>     -Brent
> 
>     1. http://cr.openjdk.java.net/~bchristi/8226297/webrev09-incremental/
> 
>     On 10/8/19 5:41 PM, Brent Christian wrote:
>      > Hi, Vladimir
>      >
>      > On 10/8/19 3:18 PM, Vladimir Yaroslavskiy wrote:
>      >>
>      >> The following renaming changes are important
>      >> and should be kept. My explanation is here
>      > > ...
>      >
>      > Thanks for the explanation - much appreciated.
>      >
>      >> * Other changes, like failed -> fail, i++ -> ++i,
>      >> and TypeConverter, FloatBuilder, DoubleBuilder, SortedBuilder
>      >> to be non-static can be reverted.
>      >>
>      >> I can revert them, if you agree.
>      >
>      > That would be great, thanks.
>      >
>      >> ??? * I like that the various DualPivotQuickSort methods are tested
>      >> ??? directly (via SortingHelper). I'd prefer that we also
>     continue testing
>      >> ??? direct calls to Arrays.sort(), as that's what users will
>     call. What
>      >> ??? would be the best way to add that back in? (Maybe a
>     SortingHelper
>      >> ??? variant that calls Arrays.sort()?).
>      >>
>      >> I will add direct calls to Arrays.sort() and
>     Arrays.parallelSort() also.
>      >
>      > Great, thank you.
>      >
>      >> ??? * Having the test operation depend on setting various values
>     to the
>      >> ??? static 'sortingHelper' field seems brittle to me. This could
>     be a good
>      >> ??? opportunity to convert from static to instance methods, make
>      >> ??? 'sortingHelper' and 'name' member variables, and create separate
>      >> ??? Sorting
>      >> ??? objects for each SortingHelper. Such a refactoring is not
>     strictly
>      >> ??? necessary, but I think it would be nice to have.
>      >>
>      >> Good idea, I will implement it and send you update version very
>     soon.
>      >
>      > Sounds good!
>      >
>      >>> ??? test/jdk/java/util/Arrays/FailedFloat.java
>      >>>
>      >>> ??? Is this test necessary, given the addition of
>      >>> ??? testFloatNegativeZero() in
>      >>> ??? Sorting.java ?
>      >>
>      >> Not necessary, because testFloatNegativeZero() covers this case.
>      >> This class was created to reproduce bug when float-pointing zeros
>      >> and NaNs are sorted.
>      >>
>      >> Please remove FailedFloat.java. It makes sense to add the source of
>      >> this class to 8226297.
>      >
>      > Done and done.
>      >
>      > -Brent
> 

From brent.christian at oracle.com  Fri Oct 25 05:28:53 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 24 Oct 2019 22:28:53 -0700
Subject: Checking instanceof in DualPivotQuicksort
In-Reply-To: <1571919081.256114976@f562.i.mail.ru>
References: <1571919081.256114976@f562.i.mail.ru>
Message-ID: <2eb27ec4-92fe-1e89-4886-ead25e9974b1@oracle.com>

Hi, Vladimir

I'd prefer to keep the code as is.  Perhaps the exception could help 
some other future maintainer to pinpoint a problem with a potential change.

-Brent

On 10/24/19 5:11 AM, Vladimir Yaroslavskiy wrote:
> Hi Brent,
> 
> Looking at coverage of DualPivotQuicksort class, I found that
> cases of unexpected type of given array are not invoked at all
> (mentioned in my previous email).
> 
> I think that these "else" can be removed, because method
> compute() of private classes are invoked from DualPivotQuicksort
> class only and we can guarantee valid array types (int[], .. , double[]).
> 
> If you agree, could you please, remove such cases?
> 
> Replace lines 4147-4148:
> 
> throw new IllegalArgumentException(
>      "Unknown type of array: " + a.getClass().getName());
> 
> by return null;
> 
> remove lines 4099-4101:
> 
> } else {
>      throw new IllegalArgumentException(
>          "Unknown type of array: " + dst.getClass().getName());
> 
> and remove lines 4030-4033:
> 
> } else {
>      throw new IllegalArgumentException(
>          "Unknown type of array: " + a.getClass().getName());
> 
> -----
> 
> And doe the same for Sorting class: remove 12 cases
> fail("Unknown type of array: " + ....
> 
> Thank you,
> Vladimir
> 

From lance.andersen at oracle.com  Fri Oct 25 18:42:06 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 25 Oct 2019 14:42:06 -0400
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <e9ac1780-d5f9-aad9-31f2-c5b2b191c162@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
 <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>
 <fe6bf497-b192-256b-8542-2face7386931@oracle.com>
 <2E75AAD1-960A-4D75-A400-88FEDBD1D38E@oracle.com>
 <e9ac1780-d5f9-aad9-31f2-c5b2b191c162@oracle.com>
Message-ID: <C2055E62-461C-4363-9153-B52747E6B14F@oracle.com>


> On Oct 23, 2019, at 4:58 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 23/10/2019 19:06, Lance Andersen wrote:
>> 
>>> On Oct 22, 2019, at 2:37 PM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>> 
>>> I assume skip(Long.MAX_VALUE) will cause n+pos to overflow and it will skip backwards rather than to the end.
>> 
>> That is correct.  If you prefer it to skip to the end, I will adjust accordingly.
> It would be surprising to specify a positive value and have it skip backwards so I think this should be fixed.

I have updated the patch per your suggestion.

The updated webrev can be found at: http://cr.openjdk.java.net/~lancea/8231451/webrev.02/index.html <http://cr.openjdk.java.net/~lancea/8231451/webrev.02/index.html>

mach5 jdk-tier1 through jdk-tier3 are clean.

Best
Lance
> 
> -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 Roger.Riggs at oracle.com  Fri Oct 25 18:57:50 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Oct 2019 14:57:50 -0400
Subject: [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
Message-ID: <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>

HI Naoto,

cldrconverter/Bundle.java:

233-246:? If there is a parent list, it seems to ignore/drop patterns 
greater than plist.size().
This would be clearer if it always processed all the patterns and used 
the parent
if the pattern[i] was empty and i < plist.size().? Switching around the 
range size leads to confusion.
(Or I misunderstand the intent).

Is the algorithm intended to produce the longest list (parent and pattern)?

Otherwise, looks fine.

Thanks, Roger



On 10/9/19 6:39 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8231273
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
>
> The webrev is huge, but majority of the changes is just to replace the 
> CLDR source locale data from version 35.1 to 36. The real code changes 
> are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
> handles aliases for currency/percent formats, and retrieves 
> per-element fallback strings for compact number patterns. Also 
> relevant tests are modified accordingly.
>
> Naoto


From TobiasDiez at gmx.de  Fri Oct 25 16:20:59 2019
From: TobiasDiez at gmx.de (Tobias Diez)
Date: Fri, 25 Oct 2019 18:20:59 +0200
Subject: [JPackage] Launcher should support command line arguments
Message-ID: <000801d58b50$3002ebc0$9008c340$@gmx.de>

Hello everybody,

currently, the default launcher generated by jpackage does not accept
command line arguments. On the other hand, the console launcher
(--win-console) allows to specify command line arguments but then a command
line window is kept open (which is fine for command line applications but
not for gui applications). Thus, what is missing is a launcher that admits
command line arguments without keeping the cmd window open.

It would be nice if this feature could be added. I guess it is quite common
that gui applications also admit cmd arguments.

Best regards
Tobias


From mandy.chung at oracle.com  Fri Oct 25 19:29:31 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 25 Oct 2019 12:29:31 -0700
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <fb835ceb-6a5b-2803-22e0-50da6d19d3ca@loongson.cn>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
 <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>
 <2f4b97f6-3839-87ae-44d2-70f03bef9945@oracle.com>
 <fb835ceb-6a5b-2803-22e0-50da6d19d3ca@loongson.cn>
Message-ID: <843adb6a-41a4-a336-bfff-2b7fa4cf2086@oracle.com>



On 10/23/19 11:21 PM, Jie Fu wrote:
> Hi Mandy,
>
> Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.02/
> It seems better now.
>
It's better while I think this can be further simplified.

line 101 to 217 involves iterating on the default sets/map and then
create a new TreeSet and TreeMap and then process the config file.

Currently addDMHMethodType validates the methodType and then adds
to dmhMethods which ensures that the map entry value is a sorted set.
So we can add one new method to add an entry to speciesTypes,
invokeTypes and callSiteTypes which performs the validation and then
add to the corresponding collection.

I think that way the code will be cleaner.  Below is something for
your reference.

Mandy

diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
--- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
+++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
@@ -75,13 +75,13 @@
      private static final JavaLangInvokeAccess JLIA
              = SharedSecrets.getJavaLangInvokeAccess();
  
-    Set<String> speciesTypes = Set.of();
+    private final TreeSet<String> speciesTypes = new TreeSet<>();
  
-    Set<String> invokerTypes = Set.of();
+    private final TreeSet<String> invokerTypes = new TreeSet<>();
  
-    Set<String> callSiteTypes = Set.of();
+    private final TreeSet<String> callSiteTypes = new TreeSet<>();
  
-    Map<String, Set<String>> dmhMethods = Map.of();
+    private final Map<String, Set<String>> dmhMethods = new TreeMap<>();
  
      String mainArgument;
  
@@ -187,21 +187,31 @@
          mainArgument = config.get(NAME);
      }

+    private void addSpeciesType(String type) {
+        speciesTypes.add(expandSignature(type));
+    }
+
+    private void addInvokerType(String methodType) {
+        validateMethodType(methodType);
+        invokerTypes.add(methodType);
+    }
+
+    private void addCallSisterType(String csType) {
+        validateMethodType(csType);
+        callSiteTypes.add(csType);
+    }
+
      public void initialize(ResourcePool in) {
          // Start with the default configuration
-        speciesTypes = defaultSpecies().stream()
-                .map(type -> expandSignature(type))
-                .collect(Collectors.toSet());
+        defaultSpecies().stream().forEach(this::addSpeciesType);
  
-        invokerTypes = defaultInvokers();
-        validateMethodTypes(invokerTypes);
+        defaultInvokers().stream().forEach(this::validateMethodType);
  
-        callSiteTypes = defaultCallSiteTypes();
+        defaultCallSiteTypes().stream().forEach(this::addCallSisterType);
  
-        dmhMethods = defaultDMHMethods();
-        for (Set<String> dmhMethodTypes : dmhMethods.values()) {
-            validateMethodTypes(dmhMethodTypes);
-        }
+        defaultDMHMethods().entrySet().stream().forEach(e -> {
+            e.getValue().stream().forEach(type -> addDMHMethodType(e.getKey(), type))
+        });
  
          // Extend the default configuration with the contents in the supplied
          // input file - if none was supplied we look for the default file
@@ -225,18 +235,6 @@
      }

  
      private void readTraceConfig(Stream<String> lines) {
-        // Use TreeSet/TreeMap to keep things sorted in a deterministic
-        // order to avoid scrambling the layout on small changes and to
-        // ease finding methods in the generated code
-        speciesTypes = new TreeSet<>(speciesTypes);
-        invokerTypes = new TreeSet<>(invokerTypes);
-        callSiteTypes = new TreeSet<>(callSiteTypes);
-
-        TreeMap<String, Set<String>> newDMHMethods = new TreeMap<>();
-        for (Map.Entry<String, Set<String>> entry : dmhMethods.entrySet()) {
-            newDMHMethods.put(entry.getKey(), new TreeSet<>(entry.getValue()));
-        }
-        dmhMethods = newDMHMethods;
          lines.map(line -> line.split(" "))
               .forEach(parts -> {
                  switch (parts[0]) {
@@ -245,19 +243,18 @@
                          if (parts.length == 3 && parts[1].startsWith("java.lang.invoke.BoundMethodHandle$Species_")) {
                              String species = parts[1].substring("java.lang.invoke.BoundMethodHandle$Species_".length());
                              if (!"L".equals(species)) {
-                                speciesTypes.add(expandSignature(species));
+                                addSpeciesType(species);
                              }
                          }
                          break;
                      case "[LF_RESOLVE]":
                          String methodType = parts[3];
-                        validateMethodType(methodType);
                          if (parts[1].equals(INVOKERS_HOLDER_NAME)) {
                              if ("linkToTargetMethod".equals(parts[2]) ||
                                      "linkToCallSite".equals(parts[2])) {
-                                callSiteTypes.add(methodType);
+                                addCallSisterType(methodType);
                              } else {
-                                invokerTypes.add(methodType);
+                                addInvokerType(methodType);
                              }
                          } else if (parts[1].contains("DirectMethodHandle")) {
                              String dmh = parts[2];
@@ -291,12 +288,6 @@
          }
      }
  
-    private void validateMethodTypes(Set<String> dmhMethodTypes) {
-        for (String type : dmhMethodTypes) {
-            validateMethodType(type);
-        }
-    }

      private void validateMethodType(String type) {
          String[] typeParts = type.split("_");
          // check return type (second part)
@@ -338,12 +329,6 @@
  
          // Generate LambdaForm Holder classes
          generateHolderClasses(out);
-
-        // Let it go
-        speciesTypes = null;
-        invokerTypes = null;
-        dmhMethods = null;
-
          return out.build();
      }


From lance.andersen at oracle.com  Fri Oct 25 22:55:21 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 25 Oct 2019 18:55:21 -0400
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <c41e32d1-6a57-6adf-5e13-b98bd6abc299@gmail.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
 <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>
 <c41e32d1-6a57-6adf-5e13-b98bd6abc299@gmail.com>
Message-ID: <0C89C862-149F-4C15-A03B-214C90698B8B@oracle.com>

Hi Jaikiran,

Thank you for your patch.


The change to Zip FS looks good.  I re-worked the test so that it also runs against ZipFile (which uses the CEN vs the LOC) and Zip FS in addition to ZipInputStream for extra coverage.

The webrev can be found at: http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html>

I have run the patch and test via Mach5 and jdk-tier1 through jdk-tier3 are clean.

Have a good weekend.

Best
Lance
> On Oct 23, 2019, at 10:47 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Thank you Lance.
> 
> -Jaikiran
> On 24/10/19 1:17 AM, Lance Andersen wrote:
>> Hi Jaikiran,
>> 
>> I will take a look and once we are good with the review, I can sponsor it.
>> 
>> Best
>> Lance
>>> On Oct 23, 2019, at 7:24 AM, Jaikiran Pai <jai.forums2013 at gmail.com <mailto:jai.forums2013 at gmail.com>> wrote:
>>> 
>>> Can I please get a review and a sponsor for a potential fix for
>>> JDK-8232879[1]? The patch is available as a webrev at [2].
>>> 
>>> What's happening in there is that the
>>> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the
>>> one arg write(byte b) method and calling the super.write(b) and then
>>> doing a crc.update. The super.write(b)
>>> (java.util.zip.DeflaterOutputStream in this case) actually internally
>>> calls the 3 arg write(b, offset, length) which is overriding by this
>>> jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream. In its
>>> implementation of write(b, offset, length), in addition to (rightly)
>>> calling super.write(b, offset, length), this method also updates the CRC
>>> (again). So this ends up updating the CRC multiple times when the single
>>> arg write is invoked.
>>> 
>>> The patch now removes this overridden implementation of write(b) in the
>>> DeflatingEntryOutputStream so that the call is handled by the
>>> java.util.zip.DeflaterOutputStream. Although there's no @implNote on
>>> java.util.zip.DeflaterOutputStream#write(byte b) static that it's
>>> (always) going to call the 3 arg write(b, offset, length) method, the
>>> implementation as of now does indeed do that. So I guess, its probably
>>> OK to rely on that knowledge and get rid of this overridden write(b)
>>> method instead of coming up with a bit more complicated fix.
>>> 
>>> The patch also includes a jtreg testcase which reproduces this issues
>>> and verifies the fix.
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232879 <https://bugs.openjdk.java.net/browse/JDK-8232879>
>>> 
>>> [2] https://cr.openjdk.java.net/~jpai/webrev/8232879/1/webrev/ <https://cr.openjdk.java.net/~jpai/webrev/8232879/1/webrev/>
>>> 
>>> -Jaikiran
>>> 
>>> 
>> 
>> <oracle_sig_logo.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>
>> 
>> 
>> 

 <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 naoto.sato at oracle.com  Fri Oct 25 23:31:00 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 25 Oct 2019 16:31:00 -0700
Subject: [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
 <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>
Message-ID: <84da6f28-9c7b-7487-efe8-7e6ab47c5fa3@oracle.com>

Hi Roger,

Thanks for the review.

On 10/25/2019 AD 11:57 ??, Roger Riggs wrote:
> HI Naoto,
> 
> cldrconverter/Bundle.java:
> 
> 233-246:? If there is a parent list, it seems to ignore/drop patterns 
> greater than plist.size().
> This would be clearer if it always processed all the patterns and used 
> the parent
> if the pattern[i] was empty and i < plist.size().? Switching around the 
> range size leads to confusion.
> (Or I misunderstand the intent).

The code assumed that parents' lists are always longer than self, which 
is true, but you are right that it can be more readable. Corrected as 
follows:

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

Bundle:233-246 is the only change since 00.

> 
> Is the algorithm intended to produce the longest list (parent and pattern)?

Since at runtime, there's no way to fallback element by element basis, 
the array should always contain all the elements (i.e., longest) possible.

Naoto

> 
> Otherwise, looks fine.
> 
> Thanks, Roger
> 
> 
> 
> On 10/9/19 6:39 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8231273
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
>>
>> The webrev is huge, but majority of the changes is just to replace the 
>> CLDR source locale data from version 35.1 to 36. The real code changes 
>> are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
>> handles aliases for currency/percent formats, and retrieves 
>> per-element fallback strings for compact number patterns. Also 
>> relevant tests are modified accordingly.
>>
>> Naoto
> 

From jai.forums2013 at gmail.com  Sat Oct 26 02:10:00 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 26 Oct 2019 07:40:00 +0530
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <0C89C862-149F-4C15-A03B-214C90698B8B@oracle.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
 <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>
 <c41e32d1-6a57-6adf-5e13-b98bd6abc299@gmail.com>
 <0C89C862-149F-4C15-A03B-214C90698B8B@oracle.com>
Message-ID: <70df8a2b-5e00-a13c-3179-c98f3b3f8ddb@gmail.com>

Thank you for the review, Lance.

On 26/10/19 4:25 AM, Lance Andersen wrote:
>
> The change to Zip FS looks good. ?I re-worked the test so that it also
> runs against ZipFile (which uses the CEN vs the LOC) and Zip FS in
> addition to ZipInputStream for extra coverage.
>
> The webrev can be found
> at:?http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html

Looks fine. A very minor note about
http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zipfs/CRCWriteTest.java.html

136                 while ((ze = zis.getNextEntry()) != null) {
 137                     assertNotNull(ze);

Looks like an oversight - that assertNotNull(ze) on 137 isn't needed due to the != null check on 136.

-Jaikiran


From fujie at loongson.cn  Sat Oct 26 02:34:37 2019
From: fujie at loongson.cn (Jie Fu)
Date: Sat, 26 Oct 2019 10:34:37 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <843adb6a-41a4-a336-bfff-2b7fa4cf2086@oracle.com>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
 <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>
 <2f4b97f6-3839-87ae-44d2-70f03bef9945@oracle.com>
 <fb835ceb-6a5b-2803-22e0-50da6d19d3ca@loongson.cn>
 <843adb6a-41a4-a336-bfff-2b7fa4cf2086@oracle.com>
Message-ID: <5de8fdf2-b90d-d828-93e5-5b99f48f79cf@loongson.cn>

Hi Mandy,

Thanks for your review and help.
I think your refactoring is a nice improvement.

Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.03/
It seems much better now.

Testing:
 ?- make test TEST="tier1 tier2 tier3" CONF=release

Thanks a lot.
Best regards,
Jie

On 2019/10/26 ??3:29, Mandy Chung wrote:
>
>
> On 10/23/19 11:21 PM, Jie Fu wrote:
>> Hi Mandy,
>>
>> Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.02/
>> It seems better now.
>>
> It's better while I think this can be further simplified.
>
> line 101 to 217 involves iterating on the default sets/map and then
> create a new TreeSet and TreeMap and then process the config file.
>
> Currently addDMHMethodType validates the methodType and then adds
> to dmhMethods which ensures that the map entry value is a sorted set.
> So we can add one new method to add an entry to speciesTypes,
> invokeTypes and callSiteTypes which performs the validation and then
> add to the corresponding collection.
>
> I think that way the code will be cleaner.  Below is something for
> your reference.
>
> Mandy
>
> diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
> --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
> +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
> @@ -75,13 +75,13 @@
>       private static final JavaLangInvokeAccess JLIA
>               = SharedSecrets.getJavaLangInvokeAccess();
>   
> -    Set<String> speciesTypes = Set.of();
> +    private final TreeSet<String> speciesTypes = new TreeSet<>();
>   
> -    Set<String> invokerTypes = Set.of();
> +    private final TreeSet<String> invokerTypes = new TreeSet<>();
>   
> -    Set<String> callSiteTypes = Set.of();
> +    private final TreeSet<String> callSiteTypes = new TreeSet<>();
>   
> -    Map<String, Set<String>> dmhMethods = Map.of();
> +    private final Map<String, Set<String>> dmhMethods = new TreeMap<>();
>   
>       String mainArgument;
>   
> @@ -187,21 +187,31 @@
>           mainArgument = config.get(NAME);
>       }
>
> +    private void addSpeciesType(String type) {
> +        speciesTypes.add(expandSignature(type));
> +    }
> +
> +    private void addInvokerType(String methodType) {
> +        validateMethodType(methodType);
> +        invokerTypes.add(methodType);
> +    }
> +
> +    private void addCallSisterType(String csType) {
> +        validateMethodType(csType);
> +        callSiteTypes.add(csType);
> +    }
> +
>       public void initialize(ResourcePool in) {
>           // Start with the default configuration
> -        speciesTypes = defaultSpecies().stream()
> -                .map(type -> expandSignature(type))
> -                .collect(Collectors.toSet());
> +        defaultSpecies().stream().forEach(this::addSpeciesType);
>   
> -        invokerTypes = defaultInvokers();
> -        validateMethodTypes(invokerTypes);
> +        defaultInvokers().stream().forEach(this::validateMethodType);
>   
> -        callSiteTypes = defaultCallSiteTypes();
> +        defaultCallSiteTypes().stream().forEach(this::addCallSisterType);
>   
> -        dmhMethods = defaultDMHMethods();
> -        for (Set<String> dmhMethodTypes : dmhMethods.values()) {
> -            validateMethodTypes(dmhMethodTypes);
> -        }
> +        defaultDMHMethods().entrySet().stream().forEach(e -> {
> +            e.getValue().stream().forEach(type -> addDMHMethodType(e.getKey(), type))
> +        });
>   
>           // Extend the default configuration with the contents in the supplied
>           // input file - if none was supplied we look for the default file
> @@ -225,18 +235,6 @@
>       }
>
>   
>       private void readTraceConfig(Stream<String> lines) {
> -        // Use TreeSet/TreeMap to keep things sorted in a deterministic
> -        // order to avoid scrambling the layout on small changes and to
> -        // ease finding methods in the generated code
> -        speciesTypes = new TreeSet<>(speciesTypes);
> -        invokerTypes = new TreeSet<>(invokerTypes);
> -        callSiteTypes = new TreeSet<>(callSiteTypes);
> -
> -        TreeMap<String, Set<String>> newDMHMethods = new TreeMap<>();
> -        for (Map.Entry<String, Set<String>> entry : dmhMethods.entrySet()) {
> -            newDMHMethods.put(entry.getKey(), new TreeSet<>(entry.getValue()));
> -        }
> -        dmhMethods = newDMHMethods;
>           lines.map(line -> line.split(" "))
>                .forEach(parts -> {
>                   switch (parts[0]) {
> @@ -245,19 +243,18 @@
>                           if (parts.length == 3 && parts[1].startsWith("java.lang.invoke.BoundMethodHandle$Species_")) {
>                               String species = parts[1].substring("java.lang.invoke.BoundMethodHandle$Species_".length());
>                               if (!"L".equals(species)) {
> -                                speciesTypes.add(expandSignature(species));
> +                                addSpeciesType(species);
>                               }
>                           }
>                           break;
>                       case "[LF_RESOLVE]":
>                           String methodType = parts[3];
> -                        validateMethodType(methodType);
>                           if (parts[1].equals(INVOKERS_HOLDER_NAME)) {
>                               if ("linkToTargetMethod".equals(parts[2]) ||
>                                       "linkToCallSite".equals(parts[2])) {
> -                                callSiteTypes.add(methodType);
> +                                addCallSisterType(methodType);
>                               } else {
> -                                invokerTypes.add(methodType);
> +                                addInvokerType(methodType);
>                               }
>                           } else if (parts[1].contains("DirectMethodHandle")) {
>                               String dmh = parts[2];
> @@ -291,12 +288,6 @@
>           }
>       }
>   
> -    private void validateMethodTypes(Set<String> dmhMethodTypes) {
> -        for (String type : dmhMethodTypes) {
> -            validateMethodType(type);
> -        }
> -    }
>
>       private void validateMethodType(String type) {
>           String[] typeParts = type.split("_");
>           // check return type (second part)
> @@ -338,12 +329,6 @@
>   
>           // Generate LambdaForm Holder classes
>           generateHolderClasses(out);
> -
> -        // Let it go
> -        speciesTypes = null;
> -        invokerTypes = null;
> -        dmhMethods = null;
> -
>           return out.build();
>       }
>

From lance.andersen at oracle.com  Sat Oct 26 02:41:52 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 25 Oct 2019 22:41:52 -0400
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <70df8a2b-5e00-a13c-3179-c98f3b3f8ddb@gmail.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
 <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>
 <c41e32d1-6a57-6adf-5e13-b98bd6abc299@gmail.com>
 <0C89C862-149F-4C15-A03B-214C90698B8B@oracle.com>
 <70df8a2b-5e00-a13c-3179-c98f3b3f8ddb@gmail.com>
Message-ID: <671B8247-977A-4140-898D-7551E23597DD@oracle.com>


> On Oct 25, 2019, at 10:10 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Thank you for the review, Lance.
> 

You are very welcome Jaikiran.
> On 26/10/19 4:25 AM, Lance Andersen wrote:
>> 
>> The change to Zip FS looks good.  I re-worked the test so that it also runs against ZipFile (which uses the CEN vs the LOC) and Zip FS in addition to ZipInputStream for extra coverage.
>> 
>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html>Looks fine. A very minor note about http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zipfs/CRCWriteTest.java.html <http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zipfs/CRCWriteTest.java.html>
> 136                 while ((ze = zis.getNextEntry()) != null) {
>  137                     assertNotNull(ze);
> 
> Looks like an oversight - that assertNotNull(ze) on 137 isn't needed due to the != null check on 1

Yep, not needed.  Sometimes you do things on auto pilot ;-)

Will remove before I push the change.
> 36.
> 
> -Jaikiran
> 

 <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 alexey.semenyuk at oracle.com  Sat Oct 26 02:56:11 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 25 Oct 2019 22:56:11 -0400
Subject: [JPackage] Launcher should support command line arguments
In-Reply-To: <000801d58b50$3002ebc0$9008c340$@gmx.de>
References: <000801d58b50$3002ebc0$9008c340$@gmx.de>
Message-ID: <cb3bf823-4e5c-592c-5936-67d6fe801a75@oracle.com>

HI Tobias,

What build of jpackage do you use?
There should be no such issue in recent jpackage builds. Please check 
https://jdk.java.net/jpackage/ for the latest EA JDK build with jpackage.

- Alexey

On 10/25/2019 12:20 PM, Tobias Diez wrote:
> Hello everybody,
>
> currently, the default launcher generated by jpackage does not accept
> command line arguments. On the other hand, the console launcher
> (--win-console) allows to specify command line arguments but then a command
> line window is kept open (which is fine for command line applications but
> not for gui applications). Thus, what is missing is a launcher that admits
> command line arguments without keeping the cmd window open.
>
> It would be nice if this feature could be added. I guess it is quite common
> that gui applications also admit cmd arguments.
>
> Best regards
> Tobias
>


From christoph.langer at sap.com  Mon Oct 28 10:19:19 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 28 Oct 2019 10:19:19 +0000
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <671B8247-977A-4140-898D-7551E23597DD@oracle.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
 <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>
 <c41e32d1-6a57-6adf-5e13-b98bd6abc299@gmail.com>
 <0C89C862-149F-4C15-A03B-214C90698B8B@oracle.com>
 <70df8a2b-5e00-a13c-3179-c98f3b3f8ddb@gmail.com>
 <671B8247-977A-4140-898D-7551E23597DD@oracle.com>
Message-ID: <AM6PR02MB4801ED3F384E354DD004481C8A660@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Lance,

thanks for reworking the test. That definitely improves coverage.

The comment for the test method (line 56/57) could be improved like: "Verify all write methods of an OutputStream that can be used to write to an entry of Zip Filesystem by exercising all of them when creating an archive and then traversing the archive with ZipFile, ZipInputStream and the Zip Filesystem".

Other than that, it's good to go for mw.

BTW, I think meanwhile all these zipfs tests have quite some duplicate infrastructure classes and methods (e.g. Entry) that could be shared. Maybe we should try to carve out some stuff into a library or some Auxillary helper class. What do you think?

Thanks
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Lance Andersen
> Sent: Samstag, 26. Oktober 2019 04:42
> To: Jaikiran Pai <jai.forums2013 at gmail.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
> leads to a CRC failure in the generated jar file
> 
> 
> > On Oct 25, 2019, at 10:10 PM, Jaikiran Pai <jai.forums2013 at gmail.com>
> wrote:
> >
> > Thank you for the review, Lance.
> >
> 
> You are very welcome Jaikiran.
> > On 26/10/19 4:25 AM, Lance Andersen wrote:
> >>
> >> The change to Zip FS looks good.  I re-worked the test so that it also runs
> against ZipFile (which uses the CEN vs the LOC) and Zip FS in addition to
> ZipInputStream for extra coverage.
> >>
> >> The webrev can be found at:
> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html
> <http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html>Looks
> fine. A very minor note about
> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zip
> fs/CRCWriteTest.java.html
> <http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zi
> pfs/CRCWriteTest.java.html>
> > 136                 while ((ze = zis.getNextEntry()) != null) {
> >  137                     assertNotNull(ze);
> >
> > Looks like an oversight - that assertNotNull(ze) on 137 isn't needed due to
> the != null check on 1
> 
> Yep, not needed.  Sometimes you do things on auto pilot ;-)
> 
> Will remove before I push the change.
> > 36.
> >
> > -Jaikiran
> >
> 
>  <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 Oct 28 10:40:40 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 28 Oct 2019 10:40:40 +0000
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <C2055E62-461C-4363-9153-B52747E6B14F@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
 <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>
 <fe6bf497-b192-256b-8542-2face7386931@oracle.com>
 <2E75AAD1-960A-4D75-A400-88FEDBD1D38E@oracle.com>
 <e9ac1780-d5f9-aad9-31f2-c5b2b191c162@oracle.com>
 <C2055E62-461C-4363-9153-B52747E6B14F@oracle.com>
Message-ID: <AM6PR02MB4801827DFF132C2265E548218A660@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Lance,

I looked at this patch as well and it seems good to me.

Cheers
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Lance Andersen
> Sent: Freitag, 25. Oktober 2019 20:42
> To: Alan Bateman <Alan.Bateman at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR 8231451: ZipFileInputStream::skip handling of negative
> values with STORED entries
> 
> 
> > On Oct 23, 2019, at 4:58 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >
> > On 23/10/2019 19:06, Lance Andersen wrote:
> >>
> >>> On Oct 22, 2019, at 2:37 PM, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
> >>>
> >>> I assume skip(Long.MAX_VALUE) will cause n+pos to overflow and it will
> skip backwards rather than to the end.
> >>
> >> That is correct.  If you prefer it to skip to the end, I will adjust accordingly.
> > It would be surprising to specify a positive value and have it skip backwards
> so I think this should be fixed.
> 
> I have updated the patch per your suggestion.
> 
> The updated webrev can be found at:
> http://cr.openjdk.java.net/~lancea/8231451/webrev.02/index.html
> <http://cr.openjdk.java.net/~lancea/8231451/webrev.02/index.html>
> 
> mach5 jdk-tier1 through jdk-tier3 are clean.
> 
> Best
> Lance
> >
> > -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 Roger.Riggs at oracle.com  Mon Oct 28 14:47:52 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 28 Oct 2019 10:47:52 -0400
Subject: [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <84da6f28-9c7b-7487-efe8-7e6ab47c5fa3@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
 <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>
 <84da6f28-9c7b-7487-efe8-7e6ab47c5fa3@oracle.com>
Message-ID: <7f878ecf-2b13-6b81-437b-4b1a8eb7b7a8@oracle.com>

Hi Naoto,

Looks good

Thanks for the clarification, Roger

On 10/25/19 7:31 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Thanks for the review.
>
> On 10/25/2019 AD 11:57 ??, Roger Riggs wrote:
>> HI Naoto,
>>
>> cldrconverter/Bundle.java:
>>
>> 233-246:? If there is a parent list, it seems to ignore/drop patterns 
>> greater than plist.size().
>> This would be clearer if it always processed all the patterns and 
>> used the parent
>> if the pattern[i] was empty and i < plist.size().? Switching around 
>> the range size leads to confusion.
>> (Or I misunderstand the intent).
>
> The code assumed that parents' lists are always longer than self, 
> which is true, but you are right that it can be more readable. 
> Corrected as follows:
>
> http://cr.openjdk.java.net/~naoto/8231273/webrev.01/
>
> Bundle:233-246 is the only change since 00.
>
>>
>> Is the algorithm intended to produce the longest list (parent and 
>> pattern)?
>
> Since at runtime, there's no way to fallback element by element basis, 
> the array should always contain all the elements (i.e., longest) 
> possible.
>
> Naoto
>
>>
>> Otherwise, looks fine.
>>
>> Thanks, Roger
>>
>>
>>
>> On 10/9/19 6:39 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8231273
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
>>>
>>> The webrev is huge, but majority of the changes is just to replace 
>>> the CLDR source locale data from version 35.1 to 36. The real code 
>>> changes are under make/jdk/src/classes/build/tools/cldrconverter, 
>>> where it now handles aliases for currency/percent formats, and 
>>> retrieves per-element fallback strings for compact number patterns. 
>>> Also relevant tests are modified accordingly.
>>>
>>> Naoto
>>


From olga.klisho at jetbrains.com  Mon Oct 28 16:18:11 2019
From: olga.klisho at jetbrains.com (Olga Klisho)
Date: Mon, 28 Oct 2019 19:18:11 +0300
Subject: fx:deploy is not available in this JDK
Message-ID: <CAKepv170y-HPN3Vc-+R3K61nN2DTSrrzaB3SXzjdzHKLGzYdSw@mail.gmail.com>

Hello,

JavaFX application successfully compiles in IntelliJ IDEA 2019.3
<https://www.jetbrains.com/idea/nextversion/> with the use of:
- *Build 14-jpackage+1-35 (2019/8/29)* (http://jdk.java.net/jpackage);
- Early-Access builds for JavaFX 14 (https://gluonhq.com/products/javafx).

The same project fails to compile with* Build 14-jpackage+1-49 (2019/10/2)*
with exception attached.

JavaFX artifacts can't be built with both mentioned jpackage builds.
Please see the sample project where the issue is reproduced attached to the
issue:
https://youtrack.jetbrains.com/issue/IDEA-200721

In case of any questions or if more details are needed please feel free to
contact me. Thank you

Olga Klisho
IDEA Support Engineer
JetBrains
http://www.jetbrains.com
The Drive to Develop
-------------- next part --------------
Exception in Application start method
Exception in thread "main" java.lang.RuntimeException: Exception in Application start method
	at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900)
	at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
	at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.lang.IllegalAccessError: superclass access check failed: class com.sun.javafx.sg.prism.web.NGWebView (in unnamed module @0x1da413f1) cannot access class com.sun.javafx.sg.prism.NGGroup (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.sg.prism to unnamed module @0x1da413f1
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:151)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:821)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:719)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:642)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:600)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:420)
	at javafx.graphics/com.sun.javafx.application.PlatformImpl.checkForClass(PlatformImpl.java:619)
	at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupportedImpl(PlatformImpl.java:896)
	at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupported(PlatformImpl.java:627)
	at javafx.graphics/javafx.application.Platform.isSupported(Platform.java:252)
	at javafx.fxml/javafx.fxml.JavaFXBuilderFactory.<init>(JavaFXBuilderFactory.java:105)
	at javafx.fxml/javafx.fxml.JavaFXBuilderFactory.<init>(JavaFXBuilderFactory.java:90)
	at javafx.fxml/javafx.fxml.FXMLLoader.<clinit>(FXMLLoader.java:1828)
	at sample.Main.start(Main.java:13)
	at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846)
	at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:455)
	at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
	at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427)
	at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)

From takiguc at linux.vnet.ibm.com  Mon Oct 28 16:51:06 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 29 Oct 2019 01:51:06 +0900
Subject: RFR: 8232161 Unexpected 1-way trip conversion entries on MS950
 charset
In-Reply-To: <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
Message-ID: <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>

Hello.

I have no idea about compatibility impact.

But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
These are BOX DRAWINGS characters.

2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
HORIZONTAL;;;;
255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;;;;;N;FORMS 
VERTICAL SINGLE AND RIGHT DOUBLE;;;;
2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
VERTICAL SINGLE AND LEFT DOUBLE;;;;
256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;

I don't think it was used as valuable data until now.
I think it's necessary to evaluate compatibility.

To Sato-san,
if you have any question and suggestion, please let me know.

To other reviewers,
please let me know if you have any question and concern.

Thanks,
Ichiroh Takiguchi

On 2019-10-19 16:36, Alan Bateman wrote:
> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>> 
>> I have a concern about 1-way trip conversion entries (4 entries) on 
>> MS950 charset.
>> The detail information is in JDK-8232161 [1]
>> 
> Do you know any sense on the compatibility impact of changing this? I
> think Naoto has the same question and we aren't sure if this one with
> need a compatibility property. I think it will need a CSR.
> 
> -Alan

From lance.andersen at oracle.com  Mon Oct 28 17:10:11 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 28 Oct 2019 13:10:11 -0400
Subject: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
 leads to a CRC failure in the generated jar file
In-Reply-To: <AM6PR02MB4801ED3F384E354DD004481C8A660@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <991bb09a-cafa-5b59-a3e4-2b1360820aea@gmail.com>
 <12B8621F-6F74-43C8-97BB-FAF27F1EBCC9@oracle.com>
 <c41e32d1-6a57-6adf-5e13-b98bd6abc299@gmail.com>
 <0C89C862-149F-4C15-A03B-214C90698B8B@oracle.com>
 <70df8a2b-5e00-a13c-3179-c98f3b3f8ddb@gmail.com>
 <671B8247-977A-4140-898D-7551E23597DD@oracle.com>
 <AM6PR02MB4801ED3F384E354DD004481C8A660@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <BDF7340F-354D-48BC-9D1F-12DE26A42B4A@oracle.com>

Hi Christoph,
> On Oct 28, 2019, at 6:19 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Lance,
> 
> thanks for reworking the test. That definitely improves coverage.
> 
> The comment for the test method (line 56/57) could be improved like: "Verify all write methods of an OutputStream that can be used to write to an entry of Zip Filesystem by exercising all of them when creating an archive and then traversing the archive with ZipFile, ZipInputStream and the Zip Filesystem?.

I think I am going to leave it as it is for now.
> 
> Other than that, it's good to go for mw.

OK, thank you.
> 
> BTW, I think meanwhile all these zipfs tests have quite some duplicate infrastructure classes and methods (e.g. Entry) that could be shared. Maybe we should try to carve out some stuff into a library or some Auxillary helper class. What do you think?

Yes it is on my todo list.  There is an issue that needs addressed 1st then that will follow on.

Best
Lance
> 
> Thanks
> Christoph
> 
>> -----Original Message-----
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
>> Of Lance Andersen
>> Sent: Samstag, 26. Oktober 2019 04:42
>> To: Jaikiran Pai <jai.forums2013 at gmail.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
>> leads to a CRC failure in the generated jar file
>> 
>> 
>>> On Oct 25, 2019, at 10:10 PM, Jaikiran Pai <jai.forums2013 at gmail.com>
>> wrote:
>>> 
>>> Thank you for the review, Lance.
>>> 
>> 
>> You are very welcome Jaikiran.
>>> On 26/10/19 4:25 AM, Lance Andersen wrote:
>>>> 
>>>> The change to Zip FS looks good.  I re-worked the test so that it also runs
>> against ZipFile (which uses the CEN vs the LOC) and Zip FS in addition to
>> ZipInputStream for extra coverage.
>>>> 
>>>> The webrev can be found at:
>> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html
>> <http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html>Looks
>> fine. A very minor note about
>> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zip
>> fs/CRCWriteTest.java.html
>> <http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zi
>> pfs/CRCWriteTest.java.html>
>>> 136                 while ((ze = zis.getNextEntry()) != null) {
>>> 137                     assertNotNull(ze);
>>> 
>>> Looks like an oversight - that assertNotNull(ze) on 137 isn't needed due to
>> the != null check on 1
>> 
>> Yep, not needed.  Sometimes you do things on auto pilot ;-)
>> 
>> Will remove before I push the change.
>>> 36.
>>> 
>>> -Jaikiran
>>> 
>> 
>> <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 sergei.tsypanov at yandex.ru  Mon Oct 28 17:14:32 2019
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Mon, 28 Oct 2019 19:14:32 +0200
Subject: Question about String.toUpperCase behaviour
Message-ID: <32507691572282872@sas2-a74be5364cfb.qloud-c.yandex.net>

Hello,

current implementation of e.g. String.toUpperCase() returns the object it was called on in case all code points are in upper case.

E.g. this test 

@Test
public void upperCase() {
  String str = "AZ";                // English
  assert str == str.toUpperCase();
  
  str = "??";                       // Russian
  assert str == str.toUpperCase();
}

passes for both Latin-1 and UTF-16. This assumption allows to simplify this:

boolean isUpperCase = str.toUpperCase().equals(str); 

to

boolean isUpperCase = str.toUpperCase() == str;

Could this transformation be legal assuming that existing behaviour of String.toUpperCase is not documented?

Regards,
Sergey Tsypanov

From adam.farley at uk.ibm.com  Mon Oct 28 17:18:18 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Mon, 28 Oct 2019 17:18:18 +0000
Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
Message-ID: <OF9FC0FB9E.6CC87C45-ON002584A1.00585784-802584A1.005F1136@notes.na.collabserv.com>

Hi All,

I'm asking for reviewers, sponsors, and opinions on the changes proposed 
below.

Right now, there are four files in OpenJDK 8 that have a GPL V2 License, 
with no Classpath Exception.

Based on the conversation so far, here's a summary of the proposed 
actions:

1) Remove this file, along with all the other JObjC files, in a new bug:

- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser

2) Add the ClassPath Exception to the licence for this file, because later 
versions of OpenJDK have made this change:

- 
jdk/make/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java 


3) Add the ClassPath Exception to the licence for these files, because it 
seems the code is used in the final build despite the directory implying 
otherwise.

- jdk/make/src/native/add_gnu_debuglink/add_gnu_debuglink.c 
- jdk/make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c 

Best Regards

Adam Farley 
IBM Runtimes


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From kevin.rushforth at oracle.com  Mon Oct 28 17:49:36 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 28 Oct 2019 10:49:36 -0700
Subject: fx:deploy is not available in this JDK
In-Reply-To: <CAKepv170y-HPN3Vc-+R3K61nN2DTSrrzaB3SXzjdzHKLGzYdSw@mail.gmail.com>
References: <CAKepv170y-HPN3Vc-+R3K61nN2DTSrrzaB3SXzjdzHKLGzYdSw@mail.gmail.com>
Message-ID: <3451f29f-ab2a-a219-0e8a-a06fb96d29da@oracle.com>

 > Error:Java FX Packager: fx:deploy task has failed.

The 'fx:deploy' task was part of the ant plugin that was formerly 
distributed in ant-javafx.jar as part of javapackager. This ant plugin 
is not included in jpacakge, so you will need to find some other way to 
integrate jpacakge into IntelliJ.

-- Kevin


On 10/28/2019 9:18 AM, Olga Klisho wrote:
> Hello,
>
> JavaFX application successfully compiles in IntelliJ IDEA 2019.3
> <https://www.jetbrains.com/idea/nextversion/> with the use of:
> - *Build 14-jpackage+1-35 (2019/8/29)* (http://jdk.java.net/jpackage);
> - Early-Access builds for JavaFX 14 (https://gluonhq.com/products/javafx).
>
> The same project fails to compile with* Build 14-jpackage+1-49 (2019/10/2)*
> with exception attached.
>
> JavaFX artifacts can't be built with both mentioned jpackage builds.
> Please see the sample project where the issue is reproduced attached to the
> issue:
> https://youtrack.jetbrains.com/issue/IDEA-200721
>
> In case of any questions or if more details are needed please feel free to
> contact me. Thank you
>
> Olga Klisho
> IDEA Support Engineer
> JetBrains
> http://www.jetbrains.com
> The Drive to Develop


From naoto.sato at oracle.com  Mon Oct 28 18:03:52 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 28 Oct 2019 11:03:52 -0700
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion entries
 on MS950 charset
In-Reply-To: <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
 <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
Message-ID: <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>

Hi Takiguchi-san,

On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
> Hello.
> 
> I have no idea about compatibility impact.
> 
> But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
> These are BOX DRAWINGS characters.
> 
> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
> HORIZONTAL;;;;
> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;;;;;N;FORMS 
> VERTICAL SINGLE AND RIGHT DOUBLE;;;;
> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
> VERTICAL SINGLE AND LEFT DOUBLE;;;;
> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
> 
> I don't think it was used as valuable data until now.
> I think it's necessary to evaluate compatibility.

What do you mean by "until now"? Are there customers claiming that it 
should be corrected? Since the current JDK's mapping is not incorrect 
per se (not just "best match"), I would like to know why this needs to 
be fixed now.

Naoto

> 
> To Sato-san,
> if you have any question and suggestion, please let me know.
> 
> To other reviewers,
> please let me know if you have any question and concern.
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-10-19 16:36, Alan Bateman wrote:
>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> Could you review the fix ?
>>>
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>
>>> I have a concern about 1-way trip conversion entries (4 entries) on 
>>> MS950 charset.
>>> The detail information is in JDK-8232161 [1]
>>>
>> Do you know any sense on the compatibility impact of changing this? I
>> think Naoto has the same question and we aren't sure if this one with
>> need a compatibility property. I think it will need a CSR.
>>
>> -Alan

From VOJIN.JOVANOVIC at ORACLE.COM  Mon Oct 28 18:10:25 2019
From: VOJIN.JOVANOVIC at ORACLE.COM (Vojin Jovanovic)
Date: Mon, 28 Oct 2019 19:10:25 +0100
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated
 lambdas
Message-ID: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>

Hi all, 

This email proposes a change to the LambdaMetaFactory that allows to disable eager initialization (with Unsafe) of generated lambdas. This is needed by the GraalVM Native Image, as initialization of lambdas during AOT compilation breaks our heap snapshotting (via initialization of interfaces with default methods that are super-types of a lambda). We have started from the original proposal that stores lambda instances in the static fields

  https://github.com/graalvm/labs-openjdk-11/commit/00b9ecd85dedd0411837eee33635dd83e8b7def8

and initializes them with Unsafe as an optimization 

   https://github.com/graalvm/labs-openjdk-11/commit/273e8590a7b57c0c10d9213ca9e0ba581e2817b8

After the discussion with Brian Goetz, we have trimmed down to the following change:

  https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff

The evolution of this change can be found at the issue: 

 https://bugs.openjdk.java.net/browse/JDK-8232806
 
Cheers,
- Vojin

From brian.goetz at oracle.com  Mon Oct 28 18:21:38 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 28 Oct 2019 14:21:38 -0400
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes
 generated lambdas
In-Reply-To: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
References: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
Message-ID: <fe2f8858-a7b3-7bc4-fe4b-5a7cb919dbc2@oracle.com>

The patch seems suitably minimal to me to meet the goals and not cause 
difficulty for future evolution of LMF (for which we have some plans, 
once some other VM work finishes up.)?? Essentially, the 
disable-eager-initialization case disables the caching optimization for 
non-capturing lambdas, and we then just revert to the main 
lambda-capture path, which makes this fairly low risk.



On 10/28/2019 2:10 PM, Vojin Jovanovic wrote:
> Hi all,
>
> This email proposes a change to the LambdaMetaFactory that allows to disable eager initialization (with Unsafe) of generated lambdas. This is needed by the GraalVM Native Image, as initialization of lambdas during AOT compilation breaks our heap snapshotting (via initialization of interfaces with default methods that are super-types of a lambda). We have started from the original proposal that stores lambda instances in the static fields
>
>    https://github.com/graalvm/labs-openjdk-11/commit/00b9ecd85dedd0411837eee33635dd83e8b7def8
>
> and initializes them with Unsafe as an optimization
>
>     https://github.com/graalvm/labs-openjdk-11/commit/273e8590a7b57c0c10d9213ca9e0ba581e2817b8
>
> After the discussion with Brian Goetz, we have trimmed down to the following change:
>
>    https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
>
> The evolution of this change can be found at the issue:
>
>   https://bugs.openjdk.java.net/browse/JDK-8232806
>   
> Cheers,
> - Vojin


From alexey.ivanov at oracle.com  Mon Oct 28 18:46:42 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 28 Oct 2019 18:46:42 +0000
Subject: RFR JDK-8232724: Remove indirection with calling JNU_NewStringPlatform
Message-ID: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>

Hello,

Please review the following fix which removes indirection in calling 
JNU_NewStringPlatform via NewStringPlatform.

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

It is a follow-up fix to JDK-8232624 and JDK-8231355. It removes 
NewStringPlatform alias as Claes did in JDK-8231355. To call 
JNU_NewStringPlatform, the function pointer to_java_string_fn_t is 
declared with JNICALL (__stdcall); the function is looked up by both the 
undecorated name and the __stdcall-decorated name for Win32.

Tier 1 and 2 tests are all green.

There are two declarations of the to_java_string_fn_t function pointer: 
in jvm.h and locally in javaClasses. I searched the source code for it 
and didn't find any usages but in 
java_lang_String::create_from_platform_dependent_str. The declaration in 
jvm.h uses "char *" whereas javaClasses uses "const char *".

Shall I remove one of them? The one in jvm.h because it's unused?


Thank you in advance.

https://bugs.openjdk.java.net/browse/JDK-8232624
https://bugs.openjdk.java.net/browse/JDK-8231355

-- 
Regards,
Alexey

From fw at deneb.enyo.de  Mon Oct 28 20:34:58 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 28 Oct 2019 21:34:58 +0100
Subject: Question about String.toUpperCase behaviour
In-Reply-To: <32507691572282872@sas2-a74be5364cfb.qloud-c.yandex.net>
 (=?utf-8?B?ItCh0LXRgNCz0LXQuQnQptGL0L/QsNC90L7QsiIncw==?= message of "Mon,
 28 Oct 2019 19:14:32 +0200")
References: <32507691572282872@sas2-a74be5364cfb.qloud-c.yandex.net>
Message-ID: <878sp46231.fsf@mid.deneb.enyo.de>

* ?????? ???????:

> Hello,
>
> current implementation of e.g. String.toUpperCase() returns the object
> it was called on in case all code points are in upper case.
>
> E.g. this test 
>
> @Test
> public void upperCase() {
>   String str = "AZ";                // English
>   assert str == str.toUpperCase();
>   
>   str = "??";                       // Russian
>   assert str == str.toUpperCase();
> }
>
> passes for both Latin-1 and UTF-16. This assumption allows to simplify this:
>
> boolean isUpperCase = str.toUpperCase().equals(str); 
>
> to
>
> boolean isUpperCase = str.toUpperCase() == str;
>
> Could this transformation be legal assuming that existing behaviour of
> String.toUpperCase is not documented?

Valid for whom?  For the JDK itself, sure.  But programmers really
should not assume such undocumented behavior when writing Java
programs, and neither shoud external tools targeting the JVM.

From martinrb at google.com  Mon Oct 28 20:40:57 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 28 Oct 2019 13:40:57 -0700
Subject: RFR: jsr166 integration 2019-11
Message-ID: <CA+kOe0-U06grdSsJ4u9WiVrpkw7xcsjukRGcD0dLe0eyCQR_mg@mail.gmail.com>

https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration-2019-11/overview.html

8231592: Clarify that ConcurrentHashMap compute methods mapping functions
execute at most once
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration-2019-11/compute-once/index.html
https://bugs.openjdk.java.net/browse/JDK-8231592

8231026: Miscellaneous changes imported from jsr166 CVS 2019-11
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration-2019-11/miscellaneous/index.html
https://bugs.openjdk.java.net/browse/JDK-8231026

From mark.reinhold at oracle.com  Mon Oct 28 22:29:58 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 28 Oct 2019 15:29:58 -0700
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes
 generated lambdas
In-Reply-To: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
References: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
Message-ID: <20191028152958.506178281@eggemoggin.niobe.net>

2019/10/28 11:10:25 -0700, vojin.jovanovic at oracle.com:
> This email proposes a change to the LambdaMetaFactory that allows to
> disable eager initialization (with Unsafe) of generated lambdas. ...
>
> ...
> 
> After the discussion with Brian Goetz, we have trimmed down to the
> following change:
> 
>   https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
> 
> The evolution of this change can be found at the issue: 
> 
>  https://bugs.openjdk.java.net/browse/JDK-8232806

Vojin -- I?d be happy to sponsor this change on your behalf.

I?ve posted a webrev that incorporates the suggestions that Paul and
R?mi made in the JBS issue:

  https://cr.openjdk.java.net/~mr/rev/8232806/

Paul, R?mi -- please make sure that I understood your suggestions
correctly.

- Mark

From paul.sandoz at oracle.com  Mon Oct 28 23:29:15 2019
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 28 Oct 2019 16:29:15 -0700
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes
 generated lambdas
In-Reply-To: <20191028152958.506178281@eggemoggin.niobe.net>
References: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
 <20191028152958.506178281@eggemoggin.niobe.net>
Message-ID: <583FFD59-DEEF-42AD-8782-DD504DD93AA5@oracle.com>


> On Oct 28, 2019, at 3:29 PM, mark.reinhold at oracle.com wrote:
> 
> 2019/10/28 11:10:25 -0700, vojin.jovanovic at oracle.com:
>> This email proposes a change to the LambdaMetaFactory that allows to
>> disable eager initialization (with Unsafe) of generated lambdas. ...
>> 
>> ...
>> 
>> After the discussion with Brian Goetz, we have trimmed down to the
>> following change:
>> 
>>  https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
>> 
>> The evolution of this change can be found at the issue: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8232806
> 
> Vojin -- I?d be happy to sponsor this change on your behalf.
> 
> I?ve posted a webrev that incorporates the suggestions that Paul and
> R?mi made in the JBS issue:
> 
>  https://cr.openjdk.java.net/~mr/rev/8232806/
> 
> Paul, R?mi -- please make sure that I understood your suggestions
> correctly

Looks good to me.

I don?t know of an easy way to test when the new sys property is true that the implementing class is not initialized. Seems to require an explicit call to LMF, cracking open the calls site?s target, and calling Unsafe.shouldBeInitialized (presuming initialization is not tickled before that call and the call works!).  Perhaps a future exercise if someone wanna takes that on.

Paul.

From ivan.gerasimov at oracle.com  Tue Oct 29 01:03:01 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 28 Oct 2019 18:03:01 -0700
Subject: RFR 8225466 : Optimize matching BMP Slice nodes
Message-ID: <3657c460-15a0-2aa1-1092-97d196cf125b@oracle.com>

Hello!

When building a Pattern object, the regex parser recognizes "slices" - 
continuous char subsequences, which all have to be matched 
case-sensitively/case-insensitively.? Matching with such a slice is 
implemented as a simple loop over a portion of the input.

In the current implementation, on each iteration of the loop it is 
checked if we have hit the end of the input (which is an uncommon case).

This check can be done only once, before the loop, which will make the 
loop lighter.

Benchmark shows up to +4% to the throughput for the case-insensitive 
matching.

Would you please help review the enhancement?

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


----------- benchmark results ---------------

UNFIXED
Benchmark??????????????? Mode? Cnt??? Score?? Error? Units
PatternBench.sliceIFind? avgt?? 16? 190.612 ? 0.336? ns/op

FIXED
Benchmark??????????????? Mode? Cnt??? Score?? Error? Units
PatternBench.sliceIFind? avgt?? 16? 182.954 ? 0.493? ns/op
-------------------------------------------

-- 
With kind regards,
Ivan Gerasimov


From alexander.matveev at oracle.com  Tue Oct 29 05:19:57 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 28 Oct 2019 22:19:57 -0700
Subject: RFR: JDK-8232186: Add verification for pkg and dmg tests
In-Reply-To: <2b6673e4-9b73-9e89-d46c-9bd0c7a72678@oracle.com>
References: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>
 <2b6673e4-9b73-9e89-d46c-9bd0c7a72678@oracle.com>
Message-ID: <c1d9497f-7654-40f1-69dc-886fec270bca@oracle.com>

Changes since last review:

http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/

- Hello.java combined into one test app and will be used by all tests.
- appOutput.txt will be created in same folder as file used for file 
association.
- Other minor changes.

Thanks,
Alexander

On 10/23/19 10:07 AM, Andy Herrick wrote:
> looks ok to me
>
> /ANdy
>
> On 10/22/2019 5:29 PM, Alexander Matveev wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> - Removed --mac-app-store-category.
>> - Added Hello.java test app to support file association on OS X.
>> - Modified Hello.java to write output file to user home location if 
>> working directory is not writable.
>> - Fixed MacHelper:getInstallationDirectory(). It was returning extra 
>> /Applications when --install-dir is specified.
>> - Fixed SigningPackageTest to use path returned by withExplodedDmg 
>> correctly.
>> - Added install/uninstall support for pkg and dmg to manage_packages.sh.
>> - Fixed replaceFileName(), otherwise on OS X it was not replacing 
>> file name correctly, since file name does not have extension.
>> - Added NameWithSpaceTest.
>> - Removed OptionsTest which is covered by other tests.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232186
>>
>> [2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/
>>
>> Thanks,
>> Alexander


From christoph.langer at sap.com  Tue Oct 29 05:29:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 29 Oct 2019 05:29:23 +0000
Subject: RFR JDK-8232724: Remove indirection with calling
 JNU_NewStringPlatform
In-Reply-To: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
References: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
Message-ID: <AM6PR02MB480168475E5B3492A10E43B38A610@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Alexey,

> Please review the following fix which removes indirection in calling
> JNU_NewStringPlatform via NewStringPlatform.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8232724
> webrev: http://cr.openjdk.java.net/~aivanov/8232724/webrev.00/
> 
> It is a follow-up fix to JDK-8232624 and JDK-8231355. It removes
> NewStringPlatform alias as Claes did in JDK-8231355. To call
> JNU_NewStringPlatform, the function pointer to_java_string_fn_t is
> declared with JNICALL (__stdcall); the function is looked up by both the
> undecorated name and the __stdcall-decorated name for Win32.
> 
> Tier 1 and 2 tests are all green.

This looks good to me.

> There are two declarations of the to_java_string_fn_t function pointer:
> in jvm.h and locally in javaClasses. I searched the source code for it
> and didn't find any usages but in
> java_lang_String::create_from_platform_dependent_str. The declaration in
> jvm.h uses "char *" whereas javaClasses uses "const char *".
> 
> Shall I remove one of them? The one in jvm.h because it's unused?

Yes, I would suggest dropping the declaration in jvm.h

Cheers
Christoph


From david.holmes at oracle.com  Tue Oct 29 07:42:08 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 29 Oct 2019 17:42:08 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
Message-ID: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/

This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but 
only in small pieces each. There is also a small touch to serviceability 
code.

This change is "simply" moving the "interrupted" field out of the 
osThread and into the java.lang.Thread so that it can be set 
independently of whether the thread is alive (and to make things easier 
for loom in the near future). It is very straightforward:

- old scheme
   - interrupted field is in osThread
   - VM can read/write directly
   - Java code calls into VM to read/write

- new scheme
   - interrupted field is in java.lang.Thread
   - VM has to use javaCalls to read/write "directly"
   - Java code can read/write directly

No changes to any of the semantics regarding the actual interrupt 
mechanism. Special thanks to Patricio for tracking down a bug I had 
introduced in that regard!

Special Note (Hi Roger!): on windows we still need to set/clear the 
_interrupt_event used by the Process.waitFor logic. To facilitate 
clearing via Thread.interrupted() I had to introduce a native method 
that is a no-op except on Windows. This seemed the cheapest and least 
intrusive means to achieve this.

Other changes revolve around the fact we used to have an intrinsic for 
Thread.isInterrupted and that is not needed any more. So we strip some 
code out of C1/C2.

The changes in the JVMCI/Graal code are a bit more far reaching as 
entire classes disappear. I've cc'd Doug and Tom at Vladimir's request 
so that they can comment on the JVMCI changes and whether I have gone 
too far or not far enough. There are a bunch of tests for interruption 
in JVMCI that could potentially be deleted if they are only intended to 
test the JVMCI handling of interrupt:

./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java

Testing:
  - Tiers 1-3 on all Oracle platforms
  - Focused testing on Linux x64:
     - Stress runs of JSR166TestCase
     - Anything that seems to use interrupt():
       - JDK
         - java/lang/Thread
         - java/util/concurrent
         - jdk/internal/loader/InterruptedClassLoad.java
         - javax/management
         - java/nio/file/Files
         - java/nio/channels
         - java/net/Socket/Timeouts.java
         - java/lang/Runtime/shutdown/
         - java/lang/ProcessBuilder/Basic.java
         - com/sun/jdi/
       - Hotspot
         - vmTestbase/nsk/monitoring/
         - vmTestbase/nsk/jdwp
         - vmTestbase/nsk/jdb/
         - vmTestbase/nsk/jdi/
         - vmTestbase/nsk/jvmti/
         - runtime/Thread
         - serviceability/jvmti/
         - serviceability/jdwp
         - serviceability/sa

Thanks,
David
-----

From david.holmes at oracle.com  Tue Oct 29 07:49:07 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 29 Oct 2019 17:49:07 +1000
Subject: RFR JDK-8232724: Remove indirection with calling
 JNU_NewStringPlatform
In-Reply-To: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
References: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
Message-ID: <a8c2fccb-df7c-8e4b-d958-3b159ea821e4@oracle.com>

Hi Alexey,

On 29/10/2019 4:46 am, Alexey Ivanov wrote:
> Hello,
> 
> Please review the following fix which removes indirection in calling 
> JNU_NewStringPlatform via NewStringPlatform.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8232724
> webrev: http://cr.openjdk.java.net/~aivanov/8232724/webrev.00/
> 
> It is a follow-up fix to JDK-8232624 and JDK-8231355. It removes 
> NewStringPlatform alias as Claes did in JDK-8231355. To call 
> JNU_NewStringPlatform, the function pointer to_java_string_fn_t is 
> declared with JNICALL (__stdcall); the function is looked up by both the 
> undecorated name and the __stdcall-decorated name for Win32.

That seems fine.

> Tier 1 and 2 tests are all green.
> 
> There are two declarations of the to_java_string_fn_t function pointer: 
> in jvm.h and locally in javaClasses. I searched the source code for it 
> and didn't find any usages but in 
> java_lang_String::create_from_platform_dependent_str. The declaration in 
> jvm.h uses "char *" whereas javaClasses uses "const char *".
> 
> Shall I remove one of them? The one in jvm.h because it's unused?

Yes please remove the unused one in jvm.h.

Thanks,
David
-----

> 
> Thank you in advance.
> 
> https://bugs.openjdk.java.net/browse/JDK-8232624
> https://bugs.openjdk.java.net/browse/JDK-8231355
> 

From doug.simon at oracle.com  Tue Oct 29 08:55:56 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 29 Oct 2019 09:55:56 +0100
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
Message-ID: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>

Hi David,

Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing:

diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
index 0752a621215..baa2136a6ba 100644
--- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
+++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
@@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase {
     public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor");
     public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE);
     public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
-    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
+    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE);
     public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int");
     public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
     public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*");
diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
index 6b37fff083d..ffc8032d2b0 100644
--- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
+++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
@@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
             }
         });
 
-        r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
+        if (config.osThreadOffset != Integer.MAX_VALUE) {
+            r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
+        }
     }
 
     public static final String reflectionClass;
diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
index 1d694fae2a4..8500c4de115 100644
--- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
+++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
@@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
 
     @Fold
     public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) {
+        assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE;
         return config.osThreadOffset;
     }
 
All the other JVMCI changes look good to me.

-Doug

> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
> 
> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code.
> 
> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward:
> 
> - old scheme
>  - interrupted field is in osThread
>  - VM can read/write directly
>  - Java code calls into VM to read/write
> 
> - new scheme
>  - interrupted field is in java.lang.Thread
>  - VM has to use javaCalls to read/write "directly"
>  - Java code can read/write directly
> 
> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard!
> 
> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this.
> 
> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2.
> 
> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt:
> 
> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
> 
> Testing:
> - Tiers 1-3 on all Oracle platforms
> - Focused testing on Linux x64:
>    - Stress runs of JSR166TestCase
>    - Anything that seems to use interrupt():
>      - JDK
>        - java/lang/Thread
>        - java/util/concurrent
>        - jdk/internal/loader/InterruptedClassLoad.java
>        - javax/management
>        - java/nio/file/Files
>        - java/nio/channels
>        - java/net/Socket/Timeouts.java
>        - java/lang/Runtime/shutdown/
>        - java/lang/ProcessBuilder/Basic.java
>        - com/sun/jdi/
>      - Hotspot
>        - vmTestbase/nsk/monitoring/
>        - vmTestbase/nsk/jdwp
>        - vmTestbase/nsk/jdb/
>        - vmTestbase/nsk/jdi/
>        - vmTestbase/nsk/jvmti/
>        - runtime/Thread
>        - serviceability/jvmti/
>        - serviceability/jdwp
>        - serviceability/sa
> 
> Thanks,
> David
> -----


From david.holmes at oracle.com  Tue Oct 29 09:12:01 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 29 Oct 2019 19:12:01 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
Message-ID: <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>

Hi Doug,

Thanks for taking a look so quickly! :)

On 29/10/2019 6:55 pm, Doug Simon wrote:
> Hi David,
> 
> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing:

So to be clear I should revert all the Graal file changes I made and 
just apply the patch below?

Thanks,
David
-----

> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
> index 0752a621215..baa2136a6ba 100644
> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase {
>       public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor");
>       public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE);
>       public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
> -    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
> +    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE);
>       public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int");
>       public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
>       public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*");
> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
> index 6b37fff083d..ffc8032d2b0 100644
> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
>               }
>           });
>   
> -        r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
> +        if (config.osThreadOffset != Integer.MAX_VALUE) {
> +            r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
> +        }
>       }
>   
>       public static final String reflectionClass;
> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
> index 1d694fae2a4..8500c4de115 100644
> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
>   
>       @Fold
>       public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) {
> +        assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE;
>           return config.osThreadOffset;
>       }
>   
> All the other JVMCI changes look good to me.
> 
> -Doug
> 
>> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>
>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code.
>>
>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward:
>>
>> - old scheme
>>   - interrupted field is in osThread
>>   - VM can read/write directly
>>   - Java code calls into VM to read/write
>>
>> - new scheme
>>   - interrupted field is in java.lang.Thread
>>   - VM has to use javaCalls to read/write "directly"
>>   - Java code can read/write directly
>>
>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard!
>>
>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this.
>>
>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2.
>>
>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt:
>>
>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
>>
>> Testing:
>> - Tiers 1-3 on all Oracle platforms
>> - Focused testing on Linux x64:
>>     - Stress runs of JSR166TestCase
>>     - Anything that seems to use interrupt():
>>       - JDK
>>         - java/lang/Thread
>>         - java/util/concurrent
>>         - jdk/internal/loader/InterruptedClassLoad.java
>>         - javax/management
>>         - java/nio/file/Files
>>         - java/nio/channels
>>         - java/net/Socket/Timeouts.java
>>         - java/lang/Runtime/shutdown/
>>         - java/lang/ProcessBuilder/Basic.java
>>         - com/sun/jdi/
>>       - Hotspot
>>         - vmTestbase/nsk/monitoring/
>>         - vmTestbase/nsk/jdwp
>>         - vmTestbase/nsk/jdb/
>>         - vmTestbase/nsk/jdi/
>>         - vmTestbase/nsk/jvmti/
>>         - runtime/Thread
>>         - serviceability/jvmti/
>>         - serviceability/jdwp
>>         - serviceability/sa
>>
>> Thanks,
>> David
>> -----
> 

From doug.simon at oracle.com  Tue Oct 29 09:14:02 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 29 Oct 2019 10:14:02 +0100
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
Message-ID: <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>



> On 29 Oct 2019, at 10:12, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Doug,
> 
> Thanks for taking a look so quickly! :)
> 
> On 29/10/2019 6:55 pm, Doug Simon wrote:
>> Hi David,
>> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing:
> 
> So to be clear I should revert all the Graal file changes I made and just apply the patch below?

Yes please.

-Doug

> 
>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>> index 0752a621215..baa2136a6ba 100644
>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase {
>>      public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor");
>>      public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE);
>>      public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
>> -    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
>> +    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE);
>>      public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int");
>>      public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
>>      public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*");
>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>> index 6b37fff083d..ffc8032d2b0 100644
>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
>>              }
>>          });
>>  -        r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>> +        if (config.osThreadOffset != Integer.MAX_VALUE) {
>> +            r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>> +        }
>>      }
>>        public static final String reflectionClass;
>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>> index 1d694fae2a4..8500c4de115 100644
>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
>>        @Fold
>>      public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) {
>> +        assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE;
>>          return config.osThreadOffset;
>>      }
>>  All the other JVMCI changes look good to me.
>> -Doug
>>> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>> 
>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code.
>>> 
>>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward:
>>> 
>>> - old scheme
>>>  - interrupted field is in osThread
>>>  - VM can read/write directly
>>>  - Java code calls into VM to read/write
>>> 
>>> - new scheme
>>>  - interrupted field is in java.lang.Thread
>>>  - VM has to use javaCalls to read/write "directly"
>>>  - Java code can read/write directly
>>> 
>>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard!
>>> 
>>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this.
>>> 
>>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2.
>>> 
>>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt:
>>> 
>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
>>> 
>>> Testing:
>>> - Tiers 1-3 on all Oracle platforms
>>> - Focused testing on Linux x64:
>>>    - Stress runs of JSR166TestCase
>>>    - Anything that seems to use interrupt():
>>>      - JDK
>>>        - java/lang/Thread
>>>        - java/util/concurrent
>>>        - jdk/internal/loader/InterruptedClassLoad.java
>>>        - javax/management
>>>        - java/nio/file/Files
>>>        - java/nio/channels
>>>        - java/net/Socket/Timeouts.java
>>>        - java/lang/Runtime/shutdown/
>>>        - java/lang/ProcessBuilder/Basic.java
>>>        - com/sun/jdi/
>>>      - Hotspot
>>>        - vmTestbase/nsk/monitoring/
>>>        - vmTestbase/nsk/jdwp
>>>        - vmTestbase/nsk/jdb/
>>>        - vmTestbase/nsk/jdi/
>>>        - vmTestbase/nsk/jvmti/
>>>        - runtime/Thread
>>>        - serviceability/jvmti/
>>>        - serviceability/jdwp
>>>        - serviceability/sa
>>> 
>>> Thanks,
>>> David
>>> -----


From VOJIN.JOVANOVIC at ORACLE.COM  Tue Oct 29 10:57:32 2019
From: VOJIN.JOVANOVIC at ORACLE.COM (Vojin Jovanovic)
Date: Tue, 29 Oct 2019 11:57:32 +0100
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes
 generated lambdas
In-Reply-To: <583FFD59-DEEF-42AD-8782-DD504DD93AA5@oracle.com>
References: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
 <20191028152958.506178281@eggemoggin.niobe.net>
 <583FFD59-DEEF-42AD-8782-DD504DD93AA5@oracle.com>
Message-ID: <22C5CDFD-9BEC-48E8-B05E-8AD67377D7F2@ORACLE.COM>

The only way I see to test this (without calling LMF directly) is to inspect the stack trace created in a static initialiser of a lambda super-type. The stack trace should not contain LMF when -Djdk.internal.lambda.disableEagerInitialization=true. Let me know if this kind of a test reasonable; I can easily add it. ? Vojin

> On 29 Oct 2019, at 00:29, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> 
>> On Oct 28, 2019, at 3:29 PM, mark.reinhold at oracle.com wrote:
>> 
>> 2019/10/28 11:10:25 -0700, vojin.jovanovic at oracle.com:
>>> This email proposes a change to the LambdaMetaFactory that allows to
>>> disable eager initialization (with Unsafe) of generated lambdas. ...
>>> 
>>> ...
>>> 
>>> After the discussion with Brian Goetz, we have trimmed down to the
>>> following change:
>>> 
>>> https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
>>> 
>>> The evolution of this change can be found at the issue: 
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8232806
>> 
>> Vojin -- I?d be happy to sponsor this change on your behalf.
>> 
>> I?ve posted a webrev that incorporates the suggestions that Paul and
>> R?mi made in the JBS issue:
>> 
>> https://cr.openjdk.java.net/~mr/rev/8232806/
>> 
>> Paul, R?mi -- please make sure that I understood your suggestions
>> correctly
> 
> Looks good to me.
> 
> I don?t know of an easy way to test when the new sys property is true that the implementing class is not initialized. Seems to require an explicit call to LMF, cracking open the calls site?s target, and calling Unsafe.shouldBeInitialized (presuming initialization is not tickled before that call and the call works!).  Perhaps a future exercise if someone wanna takes that on.
> 
> Paul.


From andy.herrick at oracle.com  Tue Oct 29 11:59:20 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 29 Oct 2019 07:59:20 -0400
Subject: Jpackage EA build available
Message-ID: <cebb76d8-5aa9-a5eb-e3e2-abeb222f5e07@oracle.com>

The next EA build of JPackage is available at https://jdk.java.net/jpackage/

Build 14-jpackage+1-64 (2019/10/28) contains the following changes 
(since Build Build 14-jpackage+1-49 on 2019/10/02)

JDK-8231910???? Expose the APPDIR variable to applications that use jpackage
JDK-8232646???? Follow up for JDK-8223325
JDK-8136879???? WinExeBundler: WScript errors display in modal dialog box
JDK-8232728???? File Association icons no longer work on windows
JDK-8232073???? [deb] RuntimePackageTest should not have shared folder 
after install
JDK-8232029???? Wrong name to look up for .desktop template in resource 
directory
JDK-8231972???? Build a stable list of jpackager tests for SQE
JDK-8223325???? Improve wix sources generated by jpackage
JDK-8232281???? jpackage is not always reporting an error when no main 
class specified
JDK-8231912???? Use https for URLs in help and error messages
JDK-8232387 tools/jpackage/share/jdk/jpackage/tests/BasicTest.java fails
JDK-8232280???? close() is not called on return value of Files.walk()
JDK-8232279???? JDK-8230726 Extend functionality of jtreg test helpers
JDK-8231862???? Decouple DesktopIntegration and LinuxPackageBundler classes
JDK-8231604???? Expand junit test added with JDK-8230920
JDK-8231858???? [macos] App does not run if installed with pkg
JDK-8232042???? [macos] Installation fails if application name contains 
spaces
JDK-8231857???? App and Application folder icons are not aligned correctly
JDK-8231856???? pkg installer dialog contains background image which 
does not look correct
JDK-8231882???? --add-modules ALL-MODULE-PATH is not handled properly
JDK-8231850???? BasicTest test fails in jcov build
JDK-8215895???? Verify and create tests for Mac installer specific 
signing options
JDK-8231706???? Change "Java" dir to "app" dir in jpackage app image on 
macOS

please send feedback to core-libs-dev at openjdk.java.net

/Andy Herrick


From adam.farley at uk.ibm.com  Tue Oct 29 12:08:12 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 29 Oct 2019 12:08:12 +0000
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
 <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
 <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
 <CA+kOe0_uO9KTjah0JFSvRzceODMg0+-4ZZ_xZ-Sxq8hpA21ykA@mail.gmail.com>
 <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com>
Message-ID: <OF714F8467.4349DFF9-ON002584A2.0038FCFA-802584A2.0042ABC8@notes.na.collabserv.com>

Hey All,

To restart (and re-centre) the chat on this:

The issue I'm trying to solve is that it's hard to determine why a given 
class was not loaded by OpenJDK.

The solution I proposed was additional (optional) debug output from the 
different classloaders.

This way we can find out:

- Whether any classloaders tried to load the class from your class' 
location (by displaying all locations they try to load the class from).
- Which type of ClassLoaders tried to find your class.
- Which classpath each ClassLoader tried to use.
- Which modules were consulted.
etc etc.

Currently, it seems the only debug information available in this regard 
centres around:

- Classes that were successfully loaded
and
- Exceptions when the class couldn't be loaded.

So my questions are:

1) Am I trying to solve the right problem here?

2) Is there any support for this solution in principle, despite the fact 
that the webrev in its current form is...unrefined?

3) Is there a better way to get this information, with or without a code 
change?

Advice or opinions are appreciated.


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

Rough example webrev: http://cr.openjdk.java.net/~afarley/8232773/webrev/ 

Best Regards

Adam Farley 
IBM Runtimes




From:   David Holmes <david.holmes at oracle.com>
To:     Martin Buchholz <martinrb at google.com>
Cc:     Ioi Lam <ioi.lam at oracle.com>, core-libs-dev 
<core-libs-dev at openjdk.java.net>, Adam Farley8 <adam.farley at uk.ibm.com>
Date:   24/10/2019 05:22
Subject:        [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output 
for Specific Classes



Hi Martin,

This is going a bit OT I think ...

On 24/10/2019 1:24 pm, Martin Buchholz wrote:
> 
> 
> On Tue, Oct 22, 2019 at 3:58 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
> 
>     Perhaps one aspect of the class loading/resolution/initialization
>     process that can lead to confusion here is that if a class fails to
>     execute its static initialization then it is marked as Erroneous and
>     all
>     subsequent attempts to use that class result in NoClassDefFoundError
>     being thrown. If the original ExceptionInInitializerError got 
swallowed
>     somewhere then that can cause great confusion as to why the later 
NCDFE
>     occurs. The VM logging should help in that case - though I'd have to
>     confirm that (if it doesn't that should be fixed).
> 
> 
> I had a need to debug an error in a <clinit> this week and was again 
> frustrated by the difficulty.
> Classes falling into Erroneous state are rare so it seems reasonable to 
> save the exception as a cause for the subsequent NCDFE (probably can't 
> fix the misleading name of the exception)

So as you know such a request existed:

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8048190&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=AfL8IyQ5gm4a9cA4orx0EnUwiGqvG6rei-DuA8gA0jQ&s=pzILDarpf9cN_MvQFqk1u3YZqFzSCRbBZVoRdFw4lS4&e= 


and was closed as it was considered that TraceExceptions (now 
-Xlog:exceptions) would provide the additional information. As noted in 
that bug there are also semantic issues about recording the cause of an 
exception in thread B, with an exception object that was thrown in 
thread A. So unless someone comes up with a very convincing argument, or 
else it prepared to do the work, I don't see that being re-opened.

> I couldn't find a way to get hotspot to report the stack trace of all 
> exceptions that are thrown; -Xlog:exceptions=trace does not .

-Xlog:exceptions shows where the exception is thrown and how it proceeds 
up the stack. It doesn't print the full stacktrace. That seems like a 
logging request for the Throwable constructor, or fillInStackTrace, to 
me, rather than trying to have the VM do it. IIRC we store minimal VM 
information in the backTrace which is expanded when needed into the full 
StacktraceElements array.
> I was also frustrated that a StackOverflowError failed to report the 
> name of the thread and the stack size that was exceeded.  But 
> -Xlog:threads*=trace helped there.

The issue there is that SOE instances are allocated natively without 
executing any Java code (as we have run out of the Java stack) so we 
can't (easily) create a String message for the exception. However 
-Xlog:exceptions could be expanded to report that information at the 
point we throw the SOE. I filed - JDK-8232923.

Cheers,
David




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From Alan.Bateman at oracle.com  Tue Oct 29 14:33:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Oct 2019 14:33:21 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <AM6PR02MB48013938E41FEB97A8FCD5028A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <371cf47e-476b-8a1d-b466-a0acbae158f8@oracle.com>
 <AM6PR02MB48013938E41FEB97A8FCD5028A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <68d6191d-eba4-c95e-261f-fc4b9bea7e76@oracle.com>

On 23/10/2019 14:26, Langer, Christoph wrote:
> Hi Alan,
>
>> I have this on my list to look at. I think we'll need to figure out a
>> path to separate the usages (the JPLIS agent usage is technical debt, we
>> should have addressed that issue a long time ago).
> I agree that it's a good thing to explore how the different usages of calls to canonicalize could be disentangled. However, can't we defer that to another item? This one seems like a straightforward bugfix to me, with some cleanup attached. And I've prepared some more cleanup in that area already which is dependent on this fix - so I'd appreciate if this wouldn't be procrastinated too much :)
I went through the change and they look okay to me (much smaller than I 
was expecting). I think we will need to figure out a solution for the 
JPLIS agent at some point because it shouldn't be using functions in 
libjava (having the VM use the function isn't too bad I suppose).

-Alan


From christoph.langer at sap.com  Tue Oct 29 15:03:11 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 29 Oct 2019 15:03:11 +0000
Subject: RFR (S) 8232168: Fix non wide char canonicalization on Windows
In-Reply-To: <68d6191d-eba4-c95e-261f-fc4b9bea7e76@oracle.com>
References: <AM0PR02MB4500A821470F2BBEE34706369F930@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <e2c6980c-98eb-f094-b697-e0bdf09fc30c@oracle.com>
 <AM0PR02MB4500C09F03853E81E14B08879F920@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <81d008d5-11e0-d049-e1a5-7ebb793d6b15@oracle.com>
 <AM6PR02MB48011DD8AE7C31F9EB5056068A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <371cf47e-476b-8a1d-b466-a0acbae158f8@oracle.com>
 <AM6PR02MB48013938E41FEB97A8FCD5028A6B0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <68d6191d-eba4-c95e-261f-fc4b9bea7e76@oracle.com>
Message-ID: <AM6PR02MB4801883E30C253CB31209CFE8A610@AM6PR02MB4801.eurprd02.prod.outlook.com>

Thanks Alan,

I'll push this after running through jdk-submit. I'm preparing another patch for some further cleanup regarding canonicalize. But it won't get rid of the call from JPLIS.

Best regards
Christoph

> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Dienstag, 29. Oktober 2019 15:33
> To: Langer, Christoph <christoph.langer at sap.com>; hotspot-runtime-
> dev at openjdk.java.net; Java Core Libs <core-libs-dev at openjdk.java.net>
> Cc: Schmelter, Ralf <ralf.schmelter at sap.com>
> Subject: Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows
> 
> On 23/10/2019 14:26, Langer, Christoph wrote:
> > Hi Alan,
> >
> >> I have this on my list to look at. I think we'll need to figure out a
> >> path to separate the usages (the JPLIS agent usage is technical debt, we
> >> should have addressed that issue a long time ago).
> > I agree that it's a good thing to explore how the different usages of calls to
> canonicalize could be disentangled. However, can't we defer that to another
> item? This one seems like a straightforward bugfix to me, with some cleanup
> attached. And I've prepared some more cleanup in that area already which is
> dependent on this fix - so I'd appreciate if this wouldn't be procrastinated too
> much :)
> I went through the change and they look okay to me (much smaller than I
> was expecting). I think we will need to figure out a solution for the
> JPLIS agent at some point because it shouldn't be using functions in
> libjava (having the VM use the function isn't too bad I suppose).
> 
> -Alan


From alexey.ivanov at oracle.com  Tue Oct 29 15:04:16 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 29 Oct 2019 15:04:16 +0000
Subject: RFR JDK-8232724: Remove indirection with calling
 JNU_NewStringPlatform
In-Reply-To: <a8c2fccb-df7c-8e4b-d958-3b159ea821e4@oracle.com>
References: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
 <a8c2fccb-df7c-8e4b-d958-3b159ea821e4@oracle.com>
Message-ID: <1d78a797-86ba-6340-3ac0-db024ee416d6@oracle.com>

Hi David, Christoph,

Thank you for your reviews.

On 29/10/2019 07:49, David Holmes wrote:
>> Shall I remove one of them? The one in jvm.h because it's unused?
>
> Yes please remove the unused one in jvm.h. 

The updated webrev:
http://cr.openjdk.java.net/~aivanov/8232724/webrev.01/

-- 
Regards,
Alexey

From forax at univ-mlv.fr  Tue Oct 29 16:08:51 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 29 Oct 2019 16:08:51 +0000
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes
 generated lambdas
In-Reply-To: <20191028152958.506178281@eggemoggin.niobe.net>
References: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
 <20191028152958.506178281@eggemoggin.niobe.net>
Message-ID: <3666EEE6-8268-4CBC-87AA-2432672864B8@univ-mlv.fr>

Looks good to me.

Remi


On October 28, 2019 10:29:58 PM UTC, mark.reinhold at oracle.com wrote:
>2019/10/28 11:10:25 -0700, vojin.jovanovic at oracle.com:
>> This email proposes a change to the LambdaMetaFactory that allows to
>> disable eager initialization (with Unsafe) of generated lambdas. ...
>>
>> ...
>> 
>> After the discussion with Brian Goetz, we have trimmed down to the
>> following change:
>> 
>>  
>https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
>> 
>> The evolution of this change can be found at the issue: 
>> 
>>  https://bugs.openjdk.java.net/browse/JDK-8232806
>
>Vojin -- I?d be happy to sponsor this change on your behalf.
>
>I?ve posted a webrev that incorporates the suggestions that Paul and
>R?mi made in the JBS issue:
>
>  https://cr.openjdk.java.net/~mr/rev/8232806/
>
>Paul, R?mi -- please make sure that I understood your suggestions
>correctly.
>
>- Mark

-- 
Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma bri?vet?.

From richard.d.evans at oracle.com  Tue Oct 29 16:21:19 2019
From: richard.d.evans at oracle.com (Richard Evans)
Date: Tue, 29 Oct 2019 16:21:19 +0000
Subject: 14-jpackage+1-64 RPM errors
Message-ID: <dcd0fcf3-c31e-4a77-32ad-f0348a63588b@oracle.com>

Just upgraded to the latest 14-jpackage+1-64 and my rpm building script 
is failing, here's the end of the --verbose output:

Running [rpmbuild, --eval=%{_target_cpu}]
rpmbuild: no spec files given for build
x86_64
java.io.IOException: Command [rpmbuild, --eval=%{_target_cpu}] exited 
with 1 code
 ??? at 
jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.rpmArch(LinuxRpmBundler.java:226)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildRPM(LinuxRpmBundler.java:241)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildPackageBundle(LinuxRpmBundler.java:155)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:154)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
 ??? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
 ??? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)
jdk.jpackage.internal.PackagerException: java.io.IOException: Command 
[rpmbuild, --eval=%{_target_cpu}] exited with 1 code
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:167)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
 ??? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
 ??? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)
Caused by: java.io.IOException: Command [rpmbuild, 
--eval=%{_target_cpu}] exited with 1 code
 ??? at 
jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.rpmArch(LinuxRpmBundler.java:226)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildRPM(LinuxRpmBundler.java:241)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildPackageBundle(LinuxRpmBundler.java:155)
 ??? at 
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:154)
 ??? ... 4 more

Here's my script:

../jdk14/bin/jpackage --package-type rpm???????????????????????????? \
 ????????????????????? --runtime-image projects/launcher/build/jlink? \
 ????????????????????? --dest zzz???????????????????????????????????? \
 ????????????????????? --name "edq"?????????????????????????????????? \
 ????????????????????? --module edq.launcher/oracle.edq.launcher.Main \
 ????????????????????? --file-associations assoc.properties?????????? \
 ????????????????????? --icon /opt/stuff/edq.png????????????????????? \
 ????????????????????? --description "Oracle EDQ Launcher"??????????? \
 ????????????????????? --vendor Oracle??????????????????????????????? \
 ????????????????????? --app-version 0.29???????????????????????????? \
 ????????????????????? --install-dir /opt???????????????????????????? \
 ????????????????????? --linux-menu-group "Oracle EDQ"??????????????? \
 ????????????????????? --linux-package-name edqlaunch

This is running on a Oracle Linux 6 system.

Thanks

Richard

-- 

Oracle <http://www.oracle.com>
Richard Evans | Product Architect
Phone: +441223228408 <tel:+441223228408> | Mobile: +447973839664 
<tel:+447973839664> | Video: richard.d.evans at oracle.com 
<sip:richard.d.evans at oracle.com>
Oracle Product Development
Park House Castle Park | Cambridge | CB3 0DU | United Kingdom

ORACLE Corporation UK Ltd is a company incorporated in England & Wales | 
Company Reg. No. 1782505 | Reg. office: Oracle Parkway, Thames Valley 
Park, Reading RG6 1RA
Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to 
developing practices and products that help protect the environment


From Alan.Bateman at oracle.com  Tue Oct 29 16:26:47 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Oct 2019 16:26:47 +0000
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
Message-ID: <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>

On 23/10/2019 08:25, Alan Bateman wrote:
>
> Thread::countStackFrames has been deprecated for 20+ years and has 
> been marked for-removal since Java SE 9. I'd like to remove it for 
> Java SE 14. It's was never a well-defined method and I've been unable 
> to find anything that uses it. The StackWalker API is a much better 
> solution for code that is interested in the number of stack frames.
Joe Darcy has suggested degrading the method in advance of its removal. 
We did the same with stop(Throwable) when we changed it to throw UOE in 
Java SE 8 before finally removing it in 11. Here is the updated webrev 
and CSR. The CSR will need to be re-reviewed. The method description is 
brief and the same as what we did for stop(Throwable).

http://cr.openjdk.java.net/~alanb/8205132/webrev.02/

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

Also just to summarize the discussion/objection from Seth Lytle. I think 
we've established that that it was a regression in JDK 10 that allowed 
that example to work. The method has always been specified to fail when 
the thread is not suspended.

-Alan




From alexey.semenyuk at oracle.com  Tue Oct 29 16:35:47 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 29 Oct 2019 12:35:47 -0400
Subject: 14-jpackage+1-64 RPM errors
In-Reply-To: <dcd0fcf3-c31e-4a77-32ad-f0348a63588b@oracle.com>
References: <dcd0fcf3-c31e-4a77-32ad-f0348a63588b@oracle.com>
Message-ID: <882e4953-490d-6fa9-b6bf-3f245876f48e@oracle.com>

Hi Richard,

Seems like `rpmbuild, --eval=%{_target_cpu}` command did two unexpected 
things in addition to printing out arch value:
1. printed out `rpmbuild: no spec files given for build`
2. exited with code `1`.

What version of rpmbuild are you using?

- Alexey

On 10/29/2019 12:21 PM, Richard Evans wrote:
> Just upgraded to the latest 14-jpackage+1-64 and my rpm building 
> script is failing, here's the end of the --verbose output:
>
> Running [rpmbuild, --eval=%{_target_cpu}]
> rpmbuild: no spec files given for build
> x86_64
> java.io.IOException: Command [rpmbuild, --eval=%{_target_cpu}] exited 
> with 1 code
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.rpmArch(LinuxRpmBundler.java:226)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildRPM(LinuxRpmBundler.java:241)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildPackageBundle(LinuxRpmBundler.java:155)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:154)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
> ??? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> ??? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)
> jdk.jpackage.internal.PackagerException: java.io.IOException: Command 
> [rpmbuild, --eval=%{_target_cpu}] exited with 1 code
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:167)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
> ??? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> ??? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)
> Caused by: java.io.IOException: Command [rpmbuild, 
> --eval=%{_target_cpu}] exited with 1 code
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.rpmArch(LinuxRpmBundler.java:226)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildRPM(LinuxRpmBundler.java:241)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxRpmBundler.buildPackageBundle(LinuxRpmBundler.java:155)
> ??? at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:154)
> ??? ... 4 more
>
> Here's my script:
>
> ../jdk14/bin/jpackage --package-type rpm???????????????????????????? \
> ????????????????????? --runtime-image projects/launcher/build/jlink? \
> ????????????????????? --dest zzz???????????????????????????????????? \
> ????????????????????? --name "edq"?????????????????????????????????? \
> ????????????????????? --module edq.launcher/oracle.edq.launcher.Main \
> ????????????????????? --file-associations assoc.properties?????????? \
> ????????????????????? --icon /opt/stuff/edq.png????????????????????? \
> ????????????????????? --description "Oracle EDQ Launcher"??????????? \
> ????????????????????? --vendor Oracle??????????????????????????????? \
> ????????????????????? --app-version 0.29???????????????????????????? \
> ????????????????????? --install-dir /opt???????????????????????????? \
> ????????????????????? --linux-menu-group "Oracle EDQ"??????????????? \
> ????????????????????? --linux-package-name edqlaunch
>
> This is running on a Oracle Linux 6 system.
>
> Thanks
>
> Richard
>


From seth.lytle at gmail.com  Tue Oct 29 16:58:25 2019
From: seth.lytle at gmail.com (seth lytle)
Date: Tue, 29 Oct 2019 12:58:25 -0400
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
Message-ID: <CAJtn+AeEQezGrUo8Q8+aBNT+kBM3AUR0Y-y2m3CL5qvPRDAZZg@mail.gmail.com>

Alan,

Was there a technical reason that the method was specified to fail
when called from within the same thread ? Ie, is there a race
condition or something similar that can happen, perhaps because the
JVM relocates the stack ?







On Tue, Oct 29, 2019 at 12:26 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 23/10/2019 08:25, Alan Bateman wrote:
> >
> > Thread::countStackFrames has been deprecated for 20+ years and has
> > been marked for-removal since Java SE 9. I'd like to remove it for
> > Java SE 14. It's was never a well-defined method and I've been unable
> > to find anything that uses it. The StackWalker API is a much better
> > solution for code that is interested in the number of stack frames.
> Joe Darcy has suggested degrading the method in advance of its removal.
> We did the same with stop(Throwable) when we changed it to throw UOE in
> Java SE 8 before finally removing it in 11. Here is the updated webrev
> and CSR. The CSR will need to be re-reviewed. The method description is
> brief and the same as what we did for stop(Throwable).
>
> http://cr.openjdk.java.net/~alanb/8205132/webrev.02/
>
> https://bugs.openjdk.java.net/browse/JDK-8232654
>
> Also just to summarize the discussion/objection from Seth Lytle. I think
> we've established that that it was a regression in JDK 10 that allowed
> that example to work. The method has always been specified to fail when
> the thread is not suspended.
>
> -Alan
>
>
>

From paul.sandoz at oracle.com  Tue Oct 29 17:01:50 2019
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 29 Oct 2019 10:01:50 -0700
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes
 generated lambdas
In-Reply-To: <22C5CDFD-9BEC-48E8-B05E-8AD67377D7F2@ORACLE.COM>
References: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
 <20191028152958.506178281@eggemoggin.niobe.net>
 <583FFD59-DEEF-42AD-8782-DD504DD93AA5@oracle.com>
 <22C5CDFD-9BEC-48E8-B05E-8AD67377D7F2@ORACLE.COM>
Message-ID: <2685EF9A-EBB2-4DA0-9CE4-BCBF4A3556D3@oracle.com>

Hi Vojin,

I think it would be useful to include such a test (for capturing and non-capturing) to protect against a regression.

Thanks,
Paul.

> On Oct 29, 2019, at 3:57 AM, Vojin Jovanovic <VOJIN.JOVANOVIC at ORACLE.COM> wrote:
> 
> The only way I see to test this (without calling LMF directly) is to inspect the stack trace created in a static initialiser of a lambda super-type. The stack trace should not contain LMF when -Djdk.internal.lambda.disableEagerInitialization=true. Let me know if this kind of a test reasonable; I can easily add it. ? Vojin
> 
>> On 29 Oct 2019, at 00:29, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>>> 
>>> On Oct 28, 2019, at 3:29 PM, mark.reinhold at oracle.com wrote:
>>> 
>>> 2019/10/28 11:10:25 -0700, vojin.jovanovic at oracle.com:
>>>> This email proposes a change to the LambdaMetaFactory that allows to
>>>> disable eager initialization (with Unsafe) of generated lambdas. ...
>>>> 
>>>> ...
>>>> 
>>>> After the discussion with Brian Goetz, we have trimmed down to the
>>>> following change:
>>>> 
>>>> https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
>>>> 
>>>> The evolution of this change can be found at the issue: 
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8232806
>>> 
>>> Vojin -- I?d be happy to sponsor this change on your behalf.
>>> 
>>> I?ve posted a webrev that incorporates the suggestions that Paul and
>>> R?mi made in the JBS issue:
>>> 
>>> https://cr.openjdk.java.net/~mr/rev/8232806/
>>> 
>>> Paul, R?mi -- please make sure that I understood your suggestions
>>> correctly
>> 
>> Looks good to me.
>> 
>> I don?t know of an easy way to test when the new sys property is true that the implementing class is not initialized. Seems to require an explicit call to LMF, cracking open the calls site?s target, and calling Unsafe.shouldBeInitialized (presuming initialization is not tickled before that call and the call works!).  Perhaps a future exercise if someone wanna takes that on.
>> 
>> Paul.
> 


From serban.iordache at gmail.com  Tue Oct 29 16:50:13 2019
From: serban.iordache at gmail.com (Serban Iordache)
Date: Tue, 29 Oct 2019 17:50:13 +0100
Subject: jpackage 14-jpackage+1-64: error 2343 when using --win-dir-chooser
Message-ID: <CA+QZ5tRHTnao0g9-9UpaQDUK_t7P8v8DCYUmtJVBnO7P4hv4cQ@mail.gmail.com>

Issue on Windows 10, with jpackage build 14-jpackage+1-64 (2019/10/28):
When using the --win-dir-chooser option, the generated MSI package is not
valid.

The error message issued by Windows Installer is:
"The installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2343."

Error code 2343 means: "Specified path is empty".
This problem did not occur in the previous version of jpackage (build
14-jpackage+1-49). I assume it is caused by the removal of the
APPLICATIONFOLDER property from:
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs.

Thanks

Serban

From mandy.chung at oracle.com  Tue Oct 29 17:19:06 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 29 Oct 2019 10:19:06 -0700
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <5de8fdf2-b90d-d828-93e5-5b99f48f79cf@loongson.cn>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
 <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>
 <2f4b97f6-3839-87ae-44d2-70f03bef9945@oracle.com>
 <fb835ceb-6a5b-2803-22e0-50da6d19d3ca@loongson.cn>
 <843adb6a-41a4-a336-bfff-2b7fa4cf2086@oracle.com>
 <5de8fdf2-b90d-d828-93e5-5b99f48f79cf@loongson.cn>
Message-ID: <440a7222-4590-6a3f-7ca5-95c7be5906cf@oracle.com>

Hi Jie,

This looks good but I ran into test/jdk/tools/jlink/BasicTest failure 
with OOME in some system configuration.?? I made a minor fix to the 
cleanup of the configuration collections after the plugin executes.

 ???????? // Let it go
-??????? speciesTypes = null;
-??????? invokerTypes = null;
-??????? dmhMethods = null;
+??????? speciesTypes.clear();
+??????? invokerTypes.clear();
+??????? callSiteTypes.clear();
+??????? dmhMethods.clear();

I have pushed the patch with the above change.

Mandy

On 10/25/19 7:34 PM, Jie Fu wrote:
>
> Hi Mandy,
>
> Thanks for your review and help.
> I think your refactoring is a nice improvement.
>
> Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.03/
> It seems much better now.
>
> Testing:
> ?- make test TEST="tier1 tier2 tier3" CONF=release
>
> Thanks a lot.
> Best regards,
> Jie
>
> On 2019/10/26 ??3:29, Mandy Chung wrote:
>>
>>
>> On 10/23/19 11:21 PM, Jie Fu wrote:
>>> Hi Mandy,
>>>
>>> Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.02/
>>> It seems better now.
>>>
>> It's better while I think this can be further simplified.
>>
>> line 101 to 217 involves iterating on the default sets/map and then
>> create a new TreeSet and TreeMap and then process the config file.
>>
>> Currently addDMHMethodType validates the methodType and then adds
>> to dmhMethods which ensures that the map entry value is a sorted set.
>> So we can add one new method to add an entry to speciesTypes,
>> invokeTypes and callSiteTypes which performs the validation and then
>> add to the corresponding collection.
>>
>> I think that way the code will be cleaner.  Below is something for
>> your reference.
>>
>> Mandy
>>
>> diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
>> --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
>> +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
>> @@ -75,13 +75,13 @@
>>       private static final JavaLangInvokeAccess JLIA
>>               = SharedSecrets.getJavaLangInvokeAccess();
>>   
>> -    Set<String> speciesTypes = Set.of();
>> +    private final TreeSet<String> speciesTypes = new TreeSet<>();
>>   
>> -    Set<String> invokerTypes = Set.of();
>> +    private final TreeSet<String> invokerTypes = new TreeSet<>();
>>   
>> -    Set<String> callSiteTypes = Set.of();
>> +    private final TreeSet<String> callSiteTypes = new TreeSet<>();
>>   
>> -    Map<String, Set<String>> dmhMethods = Map.of();
>> +    private final Map<String, Set<String>> dmhMethods = new TreeMap<>();
>>   
>>       String mainArgument;
>>   
>> @@ -187,21 +187,31 @@
>>           mainArgument = config.get(NAME);
>>       }
>>
>> +    private void addSpeciesType(String type) {
>> +        speciesTypes.add(expandSignature(type));
>> +    }
>> +
>> +    private void addInvokerType(String methodType) {
>> +        validateMethodType(methodType);
>> +        invokerTypes.add(methodType);
>> +    }
>> +
>> +    private void addCallSisterType(String csType) {
>> +        validateMethodType(csType);
>> +        callSiteTypes.add(csType);
>> +    }
>> +
>>       public void initialize(ResourcePool in) {
>>           // Start with the default configuration
>> -        speciesTypes = defaultSpecies().stream()
>> -                .map(type -> expandSignature(type))
>> -                .collect(Collectors.toSet());
>> +        defaultSpecies().stream().forEach(this::addSpeciesType);
>>   
>> -        invokerTypes = defaultInvokers();
>> -        validateMethodTypes(invokerTypes);
>> +        defaultInvokers().stream().forEach(this::validateMethodType);
>>   
>> -        callSiteTypes = defaultCallSiteTypes();
>> +        defaultCallSiteTypes().stream().forEach(this::addCallSisterType);
>>   
>> -        dmhMethods = defaultDMHMethods();
>> -        for (Set<String> dmhMethodTypes : dmhMethods.values()) {
>> -            validateMethodTypes(dmhMethodTypes);
>> -        }
>> +        defaultDMHMethods().entrySet().stream().forEach(e -> {
>> +            e.getValue().stream().forEach(type -> addDMHMethodType(e.getKey(), type))
>> +        });
>>   
>>           // Extend the default configuration with the contents in the supplied
>>           // input file - if none was supplied we look for the default file
>> @@ -225,18 +235,6 @@
>>       }
>>
>>   
>>       private void readTraceConfig(Stream<String> lines) {
>> -        // Use TreeSet/TreeMap to keep things sorted in a deterministic
>> -        // order to avoid scrambling the layout on small changes and to
>> -        // ease finding methods in the generated code
>> -        speciesTypes = new TreeSet<>(speciesTypes);
>> -        invokerTypes = new TreeSet<>(invokerTypes);
>> -        callSiteTypes = new TreeSet<>(callSiteTypes);
>> -
>> -        TreeMap<String, Set<String>> newDMHMethods = new TreeMap<>();
>> -        for (Map.Entry<String, Set<String>> entry : dmhMethods.entrySet()) {
>> -            newDMHMethods.put(entry.getKey(), new TreeSet<>(entry.getValue()));
>> -        }
>> -        dmhMethods = newDMHMethods;
>>           lines.map(line -> line.split(" "))
>>                .forEach(parts -> {
>>                   switch (parts[0]) {
>> @@ -245,19 +243,18 @@
>>                           if (parts.length == 3 && parts[1].startsWith("java.lang.invoke.BoundMethodHandle$Species_")) {
>>                               String species = parts[1].substring("java.lang.invoke.BoundMethodHandle$Species_".length());
>>                               if (!"L".equals(species)) {
>> -                                speciesTypes.add(expandSignature(species));
>> +                                addSpeciesType(species);
>>                               }
>>                           }
>>                           break;
>>                       case "[LF_RESOLVE]":
>>                           String methodType = parts[3];
>> -                        validateMethodType(methodType);
>>                           if (parts[1].equals(INVOKERS_HOLDER_NAME)) {
>>                               if ("linkToTargetMethod".equals(parts[2]) ||
>>                                       "linkToCallSite".equals(parts[2])) {
>> -                                callSiteTypes.add(methodType);
>> +                                addCallSisterType(methodType);
>>                               } else {
>> -                                invokerTypes.add(methodType);
>> +                                addInvokerType(methodType);
>>                               }
>>                           } else if (parts[1].contains("DirectMethodHandle")) {
>>                               String dmh = parts[2];
>> @@ -291,12 +288,6 @@
>>           }
>>       }
>>   
>> -    private void validateMethodTypes(Set<String> dmhMethodTypes) {
>> -        for (String type : dmhMethodTypes) {
>> -            validateMethodType(type);
>> -        }
>> -    }
>>
>>       private void validateMethodType(String type) {
>>           String[] typeParts = type.split("_");
>>           // check return type (second part)
>> @@ -338,12 +329,6 @@
>>   
>>           // Generate LambdaForm Holder classes
>>           generateHolderClasses(out);
>> -
>> -        // Let it go
>> -        speciesTypes = null;
>> -        invokerTypes = null;
>> -        dmhMethods = null;
>> -
>>           return out.build();
>>       }
>>


From mandy.chung at oracle.com  Tue Oct 29 17:37:36 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 29 Oct 2019 10:37:36 -0700
Subject: Review Request JDK-8173975: Lookup::in should not allow target
 class be primitive or array class
In-Reply-To: <22120ed2-3b60-5c9f-0e2c-5be6daae4670@oracle.com>
References: <0eca5816-68d6-33a7-9d34-7c9a78d0810a@oracle.com>
 <22120ed2-3b60-5c9f-0e2c-5be6daae4670@oracle.com>
Message-ID: <a0568932-b6ec-20c2-a778-283ec68652e8@oracle.com>



On 10/15/19 2:26 AM, Alan Bateman wrote:
> On 14/10/2019 23:34, Mandy Chung wrote:
>> MethodHandles::lookup produces a Lookup object on the caller class. 
>> The original intention for a Lookup object whose lookup class is 
>> always a non-array and non-primitive class.
>>
>> MethodHandles::privateLookupIn and Lookup::in are the two other ways 
>> that can produce a new Lookup object and they should disallow the new 
>> lookup class be a primitive or array class.
>>
>> This patch proposes to make Lookup::in consistent with 
>> MethodHandles::privateLookupIn to throw IAE if the target class is an 
>> array type or primitive type.
>>
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232227
>> webrev:
>> http://cr.openjdk.java.net/~mchung/jdk14/8173975/webrev.00/
> This change looks good and I've added myself as Reviewer to the CSR.

I updated the spec and CSR to explicitly call out void in @throw IAE 
behavior per Joe's suggestion (although Class::isPrimitive treats void 
as a primitive, that's not a natural categorization).

Revised webrev:
 ? http://cr.openjdk.java.net/~mchung/jdk14/8173975/webrev.01

Mandy

From alexey.semenyuk at oracle.com  Tue Oct 29 17:42:31 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 29 Oct 2019 13:42:31 -0400
Subject: RFR: JDK-8232186: Add verification for pkg and dmg tests
In-Reply-To: <c1d9497f-7654-40f1-69dc-886fec270bca@oracle.com>
References: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>
 <2b6673e4-9b73-9e89-d46c-9bd0c7a72678@oracle.com>
 <c1d9497f-7654-40f1-69dc-886fec270bca@oracle.com>
Message-ID: <0386461d-d470-f2e4-eb9a-0f4e6e1befd3@oracle.com>

http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/test/jdk/tools/jpackage/share/AdditionalLaunchersTest.java.sdiff.html:

To disable running the test for dmg packaging, just call 
packageTest.excludeTypes(PackageType.MAC_DMG) like this is done in 
FileAssociationsTest test.

The way PackageTest.isCurrentType() is used in AdditionalLaunchersTest 
would disable fa checks for pkg packaging if the test would be executed 
in the environment that supports both dmg and pkg packaging. If you'd 
take a look at Mach5 test logs, you will see that the same test is used 
to produce and verify pkg and dmg packages in one run. Similarly on 
Windows tests build and verify exe and msi installers in a single test run.

So I'd suggest to remove PackageTest.isCurrentType() at all from 
PackageTest class. It is not needed.

- Alexey

On 10/29/2019 1:19 AM, Alexander Matveev wrote:
> Changes since last review:
>
> http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/
>
> - Hello.java combined into one test app and will be used by all tests.
> - appOutput.txt will be created in same folder as file used for file 
> association.
> - Other minor changes.
>
> Thanks,
> Alexander
>
> On 10/23/19 10:07 AM, Andy Herrick wrote:
>> looks ok to me
>>
>> /ANdy
>>
>> On 10/22/2019 5:29 PM, Alexander Matveev wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> - Removed --mac-app-store-category.
>>> - Added Hello.java test app to support file association on OS X.
>>> - Modified Hello.java to write output file to user home location if 
>>> working directory is not writable.
>>> - Fixed MacHelper:getInstallationDirectory(). It was returning extra 
>>> /Applications when --install-dir is specified.
>>> - Fixed SigningPackageTest to use path returned by withExplodedDmg 
>>> correctly.
>>> - Added install/uninstall support for pkg and dmg to 
>>> manage_packages.sh.
>>> - Fixed replaceFileName(), otherwise on OS X it was not replacing 
>>> file name correctly, since file name does not have extension.
>>> - Added NameWithSpaceTest.
>>> - Removed OptionsTest which is covered by other tests.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232186
>>>
>>> [2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/
>>>
>>> Thanks,
>>> Alexander
>


From serguei.spitsyn at oracle.com  Tue Oct 29 18:05:50 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 29 Oct 2019 11:05:50 -0700
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
Message-ID: <ee75045b-a621-2fb5-a16a-aa8027da545b@oracle.com>

Hi David,

The fix looks good to me.
I did not pay much attention to the Graal related changes though.
The test coverage for Serviceability is complete.
Running java/lang/instrument tests is not necessary.

Thanks,
Serguei


On 10/29/19 00:42, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>
> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but 
> only in small pieces each. There is also a small touch to 
> serviceability code.
>
> This change is "simply" moving the "interrupted" field out of the 
> osThread and into the java.lang.Thread so that it can be set 
> independently of whether the thread is alive (and to make things 
> easier for loom in the near future). It is very straightforward:
>
> - old scheme
> ? - interrupted field is in osThread
> ? - VM can read/write directly
> ? - Java code calls into VM to read/write
>
> - new scheme
> ? - interrupted field is in java.lang.Thread
> ? - VM has to use javaCalls to read/write "directly"
> ? - Java code can read/write directly
>
> No changes to any of the semantics regarding the actual interrupt 
> mechanism. Special thanks to Patricio for tracking down a bug I had 
> introduced in that regard!
>
> Special Note (Hi Roger!): on windows we still need to set/clear the 
> _interrupt_event used by the Process.waitFor logic. To facilitate 
> clearing via Thread.interrupted() I had to introduce a native method 
> that is a no-op except on Windows. This seemed the cheapest and least 
> intrusive means to achieve this.
>
> Other changes revolve around the fact we used to have an intrinsic for 
> Thread.isInterrupted and that is not needed any more. So we strip some 
> code out of C1/C2.
>
> The changes in the JVMCI/Graal code are a bit more far reaching as 
> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request 
> so that they can comment on the JVMCI changes and whether I have gone 
> too far or not far enough. There are a bunch of tests for interruption 
> in JVMCI that could potentially be deleted if they are only intended 
> to test the JVMCI handling of interrupt:
>
> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java 
>
>
> Testing:
> ?- Tiers 1-3 on all Oracle platforms
> ?- Focused testing on Linux x64:
> ??? - Stress runs of JSR166TestCase
> ??? - Anything that seems to use interrupt():
> ????? - JDK
> ??????? - java/lang/Thread
> ??????? - java/util/concurrent
> ??????? - jdk/internal/loader/InterruptedClassLoad.java
> ??????? - javax/management
> ??????? - java/nio/file/Files
> ??????? - java/nio/channels
> ??????? - java/net/Socket/Timeouts.java
> ??????? - java/lang/Runtime/shutdown/
> ??????? - java/lang/ProcessBuilder/Basic.java
> ??????? - com/sun/jdi/
> ????? - Hotspot
> ??????? - vmTestbase/nsk/monitoring/
> ??????? - vmTestbase/nsk/jdwp
> ??????? - vmTestbase/nsk/jdb/
> ??????? - vmTestbase/nsk/jdi/
> ??????? - vmTestbase/nsk/jvmti/
> ??????? - runtime/Thread
> ??????? - serviceability/jvmti/
> ??????? - serviceability/jdwp
> ??????? - serviceability/sa
>
> Thanks,
> David
> -----


From alexey.semenyuk at oracle.com  Tue Oct 29 18:15:39 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 29 Oct 2019 14:15:39 -0400
Subject: jpackage 14-jpackage+1-64: error 2343 when using --win-dir-chooser
In-Reply-To: <CA+QZ5tRHTnao0g9-9UpaQDUK_t7P8v8DCYUmtJVBnO7P4hv4cQ@mail.gmail.com>
References: <CA+QZ5tRHTnao0g9-9UpaQDUK_t7P8v8DCYUmtJVBnO7P4hv4cQ@mail.gmail.com>
Message-ID: <31d62d14-7344-abee-7092-2934ef6e2417@oracle.com>

Hi Serban,

Looks like a regression from the fix for 
https://bugs.openjdk.java.net/browse/JDK-8223325.
I'v created https://bugs.openjdk.java.net/browse/JDK-8233138 to track this.

- Alexey

On 10/29/2019 12:50 PM, Serban Iordache wrote:
> Issue on Windows 10, with jpackage build 14-jpackage+1-64 (2019/10/28):
> When using the --win-dir-chooser option, the generated MSI package is not
> valid.
>
> The error message issued by Windows Installer is:
> "The installer has encountered an unexpected error installing this package.
> This may indicate a problem with this package. The error code is 2343."
>
> Error code 2343 means: "Specified path is empty".
> This problem did not occur in the previous version of jpackage (build
> 14-jpackage+1-49). I assume it is caused by the removal of the
> APPLICATIONFOLDER property from:
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs.
>
> Thanks
>
> Serban


From Alan.Bateman at oracle.com  Tue Oct 29 18:25:06 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Oct 2019 18:25:06 +0000
Subject: RFR 8231451: ZipFileInputStream::skip handling of negative values
 with STORED entries
In-Reply-To: <C2055E62-461C-4363-9153-B52747E6B14F@oracle.com>
References: <B0503D84-DFC8-4250-AE62-B297A8E156DD@oracle.com>
 <8b2c022d-5fea-e3e4-c820-58ddd29135c0@oracle.com>
 <FC0E7FD7-F1D3-409E-8683-0003C6DAD93C@oracle.com>
 <fe6bf497-b192-256b-8542-2face7386931@oracle.com>
 <2E75AAD1-960A-4D75-A400-88FEDBD1D38E@oracle.com>
 <e9ac1780-d5f9-aad9-31f2-c5b2b191c162@oracle.com>
 <C2055E62-461C-4363-9153-B52747E6B14F@oracle.com>
Message-ID: <9dc99abd-0aaf-cd6e-a1e6-a3cf5e40a3a5@oracle.com>

On 25/10/2019 19:42, Lance Andersen wrote:
>
> I have updated the patch per your suggestion.
>
> The updated webrev can be found at: 
> http://cr.openjdk.java.net/~lancea/8231451/webrev.02/index.html
>
This version looks good.

-Alan

From takiguc at linux.vnet.ibm.com  Tue Oct 29 18:35:15 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 30 Oct 2019 03:35:15 +0900
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion entries
 on MS950 charset
In-Reply-To: <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
 <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
 <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>
Message-ID: <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com>

Thanks, Sato-san.

There is no special meaning to the word "until now".
I rewrote charset related testcases, then I found this issue.

I read "Frequently Asked Questions about the CSR" [1],
I tried "Create CSR" operation, but I could not determine it worked or 
not...
(Select "Create CSR" from "More" menu)
It worked ?

[1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs

Thanks,
Ichiroh Takiguchi

On 2019-10-29 03:03, naoto.sato at oracle.com wrote:
> Hi Takiguchi-san,
> 
> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> I have no idea about compatibility impact.
>> 
>> But according to 
>> ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
>> These are BOX DRAWINGS characters.
>> 
>> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
>> HORIZONTAL;;;;
>> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;;;;;N;FORMS 
>> VERTICAL SINGLE AND RIGHT DOUBLE;;;;
>> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
>> VERTICAL SINGLE AND LEFT DOUBLE;;;;
>> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
>> 
>> I don't think it was used as valuable data until now.
>> I think it's necessary to evaluate compatibility.
> 
> What do you mean by "until now"? Are there customers claiming that it
> should be corrected? Since the current JDK's mapping is not incorrect
> per se (not just "best match"), I would like to know why this needs to
> be fixed now.
> 
> Naoto
> 
>> 
>> To Sato-san,
>> if you have any question and suggestion, please let me know.
>> 
>> To other reviewers,
>> please let me know if you have any question and concern.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2019-10-19 16:36, Alan Bateman wrote:
>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>>> Hello.
>>>> 
>>>> Could you review the fix ?
>>>> 
>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>> 
>>>> I have a concern about 1-way trip conversion entries (4 entries) on 
>>>> MS950 charset.
>>>> The detail information is in JDK-8232161 [1]
>>>> 
>>> Do you know any sense on the compatibility impact of changing this? I
>>> think Naoto has the same question and we aren't sure if this one with
>>> need a compatibility property. I think it will need a CSR.
>>> 
>>> -Alan

From mandy.chung at oracle.com  Tue Oct 29 19:30:55 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 29 Oct 2019 12:30:55 -0700
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <OF714F8467.4349DFF9-ON002584A2.0038FCFA-802584A2.0042ABC8@notes.na.collabserv.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
 <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
 <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
 <CA+kOe0_uO9KTjah0JFSvRzceODMg0+-4ZZ_xZ-Sxq8hpA21ykA@mail.gmail.com>
 <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com>
 <OF714F8467.4349DFF9-ON002584A2.0038FCFA-802584A2.0042ABC8@notes.na.collabserv.com>
Message-ID: <b8689865-b6b3-18bd-101b-26d1363c0c90@oracle.com>

Hi Adam,

It'd be useful to provide a few typical scenarios that customers run into.

That would give better understanding on the problem "hard to diagnose 
why a given class was not loaded" and help the consideration on 
alternatives. ? The debug output could produce lots of trace output but 
the output does not clearly indicate the initiating class is.? I wonder 
if the problem you are looking at is related to JDK-6747450 [1] or 
really tracing the class loader delegation and search path.? Or maybe 
Java Flight Recorder is a better candidate??? Without knowing specific 
of the problems customers have, perhaps VM logging can be enhanced to 
trace the initiating class and class loader?

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

On 10/29/19 5:08 AM, Adam Farley8 wrote:
> Hey All,
>
> To restart (and re-centre) the chat on this:
>
> The issue I'm trying to solve is that it's hard to determine why a given
> class was not loaded by OpenJDK.
>
> The solution I proposed was additional (optional) debug output from the
> different classloaders.
>
> This way we can find out:
>
> - Whether any classloaders tried to load the class from your class'
> location (by displaying all locations they try to load the class from).
> - Which type of ClassLoaders tried to find your class.
> - Which classpath each ClassLoader tried to use.
> - Which modules were consulted.
> etc etc.
>
> Currently, it seems the only debug information available in this regard
> centres around:
>
> - Classes that were successfully loaded
> and
> - Exceptions when the class couldn't be loaded.
>
> So my questions are:
>
> 1) Am I trying to solve the right problem here?
>
> 2) Is there any support for this solution in principle, despite the fact
> that the webrev in its current form is...unrefined?
>
> 3) Is there a better way to get this information, with or without a code
> change?
>
> Advice or opinions are appreciated.
>
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8232773
>
> Rough example webrev:http://cr.openjdk.java.net/~afarley/8232773/webrev/  
>
> Best Regards
>
> Adam Farley
> IBM Runtimes
>
>
>
>
> From:   David Holmes<david.holmes at oracle.com>
> To:     Martin Buchholz<martinrb at google.com>
> Cc:     Ioi Lam<ioi.lam at oracle.com>, core-libs-dev
> <core-libs-dev at openjdk.java.net>, Adam Farley8<adam.farley at uk.ibm.com>
> Date:   24/10/2019 05:22
> Subject:        [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
> for Specific Classes
>
>
>
> Hi Martin,
>
> This is going a bit OT I think ...
>
> On 24/10/2019 1:24 pm, Martin Buchholz wrote:
>> On Tue, Oct 22, 2019 at 3:58 PM David Holmes <david.holmes at oracle.com  
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>
>>      Perhaps one aspect of the class loading/resolution/initialization
>>      process that can lead to confusion here is that if a class fails to
>>      execute its static initialization then it is marked as Erroneous and
>>      all
>>      subsequent attempts to use that class result in NoClassDefFoundError
>>      being thrown. If the original ExceptionInInitializerError got
> swallowed
>>      somewhere then that can cause great confusion as to why the later
> NCDFE
>>      occurs. The VM logging should help in that case - though I'd have to
>>      confirm that (if it doesn't that should be fixed).
>>
>>
>> I had a need to debug an error in a <clinit> this week and was again
>> frustrated by the difficulty.
>> Classes falling into Erroneous state are rare so it seems reasonable to
>> save the exception as a cause for the subsequent NCDFE (probably can't
>> fix the misleading name of the exception)
> So as you know such a request existed:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8048190&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=AfL8IyQ5gm4a9cA4orx0EnUwiGqvG6rei-DuA8gA0jQ&s=pzILDarpf9cN_MvQFqk1u3YZqFzSCRbBZVoRdFw4lS4&e=  
>
>
> and was closed as it was considered that TraceExceptions (now
> -Xlog:exceptions) would provide the additional information. As noted in
> that bug there are also semantic issues about recording the cause of an
> exception in thread B, with an exception object that was thrown in
> thread A. So unless someone comes up with a very convincing argument, or
> else it prepared to do the work, I don't see that being re-opened.
>
>> I couldn't find a way to get hotspot to report the stack trace of all
>> exceptions that are thrown; -Xlog:exceptions=trace does not .
> -Xlog:exceptions shows where the exception is thrown and how it proceeds
> up the stack. It doesn't print the full stacktrace. That seems like a
> logging request for the Throwable constructor, or fillInStackTrace, to
> me, rather than trying to have the VM do it. IIRC we store minimal VM
> information in the backTrace which is expanded when needed into the full
> StacktraceElements array.
>> I was also frustrated that a StackOverflowError failed to report the
>> name of the thread and the stack size that was exceeded.  But
>> -Xlog:threads*=trace helped there.
> The issue there is that SOE instances are allocated natively without
> executing any Java code (as we have run out of the Java stack) so we
> can't (easily) create a String message for the exception. However
> -Xlog:exceptions could be expanded to report that information at the
> point we throw the SOE. I filed - JDK-8232923.
>
> Cheers,
> David
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>


From raffaello.giulietti at gmail.com  Tue Oct 29 19:33:13 2019
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Tue, 29 Oct 2019 20:33:13 +0100
Subject: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double)
 sometimes produces incorrect results
In-Reply-To: <9b15b269-1029-d07f-fe47-6b0cb5979e04@gmail.com>
References: <9b15b269-1029-d07f-fe47-6b0cb5979e04@gmail.com>
Message-ID: <422629ce-e60e-1f81-2203-7dfc43384f8f@gmail.com>

Since nothing seems to have moved, here's the familiar monthly reminder ;-)

Greetings
Raffaello




On 2019-08-30 10:47, Raffaello Giulietti wrote:
> Hi,
> 
> just a gentle reminder for a RFR of [1] (see [5] for the original request).
> 
> An efficient implementation can be found on [2] and in Brian 
> Burkhalter's webrev area [3]. This also requires a review. The full 
> details are discussed in [4].
> 
> 
> Greetings
> Raffaello
> 
> ----
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8202555
> [2] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059783.html 
> 
> [3] http://cr.openjdk.java.net/~bpb/4511638/webrev.03/
> [4] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058
> [5] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061548.html

From mandy.chung at oracle.com  Tue Oct 29 19:46:00 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 29 Oct 2019 12:46:00 -0700
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
Message-ID: <d9c95a5f-6b78-2db5-f8f5-69b494fe4d45@oracle.com>



On 10/29/19 9:26 AM, Alan Bateman wrote:
> On 23/10/2019 08:25, Alan Bateman wrote:
>>
>> Thread::countStackFrames has been deprecated for 20+ years and has 
>> been marked for-removal since Java SE 9. I'd like to remove it for 
>> Java SE 14. It's was never a well-defined method and I've been unable 
>> to find anything that uses it. The StackWalker API is a much better 
>> solution for code that is interested in the number of stack frames.
> Joe Darcy has suggested degrading the method in advance of its 
> removal. We did the same with stop(Throwable) when we changed it to 
> throw UOE in Java SE 8 before finally removing it in 11. Here is the 
> updated webrev and CSR. The CSR will need to be re-reviewed. The 
> method description is brief and the same as what we did for 
> stop(Throwable).
>
> http://cr.openjdk.java.net/~alanb/8205132/webrev.02/
>
> https://bugs.openjdk.java.net/browse/JDK-8232654
>

Both look good.

> Also just to summarize the discussion/objection from Seth Lytle. I 
> think we've established that that it was a regression in JDK 10 that 
> allowed that example to work. The method has always been specified to 
> fail when the thread is not suspended.

Good find and I agree it's a regression.

Mandy


From openjdk at icemanx.nl  Tue Oct 29 20:12:39 2019
From: openjdk at icemanx.nl (Rob Spoor)
Date: Tue, 29 Oct 2019 21:12:39 +0100
Subject: Question about String.toUpperCase behaviour
In-Reply-To: <878sp46231.fsf@mid.deneb.enyo.de>
References: <32507691572282872@sas2-a74be5364cfb.qloud-c.yandex.net>
 <878sp46231.fsf@mid.deneb.enyo.de>
Message-ID: <c861cb49-9dc2-39cb-d487-e6bfe0b4b984@icemanx.nl>

On 28/10/2019 21:34, Florian Weimer wrote:
> * ?????? ???????:
> 
>> Hello,
>>
>> current implementation of e.g. String.toUpperCase() returns the object
>> it was called on in case all code points are in upper case.
>>
>> E.g. this test
>>
>> @Test
>> public void upperCase() {
>>    String str = "AZ";                // English
>>    assert str == str.toUpperCase();
>>    
>>    str = "??";                       // Russian
>>    assert str == str.toUpperCase();
>> }
>>
>> passes for both Latin-1 and UTF-16. This assumption allows to simplify this:
>>
>> boolean isUpperCase = str.toUpperCase().equals(str);
>>
>> to
>>
>> boolean isUpperCase = str.toUpperCase() == str;
>>
>> Could this transformation be legal assuming that existing behaviour of
>> String.toUpperCase is not documented?
> 
> Valid for whom?  For the JDK itself, sure.  But programmers really
> should not assume such undocumented behavior when writing Java
> programs, and neither shoud external tools targeting the JVM.
> 

I agree. There is no reason to use == instead of equals. Not for 
readability, because it will most likely confuse people who will come 
asking why you're not using equals. Not for performance, because since 
at least Java 7 String.equals starts with this:

         if (this == anObject) {
             return true;
         }

So in other words: keep using equals, it's the cleaner option.

From hboehm at google.com  Tue Oct 29 20:35:32 2019
From: hboehm at google.com (Hans Boehm)
Date: Tue, 29 Oct 2019 13:35:32 -0700
Subject: Question about String.toUpperCase behaviour
In-Reply-To: <c861cb49-9dc2-39cb-d487-e6bfe0b4b984@icemanx.nl>
References: <32507691572282872@sas2-a74be5364cfb.qloud-c.yandex.net>
 <878sp46231.fsf@mid.deneb.enyo.de>
 <c861cb49-9dc2-39cb-d487-e6bfe0b4b984@icemanx.nl>
Message-ID: <CAMOCf+jJe4OD=1iwaHcTefTftZeqWz2tftQuciFV-M+nrcSfNg@mail.gmail.com>

On Tue, Oct 29, 2019 at 1:12 PM Rob Spoor <openjdk at icemanx.nl> wrote:
>
> I agree. There is no reason to use == instead of equals. Not for
> readability, because it will most likely confuse people who will come
> asking why you're not using equals. Not for performance, because since
> at least Java 7 String.equals starts with this:
>
>          if (this == anObject) {
>              return true;
>          }
>
That doesn't remove the performance difference when the string is NOT upper
case.

From ioi.lam at oracle.com  Tue Oct 29 20:36:15 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 29 Oct 2019 13:36:15 -0700
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: <b8689865-b6b3-18bd-101b-26d1363c0c90@oracle.com>
References: <OF91B328F5.C8BE9E0E-ON0025849B.003845BF-8025849B.003AA694@notes.na.collabserv.com>
 <a5362b93-6107-6472-415b-09eadf0898bd@oracle.com>
 <OFAF8A4EE6.5A997380-ON0025849B.0052F80A-8025849B.00564F23@notes.na.collabserv.com>
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
 <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
 <CA+kOe0_uO9KTjah0JFSvRzceODMg0+-4ZZ_xZ-Sxq8hpA21ykA@mail.gmail.com>
 <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com>
 <OF714F8467.4349DFF9-ON002584A2.0038FCFA-802584A2.0042ABC8@notes.na.collabserv.com>
 <b8689865-b6b3-18bd-101b-26d1363c0c90@oracle.com>
Message-ID: <21e5a9fc-0c5c-989d-1e05-a036f55b9167@oracle.com>

For tracing classes that fail to load:

Currently, if a delegated class loader can't find a class, if will throw 
ClassNotFoundException in its loadClass() method. So if we run with 
-Xlog:exceptions, we may get lots of CNFEs for classes that are 
eventually found. This doesn't happen with the JDK's built-in 
boot/platform loaders anymore, as they use package information to avoid 
unnecessary delegation. However, with JavaEE or OSGi type of apps, such 
superfluous CNFE traces may make it difficult to analyze classes that 
actually fail to load.

One thing the VM can help is to provide logging where a class has 
definitely failed to load. This can be done by logging
in SystemDictionary::load_shared_class, when the upcall to 
ClassLoader.loadClass() throws an exception.

====
$ hg diff
diff -r 94fe833a244b src/hotspot/share/classfile/systemDictionary.cpp
--- a/src/hotspot/share/classfile/systemDictionary.cpp??? Thu Oct 10 
10:48:31 2019 -0700
+++ b/src/hotspot/share/classfile/systemDictionary.cpp??? Tue Oct 29 
13:31:23 2019 -0700
@@ -52,6 +52,7 @@
 ?#include "interpreter/interpreter.hpp"
 ?#include "jfr/jfrEvents.hpp"
 ?#include "logging/log.hpp"
+#include "logging/logMessage.hpp"
 ?#include "logging/logStream.hpp"
 ?#include "memory/filemap.hpp"
 ?#include "memory/heapShared.hpp"
@@ -1506,7 +1507,20 @@
 ???????????????????????????? vmSymbols::loadClass_name(),
 ???????????????????????????? vmSymbols::string_class_signature(),
 ???????????????????????????? string,
-??????????????????????????? CHECK_NULL);
+??????????????????????????? THREAD);
+??? if (HAS_PENDING_EXCEPTION) {
+????? if (log_is_enabled(Info, class, exceptions)) {
+??????? ResourceMark rm(THREAD);
+??????? LogMessage(class, exceptions) msg;
+??????? stringStream debug_stream;
+??????? ClassLoaderData *loader_data = class_loader_data(class_loader);
+??????? debug_stream.print("Failed to load class %s by [", 
java_lang_String::as_quoted_ascii(string()));
+??????? loader_data->print_value_on(&debug_stream);
+??????? debug_stream.print("]");
+??????? msg.info("%s", debug_stream.as_string());
+????? }
+????? return NULL;
+??? }

 ???? assert(result.get_type() == T_OBJECT, "just checking");
 ???? oop obj = (oop) result.get_jobject();
====

Here are some examples. Note that the second case will produce 5 
separate CNFE logs for the java.lang.XXX class if -Xlog:exceptions is 
used instead.

$ java -Xlog:class+exceptions -cp ~/tmp HelloX
[0.665s][info][class,exceptions] Failed to load class HelloX by [loader 
data: 0x00007f3328511550
 ????? for instance a 
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x000000045104f998}]

$ java d -Xlog:class+exceptions -cp ~/tmp java.lang.XXX
[0.655s][info][class,exceptions] Failed to load class java.lang.XXX by 
[loader data: 0x00007f3fa0510ed0
 ????? for instance a 
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x000000045104f9a0}]


We can probably print the full call stack as well, with the "trace" 
logging level, if that's useful.


Thanks
- Ioi





On 10/29/19 12:30 PM, Mandy Chung wrote:
> Hi Adam,
>
> It'd be useful to provide a few typical scenarios that customers run 
> into.
>
> That would give better understanding on the problem "hard to diagnose 
> why a given class was not loaded" and help the consideration on 
> alternatives. ? The debug output could produce lots of trace output 
> but the output does not clearly indicate the initiating class is.? I 
> wonder if the problem you are looking at is related to JDK-6747450 [1] 
> or really tracing the class loader delegation and search path.? Or 
> maybe Java Flight Recorder is a better candidate??? Without knowing 
> specific of the problems customers have, perhaps VM logging can be 
> enhanced to trace the initiating class and class loader?
>
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-6747450
>
> On 10/29/19 5:08 AM, Adam Farley8 wrote:
>> Hey All,
>>
>> To restart (and re-centre) the chat on this:
>>
>> The issue I'm trying to solve is that it's hard to determine why a given
>> class was not loaded by OpenJDK.
>>
>> The solution I proposed was additional (optional) debug output from the
>> different classloaders.
>>
>> This way we can find out:
>>
>> - Whether any classloaders tried to load the class from your class'
>> location (by displaying all locations they try to load the class from).
>> - Which type of ClassLoaders tried to find your class.
>> - Which classpath each ClassLoader tried to use.
>> - Which modules were consulted.
>> etc etc.
>>
>> Currently, it seems the only debug information available in this regard
>> centres around:
>>
>> - Classes that were successfully loaded
>> and
>> - Exceptions when the class couldn't be loaded.
>>
>> So my questions are:
>>
>> 1) Am I trying to solve the right problem here?
>>
>> 2) Is there any support for this solution in principle, despite the fact
>> that the webrev in its current form is...unrefined?
>>
>> 3) Is there a better way to get this information, with or without a code
>> change?
>>
>> Advice or opinions are appreciated.
>>
>>
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8232773
>>
>> Rough example webrev:http://cr.openjdk.java.net/~afarley/8232773/webrev/
>> Best Regards
>>
>> Adam Farley
>> IBM Runtimes
>>
>>
>>
>>
>> From:?? David Holmes<david.holmes at oracle.com>
>> To:???? Martin Buchholz<martinrb at google.com>
>> Cc:???? Ioi Lam<ioi.lam at oracle.com>, core-libs-dev
>> <core-libs-dev at openjdk.java.net>, Adam Farley8<adam.farley at uk.ibm.com>
>> Date:?? 24/10/2019 05:22
>> Subject:??????? [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug 
>> Output
>> for Specific Classes
>>
>>
>>
>> Hi Martin,
>>
>> This is going a bit OT I think ...
>>
>> On 24/10/2019 1:24 pm, Martin Buchholz wrote:
>>> On Tue, Oct 22, 2019 at 3:58 PM David Holmes 
>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>
>>> ???? Perhaps one aspect of the class loading/resolution/initialization
>>> ???? process that can lead to confusion here is that if a class 
>>> fails to
>>> ???? execute its static initialization then it is marked as 
>>> Erroneous and
>>> ???? all
>>> ???? subsequent attempts to use that class result in 
>>> NoClassDefFoundError
>>> ???? being thrown. If the original ExceptionInInitializerError got
>> swallowed
>>> ???? somewhere then that can cause great confusion as to why the later
>> NCDFE
>>> ???? occurs. The VM logging should help in that case - though I'd 
>>> have to
>>> ???? confirm that (if it doesn't that should be fixed).
>>>
>>>
>>> I had a need to debug an error in a <clinit> this week and was again
>>> frustrated by the difficulty.
>>> Classes falling into Erroneous state are rare so it seems reasonable to
>>> save the exception as a cause for the subsequent NCDFE (probably can't
>>> fix the misleading name of the exception)
>> So as you know such a request existed:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8048190&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=AfL8IyQ5gm4a9cA4orx0EnUwiGqvG6rei-DuA8gA0jQ&s=pzILDarpf9cN_MvQFqk1u3YZqFzSCRbBZVoRdFw4lS4&e= 
>>
>>
>> and was closed as it was considered that TraceExceptions (now
>> -Xlog:exceptions) would provide the additional information. As noted in
>> that bug there are also semantic issues about recording the cause of an
>> exception in thread B, with an exception object that was thrown in
>> thread A. So unless someone comes up with a very convincing argument, or
>> else it prepared to do the work, I don't see that being re-opened.
>>
>>> I couldn't find a way to get hotspot to report the stack trace of all
>>> exceptions that are thrown; -Xlog:exceptions=trace does not .
>> -Xlog:exceptions shows where the exception is thrown and how it proceeds
>> up the stack. It doesn't print the full stacktrace. That seems like a
>> logging request for the Throwable constructor, or fillInStackTrace, to
>> me, rather than trying to have the VM do it. IIRC we store minimal VM
>> information in the backTrace which is expanded when needed into the full
>> StacktraceElements array.
>>> I was also frustrated that a StackOverflowError failed to report the
>>> name of the thread and the stack size that was exceeded.? But
>>> -Xlog:threads*=trace helped there.
>> The issue there is that SOE instances are allocated natively without
>> executing any Java code (as we have run out of the Java stack) so we
>> can't (easily) create a String message for the exception. However
>> -Xlog:exceptions could be expanded to report that information at the
>> point we throw the SOE. I filed - JDK-8232923.
>>
>> Cheers,
>> David
>>
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>> PO6 3AU
>>
>


From daniel.daugherty at oracle.com  Tue Oct 29 20:51:21 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 29 Oct 2019 16:51:21 -0400
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
Message-ID: <422bc3b5-861f-0c86-0878-1ba392b342b1@oracle.com>

On 10/29/19 3:42 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/

make/hotspot/symbols/symbols-unix
 ??? No comments.

src/hotspot/os/windows/osThread_windows.cpp
 ??? No comments.

src/hotspot/os/windows/osThread_windows.hpp
 ??? No comments.

src/hotspot/share/aot/aotCodeHeap.cpp
 ??? Skipped.

src/hotspot/share/classfile/javaClasses.cpp
 ??? No comments.

src/hotspot/share/classfile/javaClasses.hpp
 ??? No comments.

src/hotspot/share/classfile/vmSymbols.cpp
 ??? No comments.

src/hotspot/share/classfile/vmSymbols.hpp
 ??? No comments.

src/hotspot/share/include/jvm.h
 ??? No comments.

src/hotspot/share/jvmci/jvmciRuntime.cpp
src/hotspot/share/jvmci/jvmciRuntime.hpp
src/hotspot/share/jvmci/vmStructs_jvmci.cpp
 ??? Skipped these three.

src/hotspot/share/oops/oop.hpp
 ??? No comments.

src/hotspot/share/oops/oop.inline.hpp
 ??? No comments.

src/hotspot/share/opto/c2compiler.cpp
 ??? No comments.

src/hotspot/share/opto/library_call.cpp
 ??? No comments.

src/hotspot/share/prims/jvm.cpp
 ??? No comments.

src/hotspot/share/prims/jvmtiEnv.cpp
 ??? No comments.

src/hotspot/share/prims/jvmtiEnvBase.cpp
 ??? No comments.

src/hotspot/share/runtime/osThread.cpp
 ??? No comments.

src/hotspot/share/runtime/osThread.hpp
 ??? No comments.

src/hotspot/share/runtime/thread.cpp
 ??? No comments.

src/hotspot/share/runtime/vmStructs.cpp
 ??? No comments.

src/java.base/share/classes/java/lang/Thread.java
 ??? No comments.

src/java.base/share/native/libjava/Thread.c
 ??? L76: ? // Need to reset the interrupt event used by Process.waitFor
 ??? L77: ? ResetEvent((HANDLE) JVM_GetThreadInterruptEvent());
 ??????? nit - the indent in JDK .c files is four spaces.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/OSThread.java
 ??? No comments.

src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ThreadSubstitutions.java
 ??? Skipped these 5 graal files.

Thumbs up! I only have one nit above and don't need to see
another webrev if you decide to fix it.

Thanks for being so thorough on your testing.

Dan


>
> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but 
> only in small pieces each. There is also a small touch to 
> serviceability code.
>
> This change is "simply" moving the "interrupted" field out of the 
> osThread and into the java.lang.Thread so that it can be set 
> independently of whether the thread is alive (and to make things 
> easier for loom in the near future). It is very straightforward:
>
> - old scheme
> ? - interrupted field is in osThread
> ? - VM can read/write directly
> ? - Java code calls into VM to read/write
>
> - new scheme
> ? - interrupted field is in java.lang.Thread
> ? - VM has to use javaCalls to read/write "directly"
> ? - Java code can read/write directly
>
> No changes to any of the semantics regarding the actual interrupt 
> mechanism. Special thanks to Patricio for tracking down a bug I had 
> introduced in that regard!
>
> Special Note (Hi Roger!): on windows we still need to set/clear the 
> _interrupt_event used by the Process.waitFor logic. To facilitate 
> clearing via Thread.interrupted() I had to introduce a native method 
> that is a no-op except on Windows. This seemed the cheapest and least 
> intrusive means to achieve this.
>
> Other changes revolve around the fact we used to have an intrinsic for 
> Thread.isInterrupted and that is not needed any more. So we strip some 
> code out of C1/C2.
>
> The changes in the JVMCI/Graal code are a bit more far reaching as 
> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request 
> so that they can comment on the JVMCI changes and whether I have gone 
> too far or not far enough. There are a bunch of tests for interruption 
> in JVMCI that could potentially be deleted if they are only intended 
> to test the JVMCI handling of interrupt:
>
> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java 
>
>
> Testing:
> ?- Tiers 1-3 on all Oracle platforms
> ?- Focused testing on Linux x64:
> ??? - Stress runs of JSR166TestCase
> ??? - Anything that seems to use interrupt():
> ????? - JDK
> ??????? - java/lang/Thread
> ??????? - java/util/concurrent
> ??????? - jdk/internal/loader/InterruptedClassLoad.java
> ??????? - javax/management
> ??????? - java/nio/file/Files
> ??????? - java/nio/channels
> ??????? - java/net/Socket/Timeouts.java
> ??????? - java/lang/Runtime/shutdown/
> ??????? - java/lang/ProcessBuilder/Basic.java
> ??????? - com/sun/jdi/
> ????? - Hotspot
> ??????? - vmTestbase/nsk/monitoring/
> ??????? - vmTestbase/nsk/jdwp
> ??????? - vmTestbase/nsk/jdb/
> ??????? - vmTestbase/nsk/jdi/
> ??????? - vmTestbase/nsk/jvmti/
> ??????? - runtime/Thread
> ??????? - serviceability/jvmti/
> ??????? - serviceability/jdwp
> ??????? - serviceability/sa
>
> Thanks,
> David
> -----


From daniel.daugherty at oracle.com  Tue Oct 29 21:02:19 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 29 Oct 2019 17:02:19 -0400
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
Message-ID: <6b5e156f-2249-2231-92c7-16d4607eff51@oracle.com>

On 10/29/19 12:26 PM, Alan Bateman wrote:
> On 23/10/2019 08:25, Alan Bateman wrote:
>>
>> Thread::countStackFrames has been deprecated for 20+ years and has 
>> been marked for-removal since Java SE 9. I'd like to remove it for 
>> Java SE 14. It's was never a well-defined method and I've been unable 
>> to find anything that uses it. The StackWalker API is a much better 
>> solution for code that is interested in the number of stack frames.
> Joe Darcy has suggested degrading the method in advance of its 
> removal. We did the same with stop(Throwable) when we changed it to 
> throw UOE in Java SE 8 before finally removing it in 11. Here is the 
> updated webrev and CSR. The CSR will need to be re-reviewed. The 
> method description is brief and the same as what we did for 
> stop(Throwable).
>
> http://cr.openjdk.java.net/~alanb/8205132/webrev.02/

make/hotspot/symbols/symbols-unix
 ??? No comments.

src/hotspot/share/include/jvm.h
 ??? No comments.

src/hotspot/share/prims/jvm.cpp
 ??? No comments.

src/java.base/share/classes/java/lang/Thread.java
 ??? No comments.

src/java.base/share/native/libjava/Thread.c
 ??? No comments.

test/jdk/java/lang/Thread/CountStackFrames.java
 ??? No comments.

test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java
 ??? Deleted file. No comments.

Thumbs up.


> https://bugs.openjdk.java.net/browse/JDK-8232654
>
> Also just to summarize the discussion/objection from Seth Lytle. I 
> think we've established that that it was a regression in JDK 10 that 
> allowed that example to work. The method has always been specified to 
> fail when the thread is not suspended.

I believe that regression is due my work on Thread-SMR (Safe Memory
Reclaimation).

Do we need a bug filed against JDK1[012] to document the regression?

Dan


>
> -Alan


From forax at univ-mlv.fr  Tue Oct 29 21:38:55 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 29 Oct 2019 22:38:55 +0100 (CET)
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
Message-ID: <228101443.839885.1572385135051.JavaMail.zimbra@u-pem.fr>

Hi David,
in java.lang.Thread interrupt0 should be renamed to setInterruptEvent, because what it does now
and I don't really understand the comment in interrupted(), if a thread is interrupted by two other threads calling interrupt(), you will loose an interrupt anyway.

R?mi

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>, "hotspot compiler"
> <hotspot-compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Doug Simon"
> <doug.simon at oracle.com>, "TOM.RODRIGUEZ" <tom.rodriguez at oracle.com>, "serviceability-dev"
> <serviceability-dev at openjdk.java.net>, "Roger Riggs" <Roger.Riggs at oracle.com>
> Envoy?: Mardi 29 Octobre 2019 08:42:08
> Objet: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination

> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
> 
> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but
> only in small pieces each. There is also a small touch to serviceability
> code.
> 
> This change is "simply" moving the "interrupted" field out of the
> osThread and into the java.lang.Thread so that it can be set
> independently of whether the thread is alive (and to make things easier
> for loom in the near future). It is very straightforward:
> 
> - old scheme
>   - interrupted field is in osThread
>   - VM can read/write directly
>   - Java code calls into VM to read/write
> 
> - new scheme
>   - interrupted field is in java.lang.Thread
>   - VM has to use javaCalls to read/write "directly"
>   - Java code can read/write directly
> 
> No changes to any of the semantics regarding the actual interrupt
> mechanism. Special thanks to Patricio for tracking down a bug I had
> introduced in that regard!
> 
> Special Note (Hi Roger!): on windows we still need to set/clear the
> _interrupt_event used by the Process.waitFor logic. To facilitate
> clearing via Thread.interrupted() I had to introduce a native method
> that is a no-op except on Windows. This seemed the cheapest and least
> intrusive means to achieve this.
> 
> Other changes revolve around the fact we used to have an intrinsic for
> Thread.isInterrupted and that is not needed any more. So we strip some
> code out of C1/C2.
> 
> The changes in the JVMCI/Graal code are a bit more far reaching as
> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request
> so that they can comment on the JVMCI changes and whether I have gone
> too far or not far enough. There are a bunch of tests for interruption
> in JVMCI that could potentially be deleted if they are only intended to
> test the JVMCI handling of interrupt:
> 
> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
> 
> Testing:
>  - Tiers 1-3 on all Oracle platforms
>  - Focused testing on Linux x64:
>     - Stress runs of JSR166TestCase
>     - Anything that seems to use interrupt():
>       - JDK
>         - java/lang/Thread
>         - java/util/concurrent
>         - jdk/internal/loader/InterruptedClassLoad.java
>         - javax/management
>         - java/nio/file/Files
>         - java/nio/channels
>         - java/net/Socket/Timeouts.java
>         - java/lang/Runtime/shutdown/
>         - java/lang/ProcessBuilder/Basic.java
>         - com/sun/jdi/
>       - Hotspot
>         - vmTestbase/nsk/monitoring/
>         - vmTestbase/nsk/jdwp
>         - vmTestbase/nsk/jdb/
>         - vmTestbase/nsk/jdi/
>         - vmTestbase/nsk/jvmti/
>         - runtime/Thread
>         - serviceability/jvmti/
>         - serviceability/jdwp
>         - serviceability/sa
> 
> Thanks,
> David
> -----

From VOJIN.JOVANOVIC at ORACLE.COM  Tue Oct 29 22:14:14 2019
From: VOJIN.JOVANOVIC at ORACLE.COM (Vojin Jovanovic)
Date: Tue, 29 Oct 2019 23:14:14 +0100
Subject: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes
 generated lambdas
In-Reply-To: <2685EF9A-EBB2-4DA0-9CE4-BCBF4A3556D3@oracle.com>
References: <774305B8-A4E4-4B2A-AA41-990E23D9A385@ORACLE.COM>
 <20191028152958.506178281@eggemoggin.niobe.net>
 <583FFD59-DEEF-42AD-8782-DD504DD93AA5@oracle.com>
 <22C5CDFD-9BEC-48E8-B05E-8AD67377D7F2@ORACLE.COM>
 <2685EF9A-EBB2-4DA0-9CE4-BCBF4A3556D3@oracle.com>
Message-ID: <95D2A02B-0EB8-4249-B731-43973C1C4636@ORACLE.COM>

There are still ongoing discussions (as comments on https://bugs.openjdk.java.net/browse/JDK-8232806) as to whether the performance implications and loss of reference equality caused by this change are acceptable for the GraalVM Native Image. 

I would suggest to hold off merging this change until these discussions are resolved. The alternative implementation that is discussed follows:

  https://vjovanov.github.io/webrevs/8233090/

Cheers,
- Vojin

> On 29 Oct 2019, at 18:01, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Vojin,
> 
> I think it would be useful to include such a test (for capturing and non-capturing) to protect against a regression.
> 
> Thanks,
> Paul.
> 
>> On Oct 29, 2019, at 3:57 AM, Vojin Jovanovic <VOJIN.JOVANOVIC at ORACLE.COM> wrote:
>> 
>> The only way I see to test this (without calling LMF directly) is to inspect the stack trace created in a static initialiser of a lambda super-type. The stack trace should not contain LMF when -Djdk.internal.lambda.disableEagerInitialization=true. Let me know if this kind of a test reasonable; I can easily add it. ? Vojin
>> 
>>> On 29 Oct 2019, at 00:29, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> 
>>>> 
>>>> On Oct 28, 2019, at 3:29 PM, mark.reinhold at oracle.com wrote:
>>>> 
>>>> 2019/10/28 11:10:25 -0700, vojin.jovanovic at oracle.com:
>>>>> This email proposes a change to the LambdaMetaFactory that allows to
>>>>> disable eager initialization (with Unsafe) of generated lambdas. ...
>>>>> 
>>>>> ...
>>>>> 
>>>>> After the discussion with Brian Goetz, we have trimmed down to the
>>>>> following change:
>>>>> 
>>>>> https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
>>>>> 
>>>>> The evolution of this change can be found at the issue: 
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8232806
>>>> 
>>>> Vojin -- I?d be happy to sponsor this change on your behalf.
>>>> 
>>>> I?ve posted a webrev that incorporates the suggestions that Paul and
>>>> R?mi made in the JBS issue:
>>>> 
>>>> https://cr.openjdk.java.net/~mr/rev/8232806/
>>>> 
>>>> Paul, R?mi -- please make sure that I understood your suggestions
>>>> correctly
>>> 
>>> Looks good to me.
>>> 
>>> I don?t know of an easy way to test when the new sys property is true that the implementing class is not initialized. Seems to require an explicit call to LMF, cracking open the calls site?s target, and calling Unsafe.shouldBeInitialized (presuming initialization is not tickled before that call and the call works!).  Perhaps a future exercise if someone wanna takes that on.
>>> 
>>> Paul.
>> 
> 


From fujie at loongson.cn  Wed Oct 30 00:49:02 2019
From: fujie at loongson.cn (Jie Fu)
Date: Wed, 30 Oct 2019 08:49:02 +0800
Subject: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java
 are not reproducable
In-Reply-To: <440a7222-4590-6a3f-7ca5-95c7be5906cf@oracle.com>
References: <c2d529ef-2d10-2799-1919-914f6cdee9f8@loongson.cn>
 <e3d38bde-f73e-3bc0-42be-0516bb9d54d3@oracle.com>
 <761659c2-bcab-c8d4-258b-40d19fe4cd08@loongson.cn>
 <2f4b97f6-3839-87ae-44d2-70f03bef9945@oracle.com>
 <fb835ceb-6a5b-2803-22e0-50da6d19d3ca@loongson.cn>
 <843adb6a-41a4-a336-bfff-2b7fa4cf2086@oracle.com>
 <5de8fdf2-b90d-d828-93e5-5b99f48f79cf@loongson.cn>
 <440a7222-4590-6a3f-7ca5-95c7be5906cf@oracle.com>
Message-ID: <0529da9b-95ab-144e-0021-789535d92e2e@loongson.cn>

Nice catch!

Thank you so much, Mandy.

On 2019/10/30 ??1:19, Mandy Chung wrote:
> Hi Jie,
>
> This looks good but I ran into test/jdk/tools/jlink/BasicTest failure 
> with OOME in some system configuration.?? I made a minor fix to the 
> cleanup of the configuration collections after the plugin executes.
>
> ???????? // Let it go
> -??????? speciesTypes = null;
> -??????? invokerTypes = null;
> -??????? dmhMethods = null;
> +??????? speciesTypes.clear();
> +??????? invokerTypes.clear();
> +??????? callSiteTypes.clear();
> +??????? dmhMethods.clear();
>
> I have pushed the patch with the above change.
>
> Mandy
>
> On 10/25/19 7:34 PM, Jie Fu wrote:
>>
>> Hi Mandy,
>>
>> Thanks for your review and help.
>> I think your refactoring is a nice improvement.
>>
>> Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.03/
>> It seems much better now.
>>
>> Testing:
>> ?- make test TEST="tier1 tier2 tier3" CONF=release
>>
>> Thanks a lot.
>> Best regards,
>> Jie
>>
>> On 2019/10/26 ??3:29, Mandy Chung wrote:
>>>
>>>
>>> On 10/23/19 11:21 PM, Jie Fu wrote:
>>>> Hi Mandy,
>>>>
>>>> Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.02/
>>>> It seems better now.
>>>>
>>> It's better while I think this can be further simplified.
>>>
>>> line 101 to 217 involves iterating on the default sets/map and then
>>> create a new TreeSet and TreeMap and then process the config file.
>>>
>>> Currently addDMHMethodType validates the methodType and then adds
>>> to dmhMethods which ensures that the map entry value is a sorted set.
>>> So we can add one new method to add an entry to speciesTypes,
>>> invokeTypes and callSiteTypes which performs the validation and then
>>> add to the corresponding collection.
>>>
>>> I think that way the code will be cleaner.  Below is something for
>>> your reference.
>>>
>>> Mandy
>>>
>>> diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
>>> --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
>>> +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
>>> @@ -75,13 +75,13 @@
>>>       private static final JavaLangInvokeAccess JLIA
>>>               = SharedSecrets.getJavaLangInvokeAccess();
>>>   
>>> -    Set<String> speciesTypes = Set.of();
>>> +    private final TreeSet<String> speciesTypes = new TreeSet<>();
>>>   
>>> -    Set<String> invokerTypes = Set.of();
>>> +    private final TreeSet<String> invokerTypes = new TreeSet<>();
>>>   
>>> -    Set<String> callSiteTypes = Set.of();
>>> +    private final TreeSet<String> callSiteTypes = new TreeSet<>();
>>>   
>>> -    Map<String, Set<String>> dmhMethods = Map.of();
>>> +    private final Map<String, Set<String>> dmhMethods = new TreeMap<>();
>>>   
>>>       String mainArgument;
>>>   
>>> @@ -187,21 +187,31 @@
>>>           mainArgument = config.get(NAME);
>>>       }
>>>
>>> +    private void addSpeciesType(String type) {
>>> +        speciesTypes.add(expandSignature(type));
>>> +    }
>>> +
>>> +    private void addInvokerType(String methodType) {
>>> +        validateMethodType(methodType);
>>> +        invokerTypes.add(methodType);
>>> +    }
>>> +
>>> +    private void addCallSisterType(String csType) {
>>> +        validateMethodType(csType);
>>> +        callSiteTypes.add(csType);
>>> +    }
>>> +
>>>       public void initialize(ResourcePool in) {
>>>           // Start with the default configuration
>>> -        speciesTypes = defaultSpecies().stream()
>>> -                .map(type -> expandSignature(type))
>>> -                .collect(Collectors.toSet());
>>> +        defaultSpecies().stream().forEach(this::addSpeciesType);
>>>   
>>> -        invokerTypes = defaultInvokers();
>>> -        validateMethodTypes(invokerTypes);
>>> +        defaultInvokers().stream().forEach(this::validateMethodType);
>>>   
>>> -        callSiteTypes = defaultCallSiteTypes();
>>> +        defaultCallSiteTypes().stream().forEach(this::addCallSisterType);
>>>   
>>> -        dmhMethods = defaultDMHMethods();
>>> -        for (Set<String> dmhMethodTypes : dmhMethods.values()) {
>>> -            validateMethodTypes(dmhMethodTypes);
>>> -        }
>>> +        defaultDMHMethods().entrySet().stream().forEach(e -> {
>>> +            e.getValue().stream().forEach(type -> addDMHMethodType(e.getKey(), type))
>>> +        });
>>>   
>>>           // Extend the default configuration with the contents in the supplied
>>>           // input file - if none was supplied we look for the default file
>>> @@ -225,18 +235,6 @@
>>>       }
>>>
>>>   
>>>       private void readTraceConfig(Stream<String> lines) {
>>> -        // Use TreeSet/TreeMap to keep things sorted in a deterministic
>>> -        // order to avoid scrambling the layout on small changes and to
>>> -        // ease finding methods in the generated code
>>> -        speciesTypes = new TreeSet<>(speciesTypes);
>>> -        invokerTypes = new TreeSet<>(invokerTypes);
>>> -        callSiteTypes = new TreeSet<>(callSiteTypes);
>>> -
>>> -        TreeMap<String, Set<String>> newDMHMethods = new TreeMap<>();
>>> -        for (Map.Entry<String, Set<String>> entry : dmhMethods.entrySet()) {
>>> -            newDMHMethods.put(entry.getKey(), new TreeSet<>(entry.getValue()));
>>> -        }
>>> -        dmhMethods = newDMHMethods;
>>>           lines.map(line -> line.split(" "))
>>>                .forEach(parts -> {
>>>                   switch (parts[0]) {
>>> @@ -245,19 +243,18 @@
>>>                           if (parts.length == 3 && parts[1].startsWith("java.lang.invoke.BoundMethodHandle$Species_")) {
>>>                               String species = parts[1].substring("java.lang.invoke.BoundMethodHandle$Species_".length());
>>>                               if (!"L".equals(species)) {
>>> -                                speciesTypes.add(expandSignature(species));
>>> +                                addSpeciesType(species);
>>>                               }
>>>                           }
>>>                           break;
>>>                       case "[LF_RESOLVE]":
>>>                           String methodType = parts[3];
>>> -                        validateMethodType(methodType);
>>>                           if (parts[1].equals(INVOKERS_HOLDER_NAME)) {
>>>                               if ("linkToTargetMethod".equals(parts[2]) ||
>>>                                       "linkToCallSite".equals(parts[2])) {
>>> -                                callSiteTypes.add(methodType);
>>> +                                addCallSisterType(methodType);
>>>                               } else {
>>> -                                invokerTypes.add(methodType);
>>> +                                addInvokerType(methodType);
>>>                               }
>>>                           } else if (parts[1].contains("DirectMethodHandle")) {
>>>                               String dmh = parts[2];
>>> @@ -291,12 +288,6 @@
>>>           }
>>>       }
>>>   
>>> -    private void validateMethodTypes(Set<String> dmhMethodTypes) {
>>> -        for (String type : dmhMethodTypes) {
>>> -            validateMethodType(type);
>>> -        }
>>> -    }
>>>
>>>       private void validateMethodType(String type) {
>>>           String[] typeParts = type.split("_");
>>>           // check return type (second part)
>>> @@ -338,12 +329,6 @@
>>>   
>>>           // Generate LambdaForm Holder classes
>>>           generateHolderClasses(out);
>>> -
>>> -        // Let it go
>>> -        speciesTypes = null;
>>> -        invokerTypes = null;
>>> -        dmhMethods = null;
>>> -
>>>           return out.build();
>>>       }
>>>
>

From david.holmes at oracle.com  Wed Oct 30 01:50:25 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Oct 2019 11:50:25 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <ee75045b-a621-2fb5-a16a-aa8027da545b@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <ee75045b-a621-2fb5-a16a-aa8027da545b@oracle.com>
Message-ID: <2eccd9e9-7a6a-a16b-690f-424ef12cd1c6@oracle.com>

On 30/10/2019 4:05 am, serguei.spitsyn at oracle.com wrote:
> Hi David,
> 
> The fix looks good to me.

Thanks Serguei!

David

> I did not pay much attention to the Graal related changes though.
> The test coverage for Serviceability is complete.
> Running java/lang/instrument tests is not necessary.
> 
> Thanks,
> Serguei
> 
> 
> On 10/29/19 00:42, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>
>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but 
>> only in small pieces each. There is also a small touch to 
>> serviceability code.
>>
>> This change is "simply" moving the "interrupted" field out of the 
>> osThread and into the java.lang.Thread so that it can be set 
>> independently of whether the thread is alive (and to make things 
>> easier for loom in the near future). It is very straightforward:
>>
>> - old scheme
>> ? - interrupted field is in osThread
>> ? - VM can read/write directly
>> ? - Java code calls into VM to read/write
>>
>> - new scheme
>> ? - interrupted field is in java.lang.Thread
>> ? - VM has to use javaCalls to read/write "directly"
>> ? - Java code can read/write directly
>>
>> No changes to any of the semantics regarding the actual interrupt 
>> mechanism. Special thanks to Patricio for tracking down a bug I had 
>> introduced in that regard!
>>
>> Special Note (Hi Roger!): on windows we still need to set/clear the 
>> _interrupt_event used by the Process.waitFor logic. To facilitate 
>> clearing via Thread.interrupted() I had to introduce a native method 
>> that is a no-op except on Windows. This seemed the cheapest and least 
>> intrusive means to achieve this.
>>
>> Other changes revolve around the fact we used to have an intrinsic for 
>> Thread.isInterrupted and that is not needed any more. So we strip some 
>> code out of C1/C2.
>>
>> The changes in the JVMCI/Graal code are a bit more far reaching as 
>> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request 
>> so that they can comment on the JVMCI changes and whether I have gone 
>> too far or not far enough. There are a bunch of tests for interruption 
>> in JVMCI that could potentially be deleted if they are only intended 
>> to test the JVMCI handling of interrupt:
>>
>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java 
>>
>>
>> Testing:
>> ?- Tiers 1-3 on all Oracle platforms
>> ?- Focused testing on Linux x64:
>> ??? - Stress runs of JSR166TestCase
>> ??? - Anything that seems to use interrupt():
>> ????? - JDK
>> ??????? - java/lang/Thread
>> ??????? - java/util/concurrent
>> ??????? - jdk/internal/loader/InterruptedClassLoad.java
>> ??????? - javax/management
>> ??????? - java/nio/file/Files
>> ??????? - java/nio/channels
>> ??????? - java/net/Socket/Timeouts.java
>> ??????? - java/lang/Runtime/shutdown/
>> ??????? - java/lang/ProcessBuilder/Basic.java
>> ??????? - com/sun/jdi/
>> ????? - Hotspot
>> ??????? - vmTestbase/nsk/monitoring/
>> ??????? - vmTestbase/nsk/jdwp
>> ??????? - vmTestbase/nsk/jdb/
>> ??????? - vmTestbase/nsk/jdi/
>> ??????? - vmTestbase/nsk/jvmti/
>> ??????? - runtime/Thread
>> ??????? - serviceability/jvmti/
>> ??????? - serviceability/jdwp
>> ??????? - serviceability/sa
>>
>> Thanks,
>> David
>> -----
> 

From david.holmes at oracle.com  Wed Oct 30 01:52:03 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Oct 2019 11:52:03 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <422bc3b5-861f-0c86-0878-1ba392b342b1@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <422bc3b5-861f-0c86-0878-1ba392b342b1@oracle.com>
Message-ID: <b32c1a5d-475a-382b-f558-aade0f547f06@oracle.com>

Thanks for the review Dan!

Fixed the nit in thread.c

Thanks,
David

On 30/10/2019 6:51 am, Daniel D. Daugherty wrote:
> On 10/29/19 3:42 AM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
> 
> make/hotspot/symbols/symbols-unix
>  ??? No comments.
> 
> src/hotspot/os/windows/osThread_windows.cpp
>  ??? No comments.
> 
> src/hotspot/os/windows/osThread_windows.hpp
>  ??? No comments.
> 
> src/hotspot/share/aot/aotCodeHeap.cpp
>  ??? Skipped.
> 
> src/hotspot/share/classfile/javaClasses.cpp
>  ??? No comments.
> 
> src/hotspot/share/classfile/javaClasses.hpp
>  ??? No comments.
> 
> src/hotspot/share/classfile/vmSymbols.cpp
>  ??? No comments.
> 
> src/hotspot/share/classfile/vmSymbols.hpp
>  ??? No comments.
> 
> src/hotspot/share/include/jvm.h
>  ??? No comments.
> 
> src/hotspot/share/jvmci/jvmciRuntime.cpp
> src/hotspot/share/jvmci/jvmciRuntime.hpp
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp
>  ??? Skipped these three.
> 
> src/hotspot/share/oops/oop.hpp
>  ??? No comments.
> 
> src/hotspot/share/oops/oop.inline.hpp
>  ??? No comments.
> 
> src/hotspot/share/opto/c2compiler.cpp
>  ??? No comments.
> 
> src/hotspot/share/opto/library_call.cpp
>  ??? No comments.
> 
> src/hotspot/share/prims/jvm.cpp
>  ??? No comments.
> 
> src/hotspot/share/prims/jvmtiEnv.cpp
>  ??? No comments.
> 
> src/hotspot/share/prims/jvmtiEnvBase.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/osThread.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/osThread.hpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/thread.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/vmStructs.cpp
>  ??? No comments.
> 
> src/java.base/share/classes/java/lang/Thread.java
>  ??? No comments.
> 
> src/java.base/share/native/libjava/Thread.c
>  ??? L76: ? // Need to reset the interrupt event used by Process.waitFor
>  ??? L77: ? ResetEvent((HANDLE) JVM_GetThreadInterruptEvent());
>  ??????? nit - the indent in JDK .c files is four spaces.
> 
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/OSThread.java
>  ??? No comments.
> 
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java 
> 
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 
> 
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java 
> 
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java 
> 
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ThreadSubstitutions.java 
> 
>  ??? Skipped these 5 graal files.
> 
> Thumbs up! I only have one nit above and don't need to see
> another webrev if you decide to fix it.
> 
> Thanks for being so thorough on your testing.
> 
> Dan
> 
> 
>>
>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but 
>> only in small pieces each. There is also a small touch to 
>> serviceability code.
>>
>> This change is "simply" moving the "interrupted" field out of the 
>> osThread and into the java.lang.Thread so that it can be set 
>> independently of whether the thread is alive (and to make things 
>> easier for loom in the near future). It is very straightforward:
>>
>> - old scheme
>> ? - interrupted field is in osThread
>> ? - VM can read/write directly
>> ? - Java code calls into VM to read/write
>>
>> - new scheme
>> ? - interrupted field is in java.lang.Thread
>> ? - VM has to use javaCalls to read/write "directly"
>> ? - Java code can read/write directly
>>
>> No changes to any of the semantics regarding the actual interrupt 
>> mechanism. Special thanks to Patricio for tracking down a bug I had 
>> introduced in that regard!
>>
>> Special Note (Hi Roger!): on windows we still need to set/clear the 
>> _interrupt_event used by the Process.waitFor logic. To facilitate 
>> clearing via Thread.interrupted() I had to introduce a native method 
>> that is a no-op except on Windows. This seemed the cheapest and least 
>> intrusive means to achieve this.
>>
>> Other changes revolve around the fact we used to have an intrinsic for 
>> Thread.isInterrupted and that is not needed any more. So we strip some 
>> code out of C1/C2.
>>
>> The changes in the JVMCI/Graal code are a bit more far reaching as 
>> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request 
>> so that they can comment on the JVMCI changes and whether I have gone 
>> too far or not far enough. There are a bunch of tests for interruption 
>> in JVMCI that could potentially be deleted if they are only intended 
>> to test the JVMCI handling of interrupt:
>>
>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java 
>>
>>
>> Testing:
>> ?- Tiers 1-3 on all Oracle platforms
>> ?- Focused testing on Linux x64:
>> ??? - Stress runs of JSR166TestCase
>> ??? - Anything that seems to use interrupt():
>> ????? - JDK
>> ??????? - java/lang/Thread
>> ??????? - java/util/concurrent
>> ??????? - jdk/internal/loader/InterruptedClassLoad.java
>> ??????? - javax/management
>> ??????? - java/nio/file/Files
>> ??????? - java/nio/channels
>> ??????? - java/net/Socket/Timeouts.java
>> ??????? - java/lang/Runtime/shutdown/
>> ??????? - java/lang/ProcessBuilder/Basic.java
>> ??????? - com/sun/jdi/
>> ????? - Hotspot
>> ??????? - vmTestbase/nsk/monitoring/
>> ??????? - vmTestbase/nsk/jdwp
>> ??????? - vmTestbase/nsk/jdb/
>> ??????? - vmTestbase/nsk/jdi/
>> ??????? - vmTestbase/nsk/jvmti/
>> ??????? - runtime/Thread
>> ??????? - serviceability/jvmti/
>> ??????? - serviceability/jdwp
>> ??????? - serviceability/sa
>>
>> Thanks,
>> David
>> -----
> 

From david.holmes at oracle.com  Wed Oct 30 02:05:46 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Oct 2019 12:05:46 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <228101443.839885.1572385135051.JavaMail.zimbra@u-pem.fr>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <228101443.839885.1572385135051.JavaMail.zimbra@u-pem.fr>
Message-ID: <d20f6599-9382-4a96-8449-cd56cd8862f7@oracle.com>

Hi Remi,

On 30/10/2019 7:38 am, Remi Forax wrote:
> Hi David,
> in java.lang.Thread interrupt0 should be renamed to setInterruptEvent, because what it does now

There is only an "interrupt event" on Windows. What interrupt0 does is 
issue all the necessary unparks so that blocked threads will wake up and 
recheck if they were interrupted. So I don't think a rename is needed.

> and I don't really understand the comment in interrupted(), if a thread is interrupted by two other threads calling interrupt(), you will loose an interrupt anyway.

Suppose a Thread is checking interrupted() ahead of a blocking 
operation, it reads the interrupted field and sees that it is false. 
Then another thread interrupts it, setting the field to true and issuing 
the unparks. The interrupted() call continues and sets the interrupted 
field to false, and then returns false so the blocking operation 
proceeds. Because of the unparks the blocking call returns immediately. 
The thread then checks again to see if it was interrupted, but the field 
is false and so it re-parks (treating this as a spurious wakeup). But 
the thread actually was interrupted and should have thrown 
InterruptedException. The interrupt has been lost.

By only clearing the interrupted field if it was set we avoid this 
problem. This is the logic the VM code has been implementing for 20 
years, so the same logic is needed in the Java code. I added the 
additional comment to the VM code to make it clearer.

Hope that clarifies things.

Thanks,
David
-----

> R?mi
> 
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> ?: "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>, "hotspot compiler"
>> <hotspot-compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Doug Simon"
>> <doug.simon at oracle.com>, "TOM.RODRIGUEZ" <tom.rodriguez at oracle.com>, "serviceability-dev"
>> <serviceability-dev at openjdk.java.net>, "Roger Riggs" <Roger.Riggs at oracle.com>
>> Envoy?: Mardi 29 Octobre 2019 08:42:08
>> Objet: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination
> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>
>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but
>> only in small pieces each. There is also a small touch to serviceability
>> code.
>>
>> This change is "simply" moving the "interrupted" field out of the
>> osThread and into the java.lang.Thread so that it can be set
>> independently of whether the thread is alive (and to make things easier
>> for loom in the near future). It is very straightforward:
>>
>> - old scheme
>>    - interrupted field is in osThread
>>    - VM can read/write directly
>>    - Java code calls into VM to read/write
>>
>> - new scheme
>>    - interrupted field is in java.lang.Thread
>>    - VM has to use javaCalls to read/write "directly"
>>    - Java code can read/write directly
>>
>> No changes to any of the semantics regarding the actual interrupt
>> mechanism. Special thanks to Patricio for tracking down a bug I had
>> introduced in that regard!
>>
>> Special Note (Hi Roger!): on windows we still need to set/clear the
>> _interrupt_event used by the Process.waitFor logic. To facilitate
>> clearing via Thread.interrupted() I had to introduce a native method
>> that is a no-op except on Windows. This seemed the cheapest and least
>> intrusive means to achieve this.
>>
>> Other changes revolve around the fact we used to have an intrinsic for
>> Thread.isInterrupted and that is not needed any more. So we strip some
>> code out of C1/C2.
>>
>> The changes in the JVMCI/Graal code are a bit more far reaching as
>> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request
>> so that they can comment on the JVMCI changes and whether I have gone
>> too far or not far enough. There are a bunch of tests for interruption
>> in JVMCI that could potentially be deleted if they are only intended to
>> test the JVMCI handling of interrupt:
>>
>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
>>
>> Testing:
>>   - Tiers 1-3 on all Oracle platforms
>>   - Focused testing on Linux x64:
>>      - Stress runs of JSR166TestCase
>>      - Anything that seems to use interrupt():
>>        - JDK
>>          - java/lang/Thread
>>          - java/util/concurrent
>>          - jdk/internal/loader/InterruptedClassLoad.java
>>          - javax/management
>>          - java/nio/file/Files
>>          - java/nio/channels
>>          - java/net/Socket/Timeouts.java
>>          - java/lang/Runtime/shutdown/
>>          - java/lang/ProcessBuilder/Basic.java
>>          - com/sun/jdi/
>>        - Hotspot
>>          - vmTestbase/nsk/monitoring/
>>          - vmTestbase/nsk/jdwp
>>          - vmTestbase/nsk/jdb/
>>          - vmTestbase/nsk/jdi/
>>          - vmTestbase/nsk/jvmti/
>>          - runtime/Thread
>>          - serviceability/jvmti/
>>          - serviceability/jdwp
>>          - serviceability/sa
>>
>> Thanks,
>> David
>> -----

From david.holmes at oracle.com  Wed Oct 30 04:28:01 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Oct 2019 14:28:01 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
 <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
Message-ID: <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>

Hi Doug,

Your proposed patch wasn't quite right. I made some adjustments but I'm 
still having issues with the test, 
HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see 
how to make the test execution conditional on the VM config.

Updated webrev:

http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/

Thanks,
David
-----


On 29/10/2019 7:14 pm, Doug Simon wrote:
> 
> 
>> On 29 Oct 2019, at 10:12, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Doug,
>>
>> Thanks for taking a look so quickly! :)
>>
>> On 29/10/2019 6:55 pm, Doug Simon wrote:
>>> Hi David,
>>> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing:
>>
>> So to be clear I should revert all the Graal file changes I made and just apply the patch below?
> 
> Yes please.
> 
> -Doug
> 
>>
>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>> index 0752a621215..baa2136a6ba 100644
>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase {
>>>       public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor");
>>>       public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE);
>>>       public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
>>> -    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
>>> +    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE);
>>>       public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int");
>>>       public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
>>>       public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*");
>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>> index 6b37fff083d..ffc8032d2b0 100644
>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
>>>               }
>>>           });
>>>   -        r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>>> +        if (config.osThreadOffset != Integer.MAX_VALUE) {
>>> +            r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>>> +        }
>>>       }
>>>         public static final String reflectionClass;
>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>> index 1d694fae2a4..8500c4de115 100644
>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
>>>         @Fold
>>>       public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) {
>>> +        assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE;
>>>           return config.osThreadOffset;
>>>       }
>>>   All the other JVMCI changes look good to me.
>>> -Doug
>>>> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>>>
>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code.
>>>>
>>>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward:
>>>>
>>>> - old scheme
>>>>   - interrupted field is in osThread
>>>>   - VM can read/write directly
>>>>   - Java code calls into VM to read/write
>>>>
>>>> - new scheme
>>>>   - interrupted field is in java.lang.Thread
>>>>   - VM has to use javaCalls to read/write "directly"
>>>>   - Java code can read/write directly
>>>>
>>>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard!
>>>>
>>>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this.
>>>>
>>>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2.
>>>>
>>>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt:
>>>>
>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
>>>>
>>>> Testing:
>>>> - Tiers 1-3 on all Oracle platforms
>>>> - Focused testing on Linux x64:
>>>>     - Stress runs of JSR166TestCase
>>>>     - Anything that seems to use interrupt():
>>>>       - JDK
>>>>         - java/lang/Thread
>>>>         - java/util/concurrent
>>>>         - jdk/internal/loader/InterruptedClassLoad.java
>>>>         - javax/management
>>>>         - java/nio/file/Files
>>>>         - java/nio/channels
>>>>         - java/net/Socket/Timeouts.java
>>>>         - java/lang/Runtime/shutdown/
>>>>         - java/lang/ProcessBuilder/Basic.java
>>>>         - com/sun/jdi/
>>>>       - Hotspot
>>>>         - vmTestbase/nsk/monitoring/
>>>>         - vmTestbase/nsk/jdwp
>>>>         - vmTestbase/nsk/jdb/
>>>>         - vmTestbase/nsk/jdi/
>>>>         - vmTestbase/nsk/jvmti/
>>>>         - runtime/Thread
>>>>         - serviceability/jvmti/
>>>>         - serviceability/jdwp
>>>>         - serviceability/sa
>>>>
>>>> Thanks,
>>>> David
>>>> -----
> 

From david.holmes at oracle.com  Wed Oct 30 04:29:17 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Oct 2019 14:29:17 +1000
Subject: RFR JDK-8232724: Remove indirection with calling
 JNU_NewStringPlatform
In-Reply-To: <1d78a797-86ba-6340-3ac0-db024ee416d6@oracle.com>
References: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
 <a8c2fccb-df7c-8e4b-d958-3b159ea821e4@oracle.com>
 <1d78a797-86ba-6340-3ac0-db024ee416d6@oracle.com>
Message-ID: <d455b790-01b1-74d9-a883-f6ba588dde18@oracle.com>

LGTM.

Thanks,
David

On 30/10/2019 1:04 am, Alexey Ivanov wrote:
> Hi David, Christoph,
> 
> Thank you for your reviews.
> 
> On 29/10/2019 07:49, David Holmes wrote:
>>> Shall I remove one of them? The one in jvm.h because it's unused?
>>
>> Yes please remove the unused one in jvm.h. 
> 
> The updated webrev:
> http://cr.openjdk.java.net/~aivanov/8232724/webrev.01/
> 
> -- 
> Regards,
> Alexey

From david.holmes at oracle.com  Wed Oct 30 04:38:51 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Oct 2019 14:38:51 +1000
Subject: 8205132: Remove Thread.countStackFrames()
In-Reply-To: <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
References: <dd5a042a-cd3c-9e88-efe4-81236de916ca@oracle.com>
 <5e106d59-c600-ee0c-f326-f4daa5300286@oracle.com>
Message-ID: <c54494ef-85e3-07ec-eac1-755e5179db79@oracle.com>

On 30/10/2019 2:26 am, Alan Bateman wrote:
> On 23/10/2019 08:25, Alan Bateman wrote:
>>
>> Thread::countStackFrames has been deprecated for 20+ years and has 
>> been marked for-removal since Java SE 9. I'd like to remove it for 
>> Java SE 14. It's was never a well-defined method and I've been unable 
>> to find anything that uses it. The StackWalker API is a much better 
>> solution for code that is interested in the number of stack frames.
> Joe Darcy has suggested degrading the method in advance of its removal. 
> We did the same with stop(Throwable) when we changed it to throw UOE in 
> Java SE 8 before finally removing it in 11. Here is the updated webrev 
> and CSR. The CSR will need to be re-reviewed. The method description is 
> brief and the same as what we did for stop(Throwable).
> 
> http://cr.openjdk.java.net/~alanb/8205132/webrev.02/

Looks good.

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

Reviewed.

> Also just to summarize the discussion/objection from Seth Lytle. I think 
> we've established that that it was a regression in JDK 10 that allowed 
> that example to work. The method has always been specified to fail when 
> the thread is not suspended.

Yes.

Thanks,
David

> -Alan
> 
> 
> 

From christoph.langer at sap.com  Wed Oct 30 09:05:10 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 30 Oct 2019 09:05:10 +0000
Subject: RFR JDK-8232724: Remove indirection with calling
 JNU_NewStringPlatform
In-Reply-To: <d455b790-01b1-74d9-a883-f6ba588dde18@oracle.com>
References: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
 <a8c2fccb-df7c-8e4b-d958-3b159ea821e4@oracle.com>
 <1d78a797-86ba-6340-3ac0-db024ee416d6@oracle.com>
 <d455b790-01b1-74d9-a883-f6ba588dde18@oracle.com>
Message-ID: <AM6PR02MB4801084C4473E644EC8239568A600@AM6PR02MB4801.eurprd02.prod.outlook.com>

+1

You'll have to update the copyright years in the jni_util files.

Cheers
Christoph

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 30. Oktober 2019 05:29
> To: Alexey Ivanov <alexey.ivanov at oracle.com>; core-libs <core-libs-
> dev at openjdk.java.net>; hotspot-runtime <hotspot-runtime-
> dev at openjdk.java.net>; Langer, Christoph <christoph.langer at sap.com>
> Cc: Claes Redestad <claes.redestad at oracle.com>
> Subject: Re: RFR JDK-8232724: Remove indirection with calling
> JNU_NewStringPlatform
> 
> LGTM.
> 
> Thanks,
> David
> 
> On 30/10/2019 1:04 am, Alexey Ivanov wrote:
> > Hi David, Christoph,
> >
> > Thank you for your reviews.
> >
> > On 29/10/2019 07:49, David Holmes wrote:
> >>> Shall I remove one of them? The one in jvm.h because it's unused?
> >>
> >> Yes please remove the unused one in jvm.h.
> >
> > The updated webrev:
> > http://cr.openjdk.java.net/~aivanov/8232724/webrev.01/
> >
> > --
> > Regards,
> > Alexey

From richard.d.evans at oracle.com  Wed Oct 30 10:49:00 2019
From: richard.d.evans at oracle.com (Richard Evans)
Date: Wed, 30 Oct 2019 10:49:00 +0000
Subject: 14-jpackage+1-64 rpm uninstall errors
Message-ID: <e6c0e828-74fb-b4a1-12e9-05a5a7563d63@oracle.com>

Using 14-jpackage+1-64 with file associations including a png icon, I 
see the RPM includes this in the removal script:

...
xdg-icon-resource uninstall application-x-edqlaunch

The problem is that the xdg-icon-resource command requires a --size 
argument:

xdg-icon-resource uninstall [--noupdate] [--theme theme] [--context 
context] [--mode mode] --size size icon-name

so an erase fails with an error like:

xdg-icon-resource: the icon size must be specified with --size
Try 'xdg-icon-resource --help' for more information.
error: %preun(edq-0.27-1.x86_64) scriptlet failed, exit status 1
error: edq-0.27-1.x86_64: erase failed

leaving the package partly uninstalled.? Earlier when I looked in 
/usr/share/icons/hicolor/ I see my icon under "0x0" so it looks like a 
size should be specified when the package is installed.

I don't see anything like this in the bugs list.

Thanks

Richard
-- 

Oracle <http://www.oracle.com>
Richard Evans | Product Architect
Phone: +441223228408 <tel:+441223228408> | Mobile: +447973839664 
<tel:+447973839664> | Video: richard.d.evans at oracle.com 
<sip:richard.d.evans at oracle.com>
Oracle Product Development
Park House Castle Park | Cambridge | CB3 0DU | United Kingdom

ORACLE Corporation UK Ltd is a company incorporated in England & Wales | 
Company Reg. No. 1782505 | Reg. office: Oracle Parkway, Thames Valley 
Park, Reading RG6 1RA
Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to 
developing practices and products that help protect the environment


From doug.simon at oracle.com  Wed Oct 30 12:06:37 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 30 Oct 2019 13:06:37 +0100
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
 <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
 <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
Message-ID: <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com>



> On 30 Oct 2019, at 05:28, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Doug,
> 
> Your proposed patch wasn't quite right. I made some adjustments but I'm still having issues with the test, HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see how to make the test execution conditional on the VM config.

Like this:

diff --git a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
index 96e7d979d36..3c928b86961 100644
--- a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
+++ b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
@@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite;
 import java.lang.invoke.MethodHandles;
 import java.lang.invoke.MethodType;

-import org.graalvm.compiler.nodes.IfNode;
-import org.junit.Test;
-
 import org.graalvm.compiler.api.directives.GraalDirectives;
 import org.graalvm.compiler.api.replacements.MethodSubstitution;
+import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig;
+import org.graalvm.compiler.hotspot.HotSpotBackend;
+import org.graalvm.compiler.nodes.IfNode;
 import org.graalvm.compiler.replacements.test.MethodSubstitutionTest;
+import org.junit.Test;

 /**
  * Tests HotSpot specific {@link MethodSubstitution}s.
@@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest extends MethodSubstitutionTest {

     @Test
     public void testThreadSubstitutions() {
+        GraalHotSpotVMConfig config = ((HotSpotBackend) getBackend()).getRuntime().getVMConfig();
         testGraph("currentThread");
-        assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class);
-        assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class);
+        if (config.osThreadOffset != Integer.MAX_VALUE) {
+            assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class);
+            assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class);
+        }

         Thread currentThread = Thread.currentThread();
         test("currentThread", currentThread);
-        test("threadIsInterrupted", currentThread);
+        if (config.osThreadOffset != Integer.MAX_VALUE) {
+            test("threadIsInterrupted", currentThread);
+        }
     }

     @SuppressWarnings("all")

> 
> Updated webrev:
> 
> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/
> 
> Thanks,
> David
> -----
> 
> 
> On 29/10/2019 7:14 pm, Doug Simon wrote:
>>> On 29 Oct 2019, at 10:12, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Doug,
>>> 
>>> Thanks for taking a look so quickly! :)
>>> 
>>> On 29/10/2019 6:55 pm, Doug Simon wrote:
>>>> Hi David,
>>>> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing:
>>> 
>>> So to be clear I should revert all the Graal file changes I made and just apply the patch below?
>> Yes please.
>> -Doug
>>> 
>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>> index 0752a621215..baa2136a6ba 100644
>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase {
>>>>      public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor");
>>>>      public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE);
>>>>      public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
>>>> -    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
>>>> +    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE);
>>>>      public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int");
>>>>      public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
>>>>      public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*");
>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>> index 6b37fff083d..ffc8032d2b0 100644
>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
>>>>              }
>>>>          });
>>>>  -        r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>>>> +        if (config.osThreadOffset != Integer.MAX_VALUE) {
>>>> +            r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>>>> +        }
>>>>      }
>>>>        public static final String reflectionClass;
>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>> index 1d694fae2a4..8500c4de115 100644
>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
>>>>        @Fold
>>>>      public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) {
>>>> +        assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE;
>>>>          return config.osThreadOffset;
>>>>      }
>>>>  All the other JVMCI changes look good to me.
>>>> -Doug
>>>>> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> wrote:
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>>>> 
>>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code.
>>>>> 
>>>>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward:
>>>>> 
>>>>> - old scheme
>>>>>  - interrupted field is in osThread
>>>>>  - VM can read/write directly
>>>>>  - Java code calls into VM to read/write
>>>>> 
>>>>> - new scheme
>>>>>  - interrupted field is in java.lang.Thread
>>>>>  - VM has to use javaCalls to read/write "directly"
>>>>>  - Java code can read/write directly
>>>>> 
>>>>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard!
>>>>> 
>>>>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this.
>>>>> 
>>>>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2.
>>>>> 
>>>>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt:
>>>>> 
>>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
>>>>> 
>>>>> Testing:
>>>>> - Tiers 1-3 on all Oracle platforms
>>>>> - Focused testing on Linux x64:
>>>>>    - Stress runs of JSR166TestCase
>>>>>    - Anything that seems to use interrupt():
>>>>>      - JDK
>>>>>        - java/lang/Thread
>>>>>        - java/util/concurrent
>>>>>        - jdk/internal/loader/InterruptedClassLoad.java
>>>>>        - javax/management
>>>>>        - java/nio/file/Files
>>>>>        - java/nio/channels
>>>>>        - java/net/Socket/Timeouts.java
>>>>>        - java/lang/Runtime/shutdown/
>>>>>        - java/lang/ProcessBuilder/Basic.java
>>>>>        - com/sun/jdi/
>>>>>      - Hotspot
>>>>>        - vmTestbase/nsk/monitoring/
>>>>>        - vmTestbase/nsk/jdwp
>>>>>        - vmTestbase/nsk/jdb/
>>>>>        - vmTestbase/nsk/jdi/
>>>>>        - vmTestbase/nsk/jvmti/
>>>>>        - runtime/Thread
>>>>>        - serviceability/jvmti/
>>>>>        - serviceability/jdwp
>>>>>        - serviceability/sa
>>>>> 
>>>>> Thanks,
>>>>> David
>>>>> -----


From alexey.ivanov at oracle.com  Wed Oct 30 13:21:58 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 30 Oct 2019 13:21:58 +0000
Subject: RFR JDK-8232724: Remove indirection with calling
 JNU_NewStringPlatform
In-Reply-To: <AM6PR02MB4801084C4473E644EC8239568A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
 <a8c2fccb-df7c-8e4b-d958-3b159ea821e4@oracle.com>
 <1d78a797-86ba-6340-3ac0-db024ee416d6@oracle.com>
 <d455b790-01b1-74d9-a883-f6ba588dde18@oracle.com>
 <AM6PR02MB4801084C4473E644EC8239568A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <031ce180-cddb-b5e2-63e4-df7018a94905@oracle.com>

Thank you, David and Christoph, for your reviews.

I'll update the copyright year before the push if you don't mind.

Regards,
Alexey

On 30/10/2019 09:05, Langer, Christoph wrote:
> +1
>
> You'll have to update the copyright years in the jni_util files.
>
> Cheers
> Christoph
>
>> -----Original Message-----
>> From: David Holmes <david.holmes at oracle.com>
>> Sent: Mittwoch, 30. Oktober 2019 05:29
>> To: Alexey Ivanov <alexey.ivanov at oracle.com>; core-libs <core-libs-
>> dev at openjdk.java.net>; hotspot-runtime <hotspot-runtime-
>> dev at openjdk.java.net>; Langer, Christoph <christoph.langer at sap.com>
>> Cc: Claes Redestad <claes.redestad at oracle.com>
>> Subject: Re: RFR JDK-8232724: Remove indirection with calling
>> JNU_NewStringPlatform
>>
>> LGTM.
>>
>> Thanks,
>> David
>>
>> On 30/10/2019 1:04 am, Alexey Ivanov wrote:
>>> Hi David, Christoph,
>>>
>>> Thank you for your reviews.
>>>
>>> On 29/10/2019 07:49, David Holmes wrote:
>>>>> Shall I remove one of them? The one in jvm.h because it's unused?
>>>> Yes please remove the unused one in jvm.h.
>>> The updated webrev:
>>> http://cr.openjdk.java.net/~aivanov/8232724/webrev.01/
>>>
>>> --
>>> Regards,
>>> Alexey


From christoph.langer at sap.com  Wed Oct 30 14:15:15 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 30 Oct 2019 14:15:15 +0000
Subject: RFR JDK-8232724: Remove indirection with calling
 JNU_NewStringPlatform
In-Reply-To: <031ce180-cddb-b5e2-63e4-df7018a94905@oracle.com>
References: <9929ca83-29bd-308c-2320-59acd242f0d6@oracle.com>
 <a8c2fccb-df7c-8e4b-d958-3b159ea821e4@oracle.com>
 <1d78a797-86ba-6340-3ac0-db024ee416d6@oracle.com>
 <d455b790-01b1-74d9-a883-f6ba588dde18@oracle.com>
 <AM6PR02MB4801084C4473E644EC8239568A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <031ce180-cddb-b5e2-63e4-df7018a94905@oracle.com>
Message-ID: <AM6PR02MB4801F7A262FFEAB55E0C422A8A600@AM6PR02MB4801.eurprd02.prod.outlook.com>

Sure. Thanks, Alexey.

> -----Original Message-----
> From: Alexey Ivanov <alexey.ivanov at oracle.com>
> Sent: Mittwoch, 30. Oktober 2019 14:22
> To: Langer, Christoph <christoph.langer at sap.com>; David Holmes
> <david.holmes at oracle.com>; core-libs <core-libs-dev at openjdk.java.net>;
> hotspot-runtime <hotspot-runtime-dev at openjdk.java.net>
> Cc: Claes Redestad <claes.redestad at oracle.com>
> Subject: Re: RFR JDK-8232724: Remove indirection with calling
> JNU_NewStringPlatform
> 
> Thank you, David and Christoph, for your reviews.
> 
> I'll update the copyright year before the push if you don't mind.
> 
> Regards,
> Alexey
> 
> On 30/10/2019 09:05, Langer, Christoph wrote:
> > +1
> >
> > You'll have to update the copyright years in the jni_util files.
> >
> > Cheers
> > Christoph
> >
> >> -----Original Message-----
> >> From: David Holmes <david.holmes at oracle.com>
> >> Sent: Mittwoch, 30. Oktober 2019 05:29
> >> To: Alexey Ivanov <alexey.ivanov at oracle.com>; core-libs <core-libs-
> >> dev at openjdk.java.net>; hotspot-runtime <hotspot-runtime-
> >> dev at openjdk.java.net>; Langer, Christoph <christoph.langer at sap.com>
> >> Cc: Claes Redestad <claes.redestad at oracle.com>
> >> Subject: Re: RFR JDK-8232724: Remove indirection with calling
> >> JNU_NewStringPlatform
> >>
> >> LGTM.
> >>
> >> Thanks,
> >> David
> >>
> >> On 30/10/2019 1:04 am, Alexey Ivanov wrote:
> >>> Hi David, Christoph,
> >>>
> >>> Thank you for your reviews.
> >>>
> >>> On 29/10/2019 07:49, David Holmes wrote:
> >>>>> Shall I remove one of them? The one in jvm.h because it's unused?
> >>>> Yes please remove the unused one in jvm.h.
> >>> The updated webrev:
> >>> http://cr.openjdk.java.net/~aivanov/8232724/webrev.01/
> >>>
> >>> --
> >>> Regards,
> >>> Alexey


From alexey.semenyuk at oracle.com  Wed Oct 30 14:43:15 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 30 Oct 2019 10:43:15 -0400
Subject: 14-jpackage+1-64 rpm uninstall errors
In-Reply-To: <e6c0e828-74fb-b4a1-12e9-05a5a7563d63@oracle.com>
References: <e6c0e828-74fb-b4a1-12e9-05a5a7563d63@oracle.com>
Message-ID: <f66f4785-ffd5-e54b-e925-df326cb30d09@oracle.com>

Hi Richard,

I confirm these issues are reproducible on OL7. Filed 
https://bugs.openjdk.java.net/browse/JDK-8233218.

- Alexey

On 10/30/2019 6:49 AM, Richard Evans wrote:
> Using 14-jpackage+1-64 with file associations including a png icon, I 
> see the RPM includes this in the removal script:
>
> ...
> xdg-icon-resource uninstall application-x-edqlaunch
>
> The problem is that the xdg-icon-resource command requires a --size 
> argument:
>
> xdg-icon-resource uninstall [--noupdate] [--theme theme] [--context 
> context] [--mode mode] --size size icon-name
>
> so an erase fails with an error like:
>
> xdg-icon-resource: the icon size must be specified with --size
> Try 'xdg-icon-resource --help' for more information.
> error: %preun(edq-0.27-1.x86_64) scriptlet failed, exit status 1
> error: edq-0.27-1.x86_64: erase failed
>
> leaving the package partly uninstalled.? Earlier when I looked in 
> /usr/share/icons/hicolor/ I see my icon under "0x0" so it looks like a 
> size should be specified when the package is installed.
>
> I don't see anything like this in the bugs list.
>
> Thanks
>
> Richard


From brian.burkhalter at oracle.com  Wed Oct 30 15:20:06 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 30 Oct 2019 08:20:06 -0700
Subject: Fwd: 8232271: java.io.File.get*Space() should be aligned to updated
 FileStore analog methods
References: <C15EDD06-9771-4E46-8C5A-A58FC37D2F7E@oracle.com>
Message-ID: <FBDE44D9-1A18-4085-B819-E203EAF4A89F@oracle.com>

Ping !

> Begin forwarded message:
> 
> From: Brian Burkhalter <brian.burkhalter at oracle.com>
> Subject: 8232271: java.io.File.get*Space() should be aligned to updated FileStore analog methods
> Date: October 17, 2019 at 10:35:46 AM PDT
> To: Core-Libs-Dev <core-libs-dev at openjdk.java.net>
> 
> For issue [1], please review the patch [2]. This change aligns the specifications of the File.get*Space() methods with their equivalents in java.nio.file.FileStore. This issue is related to [3] which is discussed in this thread [4].
> 
> Naturally a CSR would eventually be required.
> 
> Thanks,
> 
> Brian
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8232271
> [2] http://cr.openjdk.java.net/~bpb/8232271/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8162520
> [4] http://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006644.html


From Alan.Bateman at oracle.com  Wed Oct 30 15:33:31 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Oct 2019 15:33:31 +0000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
Message-ID: <56094f66-ca3f-8209-0559-62a9412619c2@oracle.com>

On 29/10/2019 07:42, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>
The implNote has "In the JDK Reference Implementation". I think you can 
replace that with "In this implementation" so that it is consistent with 
the other impl notes that we've added in recent releases.

In any case, I went through the Thread changes and the call into the VM 
to clear the event on Windows. Looks okay to me (we'll have re-work to 
do in Loom of course but that was expected).

-Alan



From naoto.sato at oracle.com  Wed Oct 30 16:25:21 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 30 Oct 2019 09:25:21 -0700
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion entries
 on MS950 charset
In-Reply-To: <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
 <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
 <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>
 <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com>
Message-ID: <928774f8-9d20-bf75-fbc3-36c8a37b273c@oracle.com>

Takiguchi-san,

Personally I am reluctant to make this change. If we were to introduce 
this, it will be a different encoding from the existing MS950, so either 
1) we need a new encoding, or 2) make some switch between the encoding, 
possibly a system property. But neither seems worth doing, as :-

1) JDK's conversion is not a bug per se.
2) Seems that Unicode.org's "best fit" was introduced around 2006? (From 
the date on the unicode.org 
(https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt), 
so JDK's mapping predates it.
3) Those code points are not a common ones (BOX DRAWINGS), and no 
customer had a complaint about it.

Please let me know if there are some rationale for fixing it.

BTW, as to the CSR, I don't see it was created.

Naoto


On 10/29/19 11:35 AM, Ichiroh Takiguchi wrote:
> Thanks, Sato-san.
> 
> There is no special meaning to the word "until now".
> I rewrote charset related testcases, then I found this issue.
> 
> I read "Frequently Asked Questions about the CSR" [1],
> I tried "Create CSR" operation, but I could not determine it worked or 
> not...
> (Select "Create CSR" from "More" menu)
> It worked ?
> 
> [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-10-29 03:03, naoto.sato at oracle.com wrote:
>> Hi Takiguchi-san,
>>
>> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> I have no idea about compatibility impact.
>>>
>>> But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
>>> These are BOX DRAWINGS characters.
>>>
>>> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
>>> HORIZONTAL;;;;
>>> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT 
>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND RIGHT DOUBLE;;;;
>>> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
>>> VERTICAL SINGLE AND LEFT DOUBLE;;;;
>>> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
>>>
>>> I don't think it was used as valuable data until now.
>>> I think it's necessary to evaluate compatibility.
>>
>> What do you mean by "until now"? Are there customers claiming that it
>> should be corrected? Since the current JDK's mapping is not incorrect
>> per se (not just "best match"), I would like to know why this needs to
>> be fixed now.
>>
>> Naoto
>>
>>>
>>> To Sato-san,
>>> if you have any question and suggestion, please let me know.
>>>
>>> To other reviewers,
>>> please let me know if you have any question and concern.
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>>
>>> On 2019-10-19 16:36, Alan Bateman wrote:
>>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>>>> Hello.
>>>>>
>>>>> Could you review the fix ?
>>>>>
>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>>>
>>>>> I have a concern about 1-way trip conversion entries (4 entries) on 
>>>>> MS950 charset.
>>>>> The detail information is in JDK-8232161 [1]
>>>>>
>>>> Do you know any sense on the compatibility impact of changing this? I
>>>> think Naoto has the same question and we aren't sure if this one with
>>>> need a compatibility property. I think it will need a CSR.
>>>>
>>>> -Alan

From OGATAK at jp.ibm.com  Wed Oct 30 16:46:44 2019
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Thu, 31 Oct 2019 01:46:44 +0900
Subject: RFR: JDK-8229871: Improve performance of Method.copy() and
 leafCopy()
In-Reply-To: <caf652eb-ed8d-ca93-b4a6-add1e6d46d56@gmail.com>
References: <OF81612CC4.14F5ECFD-ON4925845B.00354906-4925845B.00361E60@notes.na.collabserv.com>
 <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com>
 <OF4B72AC47.286D7A8E-ON4925845D.003B9DB0-4925845D.003CAC03@LocalDomain>
 <OFD652D0B3.AD344B0A-ON49258463.0023C214-49258463.0024C5EA@LocalDomain>
 <OF6F3EA274.2EC3CCDA-ON4925848D.0035C4BE-4925848D.00390E10@notes.na.collabserv.com>
 <14b28640-cd16-c672-c4bb-754116e882da@gmail.com>
 <OF700BE5C9.50229F68-ON49258490.0037CB9A-49258490.00388773@notes.na.collabserv.com>
 <caf652eb-ed8d-ca93-b4a6-add1e6d46d56@gmail.com>
Message-ID: <OFD75BA542.AFF33B86-ON492584A3.005AF9C5-492584A3.005C2C77@notes.na.collabserv.com>

Hi Peter,

Thank you very much for your updated fix and sorry to be late to reply.

I found that the performance data I posted earlier was wrong because I 
fetched the latest code before building the JVM with your fix, while I 
still used older JVM as the base version.  The new build picked up 
JDK-8230020 [1], which reverts JDK-8225670 [2] that degraded performance 
of SPECjbb2015.  Unfortunately, the base version only included [2]...

Your new version [3] apparently looks better.  I'll update my base JVM and 
measure the performance of [3].


Regards,
Ogata

[1] https://bugs.openjdk.java.net/browse/JDK-8230020
[2] https://bugs.openjdk.java.net/browse/JDK-8225670
[3] 
http://cr.openjdk.java.net/~plevart/jdk-dev/8229871_Method.methodAccessor/webrev.01/


Peter Levart <peter.levart at gmail.com> wrote on 2019/10/24 06:09:54:

> From: Peter Levart <peter.levart at gmail.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> Cc: core-libs-dev at openjdk.java.net
> Date: 2019/10/24 06:10
> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of 
> Method.copy() and leafCopy()
> 
> Hi Ogata,
> 
> I finally managed to find some time to experiment with this. To measure 
> invocation performance I created the following JMH benchmark [1]. It 
> measures the invocation speed of instance and static methods using 
either:
> - direct invocation (bytecodes)
> - invocation via constant Method instance
> - invocation via variable Method instance
> 
> Here are the results using unmodified JDK 14 build (baseline):
> 
> Benchmark                                         Mode  Cnt Score   
> Error  Units
> ReflectionSpeedBenchmark.instanceDirect           avgt   10   2.272 ? 
> 0.002  ns/op
> ReflectionSpeedBenchmark.instanceReflectiveConst  avgt   10  16.609 ? 
> 0.162  ns/op
> ReflectionSpeedBenchmark.instanceReflectiveVar    avgt   10  16.715 ? 
> 0.163  ns/op
> ReflectionSpeedBenchmark.staticDirect             avgt   10   2.275 ? 
> 0.012  ns/op
> ReflectionSpeedBenchmark.staticReflectiveConst    avgt   10  16.351 ? 
> 0.330  ns/op
> ReflectionSpeedBenchmark.staticReflectiveVar      avgt   10  16.259 ? 
> 0.196  ns/op
> 
> Your webrev.04 [2] has a slight (~ 6%) improvement for constant Method 
> instance (i.e. assigned to static final field):
> 
> Benchmark                                         Mode  Cnt Score   
> Error  Units
> ReflectionSpeedBenchmark.instanceDirect           avgt   10   2.273 ? 
> 0.003  ns/op
> ReflectionSpeedBenchmark.instanceReflectiveConst  avgt   10  15.628 ? 
> 0.115  ns/op
> ReflectionSpeedBenchmark.instanceReflectiveVar    avgt   10  16.706 ? 
> 0.144  ns/op
> ReflectionSpeedBenchmark.staticDirect             avgt   10   2.277 ? 
> 0.008  ns/op
> ReflectionSpeedBenchmark.staticReflectiveConst    avgt   10  15.285 ? 
> 0.109  ns/op
> ReflectionSpeedBenchmark.staticReflectiveVar      avgt   10  16.600 ? 
> 0.222  ns/op
> 
> Now I have prepared another variant [3] that replaces 
> DelegatingMethodAccessorImpl with SlowFastMethodAccessorImpl and 
> produces the following result:
> 
> Benchmark                                         Mode  Cnt Score   
> Error  Units
> ReflectionSpeedBenchmark.instanceDirect           avgt   10   2.371 ? 
> 0.027  ns/op
> ReflectionSpeedBenchmark.instanceReflectiveConst  avgt   10   7.161 ? 
> 0.066  ns/op
> ReflectionSpeedBenchmark.instanceReflectiveVar    avgt   10  16.501 ? 
> 0.154  ns/op
> ReflectionSpeedBenchmark.staticDirect             avgt   10   2.373 ? 
> 0.017  ns/op
> ReflectionSpeedBenchmark.staticReflectiveConst    avgt   10   6.971 ? 
> 0.103  ns/op
> ReflectionSpeedBenchmark.staticReflectiveVar      avgt   10  15.893 ? 
> 0.110  ns/op
> 
> This is more than twice as fast as the baseline for constant Method 
> instances while not degrading performance for variable Method instances.
> 
> 
> [1] 
http://cr.openjdk.java.net/~plevart/jdk-dev/8229871_Method.methodAccessor/ReflectionSpeedBenchmark.java

> [2] http://cr.openjdk.java.net/~ogatak/8229871/webrev.04/
> [3] 
http://cr.openjdk.java.net/~plevart/jdk-dev/8229871_Method.methodAccessor/webrev.01/ 

> 
> 
> Could you spin this one [3] on your SPECjbb2015 benchmark to see if it 
> still performs favorably?
> 
> 
> Regards, Peter
> 
> On 10/11/19 12:17 PM, Kazunori Ogata wrote:
> > Hi Peter,
> >
> > Thank you for the comment and suggestion of the fix.
> >
> > I tried to pick up your change w.r.t. methodAccessor:
> > https://urldefense.proofpoint.com/v2/url?
> u=https-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev.
> 04_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=-xRlUE3M_VEQ_pLDsVNMsIneJ7tKig8ElUy8vmAQoUM&e= 
> >
> >
> > Regarding micro benchmark, my original motivation of this change is to
> > improve performance of Class.getMethods(), which calls Method.copy() 
for
> > each declared method to create a copy of Method[].
> >
> > I measured my simple microbench:
> > https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__cr.openjdk.java.net_-7Eogatak_8229871_GetMethodsBench.java&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=Phaibyh6EWjUKos14T7aQfBzSGcH4stxqnhQFkEZsp4&e= 
> >
> > Base code: Elapsed time = 4808 ms
> > webrev.01: Elapsed time = 4536 ms  (+   6%)
> > webrev.02: Elapsed time = 2331 ms  (+106%)
> > webrev.04: Elapsed time = 3746 ms  (+ 28%)
> >
> > I'll measure larger benchmark and try to think if we can reduce the
> > overhead of memory barrier.
> >
> >
> > Regards,
> > Ogata
> >
> >
> > Peter Levart <peter.levart at gmail.com> wrote on 2019/10/09 16:44:13:
> >
> >> From: Peter Levart <peter.levart at gmail.com>
> >> To: Kazunori Ogata <OGATAK at jp.ibm.com>, 
core-libs-dev at openjdk.java.net
> >> Date: 2019/10/09 16:44
> >> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of
> >> Method.copy() and leafCopy()
> >>
> >> Hi Ogata,
> >>
> >> May I just add that volatile field ensured that MethodAccessor object
> > was
> >> correctly published. DelegatingMethodAccessortImpl is not safe to be
> >> published via data race because it contains plain `delegate` field
> >> initialized in the constructor. In addition, the object that is first
> >> assigned to that field is NativeMethodAccessorImpl which has plain
> >> `parent` field. You can get NPE when invoking the Method.invoke from
> >> multuiple threads if Method.methodAccessor is not volatile.
> >>
> >> In addition, It would be nice to have two microbenchmarks exercising:
> >> a) Method copy performance
> >> b) Method invocation performance
> >>
> >> Regards, Peter
> >>
> >> P.S. When exploring the possibility of an alternative MethodAccessor
> >> implementation (using MethodHandle(s)):
> >>
> >>
> > https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk-2Ddev_6824466-5FMHReflectionAccessors_&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=LKR_2z3fvXB0IYUryijzgd-jH6wG3Mr2UmiOMKviFGU&e= 
> >> webrev.00.2/
> >>
> >> ...I found out that it was possible to re-arrange the play between
> >> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and generated
> >> MethodAccessor in such a way that the DelegatingMethodAccessortImpl
> >> becomes safe to be published via data race. This allowed for
> >> Method.methodAccessor field to become plain field. In addition this
> > field
> >> can be made @Stable which further optimizes access to MethodAccessor
> >> instance when Method instance can be constant-folded, which showed in
> >> special microbenchmarks.
> >>
> >> So perhaps you could try to use above implementation (just changes to
> >> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and part of
> >> Reflection factory but without MH* stuff) and measure it against 
current
> >> and your implementation (which as shown above has a data-race flaw).
> >> On 10/8/19 12:23 PM, Kazunori Ogata wrote:
> >> Hi all,
> >>
> >> I posted two changes and got reply that performance evaluation is
> > needed.
> >> I found that making Method.methodAccessor non-volatile (webrev.02) is
> >> better than avoid copying methodAccessor value when it is null
> >> (webrev.01), as shown below.
> >>
> >> So I'd like to ask review of the former change.  I updated weberv 
using
> >> the latest code base (though there was no difference from webrev.02):
> >>
> >> Webrev: https://urldefense.proofpoint.com/v2/url?
> u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev.
> 03_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=xm_iw74CmqAabV2cctZfI75t28_DCXP9VFVjHcnQXp4&e= 
> >>
> >> Bug: https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8229871&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=bzRkFq845mYFriH7TirkzA4JzG0m47x09kebpHfMgTw&e= 
> >>
> >>
> >> For this performance evaluation, I calculated 75 percentile of 9 runs 
of
> >> SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers. 
I
> >> bound a JVM to a NUMA node and set the number of GC threads to the 
same
> > as
> >> the number of physical cores.  These tuning reduced run-to-run
> > fluctuation
> >> on POWER (as usual...).
> >>
> >> SPECjbb2015:
> >>    webrev.02:  critical jOPS +1.6%, max jOPS +0.2%
> >>    webrev.01:  critical jOPS +0.4%, max jOPS +0.2%
> >>
> >>
> >> For DaCapo, some benchmark still improved performance and some 
degraded,
> >> but the geometric mean of all benchmarks were small:
> >>    weberv.02: +0.3%
> >>    weberv.01: +0.2%
> >>
> >> The difference of improvement/degradation between the two changes in
> > each
> >> benchmark were less than 0.8%.
> >>
> >> The range of improvement/degradation in each benchmark were:
> >>    webrev.02: between +2.4% and -1.0%
> >>    webrev.01: between +1.6% and -1.8%
> >>
> >>
> >> So I think webrev.02 (i.e., making methodAccessor non-volatile) is a
> > good
> >> change, since it improved SPECjbb critical jOPS by 1.6%.
> >>
> >>
> >> Regards,
> >> Ogata
> >>
> >>
> >> Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39:
> >>
> >> From: Kazunori Ogata/Japan/IBM
> >> To: Mandy Chung <mandy.chung at oracle.com>
> >> Cc: core-libs-dev at openjdk.java.net
> >> Date: 2019/08/27 15:41
> >> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() 
and
> >> leafCopy()
> >> Hi Mandy,
> >>
> >> Let me post interim results of the performance evaluation, though I'm
> >> still measuring benchmarks and analyzing them.
> >>
> >> For SPECjbb2015, skipping storing null (webrev.01) was faster than
> >> making
> >> methodAccessor non-volatile (webrev.02).  The improvements of each of
> >> the
> >> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%,
> >> respectively.  This is only an average of six runs.
> >>
> >> For DaCapo, the results were mixed.  In some benchmark, both of the
> >> changes degraded performance.  In some others, webrev.01 was better, 
but
> >
> >> weberv.02 was better in some others.
> >>
> >> I'll continue evaluation, but it is helpful if you could give me some
> >> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015.
> >>
> >> Regards,
> >> Ogata
> >>
> >> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41:
> >>
> >> From: Kazunori Ogata/Japan/IBM
> >> To: Mandy Chung <mandy.chung at oracle.com>
> >> Cc: core-libs-dev at openjdk.java.net
> >> Date: 2019/08/21 20:02
> >> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy()
> >> and leafCopy()
> >> Hi Mandy,
> >>
> >> Thank you for reviewing the webrev.  I updated it to add a space 
after
> >> "if" and also put four spaces for indentation (it was three).
> >>
> >> https://urldefense.proofpoint.com/v2/url?
> u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev.
> 01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=qLT9k5xsheWZfU7ocimSbEMANQDnelEUqqiR5X-Zio4&e= 
> >>
> >> Thank you so much for checking the history of fieldAccessor.  I was
> >> surprised that fieldAccessor was made non-volatile in JDK5, but
> >> methodAccessor was left as volatile for 15 years after that...
> >>
> >> I agree we need benchmark data.  My simple micro benchmark that
> >> repeats
> >> invoking Class.getMethods() improved performance by 70% when it made
> >> non-
> >> volatile (as shown in the following webrev).  I'll try to run larger
> >> benchmarks, such as SPECjbb2015, to see real impact.
> >>
> >> https://urldefense.proofpoint.com/v2/url?
> u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev.
> 02_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=aq50ONJW0fK7CBk1upVkJekAbRrDsZygPkWrjL_sM4I&e= 
> >>
> >> Regards,
> >> Ogata
> >>
> >> Mandy Chung <mandy.chung at oracle.com> wrote on 2019/08/21 01:21:42:
> >>
> >> From: Mandy Chung <mandy.chung at oracle.com>
> >> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> >> Cc: core-libs-dev at openjdk.java.net
> >> Date: 2019/08/21 01:21
> >> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of
> >> Method.copy() and leafCopy()
> >>
> >> Hi Ogata,
> >>
> >> The patch looks okay.  Nit: please add a space between if and (.
> >>
> >> About volatile methodAccessor field, I checked the history.  Both
> >> fieldAccessor and methodAccessor were started as volatile and the
> >> fieldAccessor declaration was updated due to JDK-5044412.   As you
> >> observe, I think the methodAccessor field could be made
> >> non-volatile.
> >> OTOH that might impact when it's inflated to spin bytecode for this
> >> method invocation.  I don't know how importance to keep its volatile
> >> vs
> >> non-volatile in practice without doing benchmarking/real application
> >> testing.
> >>
> >> Mandy
> >>
> >> On 8/19/19 2:51 AM, Kazunori Ogata wrote:
> >> Hi,
> >>
> >> May I have review for "JDK-8229871: Imporve performance of
> >> Method.copy()
> >> and leafCopy()"?
> >>
> >> Method.copy() and leafCopy() creates a copy of a Method object
> >> with
> >> sharing MethodAccessor object. Since the methodAccessor field is a
> >> volatile variable, copying this field needs memory fence to ensure
> >> the
> >> field is visible to all threads on the weak memory platforms such
> >> as POWER
> >> and ARM.
> >>
> >> When the methodAccessor of the root object is null (i.e., not
> >> initialized
> >> yet), we do not need to copy the null value because this field of
> >> the
> >> copied object has been initialized to null in the constructor. We
> >> can
> >> reduce overhead of the memory fence only when the root's
> >> methodAccessor is
> >> non-null. This change improved performance by 5.8% using a micro
> >> benchmark
> >> that repeatedly invokes Class.getMethods().
> >>
> >> Bug: https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8229871&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=bzRkFq845mYFriH7TirkzA4JzG0m47x09kebpHfMgTw&e= 
> >>
> >> Webrev: https://urldefense.proofpoint.com/v2/url?
> u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev.
> 00_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb-
> K9uCUrU_Yw&s=lGQy-Xy0ofp8d551jCUZdwmZ_OD4sXsMaoRKWzwer4o&e= 
> >>
> >>
> >> By the way, why Method.methodAccessor is volatile, while
> >> Field.fieldAccessor and Field.overrideFieldAccessor are not
> >> volatile?  I
> >> know the use of volatile reduces probability of creating
> >> duplicated method
> >> accessor, but the chance still exists.  I couldn't find the
> >> difference
> >> between Method and Field classes to make Method.methodAccessor
> >> volatile.
> >> If we can make it non-volatile, it is more preferable than a quick
> >> hack
> >> above.
> >>
> >>
> >> Regards,
> >> Ogata
> >>
> >>
> >>
> >
> 
> 



From alexey.semenyuk at oracle.com  Wed Oct 30 19:48:13 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 30 Oct 2019 15:48:13 -0400
Subject: RFR: JDK-8233218: rpm uninstall errors (xdg-icon-resource: the icon
 size must be specified with --size)
In-Reply-To: <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
References: <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
Message-ID: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8233218/webrev.00


From alexey.semenyuk at oracle.com  Wed Oct 30 20:42:20 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 30 Oct 2019 16:42:20 -0400
Subject: RFR: JDK-8233138: Error 2343 when using --win-dir-chooser
In-Reply-To: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
References: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
Message-ID: <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

Additionally removed code that adds component to msi package to remove 
files and directories not managed by the msi package in shortcuts folder 
(changes in WixSourcesBuilder.java).

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8233138/webrev.00


From alexey.semenyuk at oracle.com  Wed Oct 30 22:03:05 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 30 Oct 2019 18:03:05 -0400
Subject: RFR: JDK-8233143: RPM errors: rpmbuild: no spec files given for build
In-Reply-To: <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
References: <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
Message-ID: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8233143/webrev.00


From david.holmes at oracle.com  Wed Oct 30 23:29:15 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 31 Oct 2019 09:29:15 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <56094f66-ca3f-8209-0559-62a9412619c2@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <56094f66-ca3f-8209-0559-62a9412619c2@oracle.com>
Message-ID: <9404b5fb-f0a7-3b4e-80d9-ec0530be1d9a@oracle.com>

Hi Alan,

Thanks for taking a look at this.

On 31/10/2019 1:33 am, Alan Bateman wrote:
> On 29/10/2019 07:42, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>
> The implNote has "In the JDK Reference Implementation". I think you can 
> replace that with "In this implementation" so that it is consistent with 
> the other impl notes that we've added in recent releases.

Joe Darcy specifically requested that terminology in the CSR request as 
the new way of referring to "this implementation". There are 24 existing 
uses.

> In any case, I went through the Thread changes and the call into the VM 
> to clear the event on Windows. Looks okay to me (we'll have re-work to 
> do in Loom of course but that was expected).

Thanks again.

David

> -Alan
> 
> 

From alexander.matveev at oracle.com  Thu Oct 31 00:03:15 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 30 Oct 2019 17:03:15 -0700
Subject: RFR: JDK-8233218: rpm uninstall errors (xdg-icon-resource: the
 icon size must be specified with --size)
In-Reply-To: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
References: <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
 <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
Message-ID: <d2060a29-fd6f-936e-8928-4900cdafbe6f@oracle.com>

Looks good.

On 10/30/2019 12:48 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233218
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233218/webrev.00
>


From alexander.matveev at oracle.com  Thu Oct 31 00:12:31 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 30 Oct 2019 17:12:31 -0700
Subject: RFR: JDK-8233138: Error 2343 when using --win-dir-chooser
In-Reply-To: <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
References: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
 <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
Message-ID: <602bc9fa-3dd0-57d9-b2c2-467f8be292c5@oracle.com>

Hi Alexey,

Looks good. Did you test it by trying to install into existing folder? I 
remember having issues reading some variables in libwixhelper.cpp.

Thanks,
Alexander

On 10/30/2019 1:42 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally removed code that adds component to msi package to remove 
> files and directories not managed by the msi package in shortcuts 
> folder (changes in WixSourcesBuilder.java).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233138
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233138/webrev.00
>


From andy.herrick at oracle.com  Thu Oct 31 00:15:51 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 30 Oct 2019 20:15:51 -0400
Subject: RFR: JDK-8233218: rpm uninstall errors (xdg-icon-resource: the
 icon size must be specified with --size)
In-Reply-To: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
References: <34497516-fcdb-ce41-c380-4e5365d3dbdf@oracle.com>
 <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
Message-ID: <66f569b0-865c-c8ff-e45b-84807b727fde@oracle.com>

looks good.

/Andy

On 10/30/2019 3:48 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233218
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233218/webrev.00
>

From andy.herrick at oracle.com  Thu Oct 31 00:16:05 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 30 Oct 2019 20:16:05 -0400
Subject: RFR: JDK-8233138: Error 2343 when using --win-dir-chooser
In-Reply-To: <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
References: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
 <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
Message-ID: <18ffe2cc-8c8e-f49e-2c0d-73822fb6a78d@oracle.com>

looks good


/Andy


On 10/30/2019 4:42 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally removed code that adds component to msi package to remove 
> files and directories not managed by the msi package in shortcuts 
> folder (changes in WixSourcesBuilder.java).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233138
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233138/webrev.00
>

From alexander.matveev at oracle.com  Thu Oct 31 00:29:32 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 30 Oct 2019 17:29:32 -0700
Subject: RFR: JDK-8233143: RPM errors: rpmbuild: no spec files given for
 build
In-Reply-To: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com>
References: <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
 <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com>
Message-ID: <c9530e67-7919-ccfa-9870-3fa7e8c880d2@oracle.com>

Looks good.

On 10/30/2019 3:03 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233143
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233143/webrev.00
>


From andy.herrick at oracle.com  Thu Oct 31 00:30:22 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 30 Oct 2019 20:30:22 -0400
Subject: RFR: JDK-8233143: RPM errors: rpmbuild: no spec files given for
 build
In-Reply-To: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com>
References: <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
 <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com>
Message-ID: <46d9fd6c-50e7-4d01-c1ee-c3e4a5077d53@oracle.com>

looks good.

/Andy

On 10/30/2019 6:03 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233143
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233143/webrev.00
>

From serguei.spitsyn at oracle.com  Thu Oct 31 00:36:29 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 30 Oct 2019 17:36:29 -0700
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
 <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
 <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
Message-ID: <3007b1c6-6a9a-bad4-edf5-ce8e5a54ac18@oracle.com>

Hi David,

The update looks good.

Thanks,
Serguei

On 10/29/19 9:28 PM, David Holmes wrote:
> Hi Doug,
>
> Your proposed patch wasn't quite right. I made some adjustments but 
> I'm still having issues with the test, 
> HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see 
> how to make the test execution conditional on the VM config.
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/
>
> Thanks,
> David
> -----
>
>
> On 29/10/2019 7:14 pm, Doug Simon wrote:
>>
>>
>>> On 29 Oct 2019, at 10:12, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>> Hi Doug,
>>>
>>> Thanks for taking a look so quickly! :)
>>>
>>> On 29/10/2019 6:55 pm, Doug Simon wrote:
>>>> Hi David,
>>>> Since Graal needs to work against multiple JVMCI versions (and VM 
>>>> versions!), the Graal changes should only disable the intrinsic 
>>>> when the relevant VM config is missing:
>>>
>>> So to be clear I should revert all the Graal file changes I made and 
>>> just apply the patch below?
>>
>> Yes please.
>>
>> -Doug
>>
>>>
>>>> diff --git 
>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 
>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 
>>>>
>>>> index 0752a621215..baa2136a6ba 100644
>>>> --- 
>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>> +++ 
>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends 
>>>> GraalHotSpotVMConfigBase {
>>>> ????? public final int javaThreadAnchorOffset = 
>>>> getFieldOffset("JavaThread::_anchor", Integer.class, 
>>>> "JavaFrameAnchor");
>>>> ????? public final int javaThreadShouldPostOnExceptionsFlagOffset = 
>>>> getFieldOffset("JavaThread::_should_post_on_exceptions_flag", 
>>>> Integer.class, "int", Integer.MIN_VALUE);
>>>> ????? public final int threadObjectOffset = 
>>>> getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
>>>> -??? public final int osThreadOffset = 
>>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
>>>> +??? public final int osThreadOffset = 
>>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", 
>>>> Integer.MAX_VALUE);
>>>> ????? public final int threadIsMethodHandleReturnOffset = 
>>>> getFieldOffset("JavaThread::_is_method_handle_return", 
>>>> Integer.class, "int");
>>>> ????? public final int threadObjectResultOffset = 
>>>> getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
>>>> ????? public final int jvmciCountersThreadOffset = 
>>>> getFieldOffset("JavaThread::_jvmci_counters", Integer.class, 
>>>> "jlong*");
>>>> diff --git 
>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java 
>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java 
>>>>
>>>> index 6b37fff083d..ffc8032d2b0 100644
>>>> --- 
>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>> +++ 
>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
>>>> ????????????? }
>>>> ????????? });
>>>> ? - r.registerMethodSubstitution(ThreadSubstitutions.class, 
>>>> "isInterrupted", Receiver.class, boolean.class);
>>>> +??????? if (config.osThreadOffset != Integer.MAX_VALUE) {
>>>> + r.registerMethodSubstitution(ThreadSubstitutions.class, 
>>>> "isInterrupted", Receiver.class, boolean.class);
>>>> +??????? }
>>>> ????? }
>>>> ??????? public static final String reflectionClass;
>>>> diff --git 
>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java 
>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java 
>>>>
>>>> index 1d694fae2a4..8500c4de115 100644
>>>> --- 
>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>> +++ 
>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
>>>> ??????? @Fold
>>>> ????? public static int osThreadOffset(@InjectedParameter 
>>>> GraalHotSpotVMConfig config) {
>>>> +??????? assert config.instanceKlassInitThreadOffset != 
>>>> Integer.MAX_VALUE;
>>>> ????????? return config.osThreadOffset;
>>>> ????? }
>>>> ? All the other JVMCI changes look good to me.
>>>> -Doug
>>>>> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already 
>>>>> approved)
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>>>>
>>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, 
>>>>> but only in small pieces each. There is also a small touch to 
>>>>> serviceability code.
>>>>>
>>>>> This change is "simply" moving the "interrupted" field out of the 
>>>>> osThread and into the java.lang.Thread so that it can be set 
>>>>> independently of whether the thread is alive (and to make things 
>>>>> easier for loom in the near future). It is very straightforward:
>>>>>
>>>>> - old scheme
>>>>> ? - interrupted field is in osThread
>>>>> ? - VM can read/write directly
>>>>> ? - Java code calls into VM to read/write
>>>>>
>>>>> - new scheme
>>>>> ? - interrupted field is in java.lang.Thread
>>>>> ? - VM has to use javaCalls to read/write "directly"
>>>>> ? - Java code can read/write directly
>>>>>
>>>>> No changes to any of the semantics regarding the actual interrupt 
>>>>> mechanism. Special thanks to Patricio for tracking down a bug I 
>>>>> had introduced in that regard!
>>>>>
>>>>> Special Note (Hi Roger!): on windows we still need to set/clear 
>>>>> the _interrupt_event used by the Process.waitFor logic. To 
>>>>> facilitate clearing via Thread.interrupted() I had to introduce a 
>>>>> native method that is a no-op except on Windows. This seemed the 
>>>>> cheapest and least intrusive means to achieve this.
>>>>>
>>>>> Other changes revolve around the fact we used to have an intrinsic 
>>>>> for Thread.isInterrupted and that is not needed any more. So we 
>>>>> strip some code out of C1/C2.
>>>>>
>>>>> The changes in the JVMCI/Graal code are a bit more far reaching as 
>>>>> entire classes disappear. I've cc'd Doug and Tom at Vladimir's 
>>>>> request so that they can comment on the JVMCI changes and whether 
>>>>> I have gone too far or not far enough. There are a bunch of tests 
>>>>> for interruption in JVMCI that could potentially be deleted if 
>>>>> they are only intended to test the JVMCI handling of interrupt:
>>>>>
>>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java 
>>>>>
>>>>>
>>>>> Testing:
>>>>> - Tiers 1-3 on all Oracle platforms
>>>>> - Focused testing on Linux x64:
>>>>> ??? - Stress runs of JSR166TestCase
>>>>> ??? - Anything that seems to use interrupt():
>>>>> ????? - JDK
>>>>> ??????? - java/lang/Thread
>>>>> ??????? - java/util/concurrent
>>>>> ??????? - jdk/internal/loader/InterruptedClassLoad.java
>>>>> ??????? - javax/management
>>>>> ??????? - java/nio/file/Files
>>>>> ??????? - java/nio/channels
>>>>> ??????? - java/net/Socket/Timeouts.java
>>>>> ??????? - java/lang/Runtime/shutdown/
>>>>> ??????? - java/lang/ProcessBuilder/Basic.java
>>>>> ??????? - com/sun/jdi/
>>>>> ????? - Hotspot
>>>>> ??????? - vmTestbase/nsk/monitoring/
>>>>> ??????? - vmTestbase/nsk/jdwp
>>>>> ??????? - vmTestbase/nsk/jdb/
>>>>> ??????? - vmTestbase/nsk/jdi/
>>>>> ??????? - vmTestbase/nsk/jvmti/
>>>>> ??????? - runtime/Thread
>>>>> ??????? - serviceability/jvmti/
>>>>> ??????? - serviceability/jdwp
>>>>> ??????? - serviceability/sa
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>


From alexander.matveev at oracle.com  Thu Oct 31 00:37:40 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 30 Oct 2019 17:37:40 -0700
Subject: RFR: JDK-8232186: Add verification for pkg and dmg tests
In-Reply-To: <0386461d-d470-f2e4-eb9a-0f4e6e1befd3@oracle.com>
References: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>
 <2b6673e4-9b73-9e89-d46c-9bd0c7a72678@oracle.com>
 <c1d9497f-7654-40f1-69dc-886fec270bca@oracle.com>
 <0386461d-d470-f2e4-eb9a-0f4e6e1befd3@oracle.com>
Message-ID: <d61b2750-9f8a-a40d-ff65-177e84285ccc@oracle.com>

http://cr.openjdk.java.net/~almatvee/8232186/webrev.04/

- Added trace to Hello.java.
- Re-done how FA is excluded for DMG tests.

Thanks,
Alexander

On 10/29/2019 10:42 AM, Alexey Semenyuk wrote:
> http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/test/jdk/tools/jpackage/share/AdditionalLaunchersTest.java.sdiff.html: 
>
>
> To disable running the test for dmg packaging, just call 
> packageTest.excludeTypes(PackageType.MAC_DMG) like this is done in 
> FileAssociationsTest test.
>
> The way PackageTest.isCurrentType() is used in AdditionalLaunchersTest 
> would disable fa checks for pkg packaging if the test would be 
> executed in the environment that supports both dmg and pkg packaging. 
> If you'd take a look at Mach5 test logs, you will see that the same 
> test is used to produce and verify pkg and dmg packages in one run. 
> Similarly on Windows tests build and verify exe and msi installers in 
> a single test run.
>
> So I'd suggest to remove PackageTest.isCurrentType() at all from 
> PackageTest class. It is not needed.
>
> - Alexey
>
> On 10/29/2019 1:19 AM, Alexander Matveev wrote:
>> Changes since last review:
>>
>> http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/
>>
>> - Hello.java combined into one test app and will be used by all tests.
>> - appOutput.txt will be created in same folder as file used for file 
>> association.
>> - Other minor changes.
>>
>> Thanks,
>> Alexander
>>
>> On 10/23/19 10:07 AM, Andy Herrick wrote:
>>> looks ok to me
>>>
>>> /ANdy
>>>
>>> On 10/22/2019 5:29 PM, Alexander Matveev wrote:
>>>> Please review the jpackage fix for bug [1] at [2].
>>>>
>>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>>> repository (jpackage).
>>>>
>>>> - Removed --mac-app-store-category.
>>>> - Added Hello.java test app to support file association on OS X.
>>>> - Modified Hello.java to write output file to user home location if 
>>>> working directory is not writable.
>>>> - Fixed MacHelper:getInstallationDirectory(). It was returning 
>>>> extra /Applications when --install-dir is specified.
>>>> - Fixed SigningPackageTest to use path returned by withExplodedDmg 
>>>> correctly.
>>>> - Added install/uninstall support for pkg and dmg to 
>>>> manage_packages.sh.
>>>> - Fixed replaceFileName(), otherwise on OS X it was not replacing 
>>>> file name correctly, since file name does not have extension.
>>>> - Added NameWithSpaceTest.
>>>> - Removed OptionsTest which is covered by other tests.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232186
>>>>
>>>> [2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/
>>>>
>>>> Thanks,
>>>> Alexander
>>
>


From david.holmes at oracle.com  Thu Oct 31 01:34:06 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 31 Oct 2019 11:34:06 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <3007b1c6-6a9a-bad4-edf5-ce8e5a54ac18@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
 <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
 <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
 <3007b1c6-6a9a-bad4-edf5-ce8e5a54ac18@oracle.com>
Message-ID: <619a83de-1602-9395-47e4-a8e6c6968103@oracle.com>

Thanks Serguei!

David

On 31/10/2019 10:36 am, serguei.spitsyn at oracle.com wrote:
> Hi David,
> 
> The update looks good.
> 
> Thanks,
> Serguei
> 
> On 10/29/19 9:28 PM, David Holmes wrote:
>> Hi Doug,
>>
>> Your proposed patch wasn't quite right. I made some adjustments but 
>> I'm still having issues with the test, 
>> HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see 
>> how to make the test execution conditional on the VM config.
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/
>>
>> Thanks,
>> David
>> -----
>>
>>
>> On 29/10/2019 7:14 pm, Doug Simon wrote:
>>>
>>>
>>>> On 29 Oct 2019, at 10:12, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Doug,
>>>>
>>>> Thanks for taking a look so quickly! :)
>>>>
>>>> On 29/10/2019 6:55 pm, Doug Simon wrote:
>>>>> Hi David,
>>>>> Since Graal needs to work against multiple JVMCI versions (and VM 
>>>>> versions!), the Graal changes should only disable the intrinsic 
>>>>> when the relevant VM config is missing:
>>>>
>>>> So to be clear I should revert all the Graal file changes I made and 
>>>> just apply the patch below?
>>>
>>> Yes please.
>>>
>>> -Doug
>>>
>>>>
>>>>> diff --git 
>>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 
>>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 
>>>>>
>>>>> index 0752a621215..baa2136a6ba 100644
>>>>> --- 
>>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 
>>>>>
>>>>> +++ 
>>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 
>>>>>
>>>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends 
>>>>> GraalHotSpotVMConfigBase {
>>>>> ????? public final int javaThreadAnchorOffset = 
>>>>> getFieldOffset("JavaThread::_anchor", Integer.class, 
>>>>> "JavaFrameAnchor");
>>>>> ????? public final int javaThreadShouldPostOnExceptionsFlagOffset = 
>>>>> getFieldOffset("JavaThread::_should_post_on_exceptions_flag", 
>>>>> Integer.class, "int", Integer.MIN_VALUE);
>>>>> ????? public final int threadObjectOffset = 
>>>>> getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
>>>>> -??? public final int osThreadOffset = 
>>>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
>>>>> +??? public final int osThreadOffset = 
>>>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", 
>>>>> Integer.MAX_VALUE);
>>>>> ????? public final int threadIsMethodHandleReturnOffset = 
>>>>> getFieldOffset("JavaThread::_is_method_handle_return", 
>>>>> Integer.class, "int");
>>>>> ????? public final int threadObjectResultOffset = 
>>>>> getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
>>>>> ????? public final int jvmciCountersThreadOffset = 
>>>>> getFieldOffset("JavaThread::_jvmci_counters", Integer.class, 
>>>>> "jlong*");
>>>>> diff --git 
>>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java 
>>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java 
>>>>>
>>>>> index 6b37fff083d..ffc8032d2b0 100644
>>>>> --- 
>>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java 
>>>>>
>>>>> +++ 
>>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java 
>>>>>
>>>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
>>>>> ????????????? }
>>>>> ????????? });
>>>>> ? - r.registerMethodSubstitution(ThreadSubstitutions.class, 
>>>>> "isInterrupted", Receiver.class, boolean.class);
>>>>> +??????? if (config.osThreadOffset != Integer.MAX_VALUE) {
>>>>> + r.registerMethodSubstitution(ThreadSubstitutions.class, 
>>>>> "isInterrupted", Receiver.class, boolean.class);
>>>>> +??????? }
>>>>> ????? }
>>>>> ??????? public static final String reflectionClass;
>>>>> diff --git 
>>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java 
>>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java 
>>>>>
>>>>> index 1d694fae2a4..8500c4de115 100644
>>>>> --- 
>>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java 
>>>>>
>>>>> +++ 
>>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java 
>>>>>
>>>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
>>>>> ??????? @Fold
>>>>> ????? public static int osThreadOffset(@InjectedParameter 
>>>>> GraalHotSpotVMConfig config) {
>>>>> +??????? assert config.instanceKlassInitThreadOffset != 
>>>>> Integer.MAX_VALUE;
>>>>> ????????? return config.osThreadOffset;
>>>>> ????? }
>>>>> ? All the other JVMCI changes look good to me.
>>>>> -Doug
>>>>>> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already 
>>>>>> approved)
>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>>>>>
>>>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, 
>>>>>> but only in small pieces each. There is also a small touch to 
>>>>>> serviceability code.
>>>>>>
>>>>>> This change is "simply" moving the "interrupted" field out of the 
>>>>>> osThread and into the java.lang.Thread so that it can be set 
>>>>>> independently of whether the thread is alive (and to make things 
>>>>>> easier for loom in the near future). It is very straightforward:
>>>>>>
>>>>>> - old scheme
>>>>>> ? - interrupted field is in osThread
>>>>>> ? - VM can read/write directly
>>>>>> ? - Java code calls into VM to read/write
>>>>>>
>>>>>> - new scheme
>>>>>> ? - interrupted field is in java.lang.Thread
>>>>>> ? - VM has to use javaCalls to read/write "directly"
>>>>>> ? - Java code can read/write directly
>>>>>>
>>>>>> No changes to any of the semantics regarding the actual interrupt 
>>>>>> mechanism. Special thanks to Patricio for tracking down a bug I 
>>>>>> had introduced in that regard!
>>>>>>
>>>>>> Special Note (Hi Roger!): on windows we still need to set/clear 
>>>>>> the _interrupt_event used by the Process.waitFor logic. To 
>>>>>> facilitate clearing via Thread.interrupted() I had to introduce a 
>>>>>> native method that is a no-op except on Windows. This seemed the 
>>>>>> cheapest and least intrusive means to achieve this.
>>>>>>
>>>>>> Other changes revolve around the fact we used to have an intrinsic 
>>>>>> for Thread.isInterrupted and that is not needed any more. So we 
>>>>>> strip some code out of C1/C2.
>>>>>>
>>>>>> The changes in the JVMCI/Graal code are a bit more far reaching as 
>>>>>> entire classes disappear. I've cc'd Doug and Tom at Vladimir's 
>>>>>> request so that they can comment on the JVMCI changes and whether 
>>>>>> I have gone too far or not far enough. There are a bunch of tests 
>>>>>> for interruption in JVMCI that could potentially be deleted if 
>>>>>> they are only intended to test the JVMCI handling of interrupt:
>>>>>>
>>>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java 
>>>>>>
>>>>>>
>>>>>> Testing:
>>>>>> - Tiers 1-3 on all Oracle platforms
>>>>>> - Focused testing on Linux x64:
>>>>>> ??? - Stress runs of JSR166TestCase
>>>>>> ??? - Anything that seems to use interrupt():
>>>>>> ????? - JDK
>>>>>> ??????? - java/lang/Thread
>>>>>> ??????? - java/util/concurrent
>>>>>> ??????? - jdk/internal/loader/InterruptedClassLoad.java
>>>>>> ??????? - javax/management
>>>>>> ??????? - java/nio/file/Files
>>>>>> ??????? - java/nio/channels
>>>>>> ??????? - java/net/Socket/Timeouts.java
>>>>>> ??????? - java/lang/Runtime/shutdown/
>>>>>> ??????? - java/lang/ProcessBuilder/Basic.java
>>>>>> ??????? - com/sun/jdi/
>>>>>> ????? - Hotspot
>>>>>> ??????? - vmTestbase/nsk/monitoring/
>>>>>> ??????? - vmTestbase/nsk/jdwp
>>>>>> ??????? - vmTestbase/nsk/jdb/
>>>>>> ??????? - vmTestbase/nsk/jdi/
>>>>>> ??????? - vmTestbase/nsk/jvmti/
>>>>>> ??????? - runtime/Thread
>>>>>> ??????? - serviceability/jvmti/
>>>>>> ??????? - serviceability/jdwp
>>>>>> ??????? - serviceability/sa
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
>>>
> 

From alexey.semenyuk at oracle.com  Thu Oct 31 02:16:59 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 30 Oct 2019 22:16:59 -0400
Subject: RFR: JDK-8233138: Error 2343 when using --win-dir-chooser
In-Reply-To: <602bc9fa-3dd0-57d9-b2c2-467f8be292c5@oracle.com>
References: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
 <e187d3f7-fa24-8aab-66de-7856715bb168@oracle.com>
 <602bc9fa-3dd0-57d9-b2c2-467f8be292c5@oracle.com>
Message-ID: <fb81d92a-15fd-c14d-6aec-66930c7fe47e@oracle.com>



On 10/30/2019 8:12 PM, Alexander Matveev wrote:
> Hi Alexey,
>
> Looks good. 

> Did you test it by trying to install into existing folder? I remember 
> having issues reading some variables in libwixhelper.cpp.
Yes, I did. Without the fix in libwixhelper.cpp it allowed to install in 
non-empty directory.

- Alexey
>
> Thanks,
> Alexander
>
> On 10/30/2019 1:42 PM, Alexey Semenyuk wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> Additionally removed code that adds component to msi package to 
>> remove files and directories not managed by the msi package in 
>> shortcuts folder (changes in WixSourcesBuilder.java).
>>
>> - Alexey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233138
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8233138/webrev.00
>>
>


From alexey.semenyuk at oracle.com  Thu Oct 31 02:22:41 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 30 Oct 2019 22:22:41 -0400
Subject: RFR: JDK-8232186: Add verification for pkg and dmg tests
In-Reply-To: <d61b2750-9f8a-a40d-ff65-177e84285ccc@oracle.com>
References: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>
 <2b6673e4-9b73-9e89-d46c-9bd0c7a72678@oracle.com>
 <c1d9497f-7654-40f1-69dc-886fec270bca@oracle.com>
 <0386461d-d470-f2e4-eb9a-0f4e6e1befd3@oracle.com>
 <d61b2750-9f8a-a40d-ff65-177e84285ccc@oracle.com>
Message-ID: <d5fc273c-0c53-f898-70cb-c049e4e298dd@oracle.com>

Looks good.

- Alexey

On 10/30/2019 8:37 PM, Alexander Matveev wrote:
> http://cr.openjdk.java.net/~almatvee/8232186/webrev.04/
>
> - Added trace to Hello.java.
> - Re-done how FA is excluded for DMG tests.
>
> Thanks,
> Alexander
>
> On 10/29/2019 10:42 AM, Alexey Semenyuk wrote:
>> http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/test/jdk/tools/jpackage/share/AdditionalLaunchersTest.java.sdiff.html: 
>>
>>
>> To disable running the test for dmg packaging, just call 
>> packageTest.excludeTypes(PackageType.MAC_DMG) like this is done in 
>> FileAssociationsTest test.
>>
>> The way PackageTest.isCurrentType() is used in 
>> AdditionalLaunchersTest would disable fa checks for pkg packaging if 
>> the test would be executed in the environment that supports both dmg 
>> and pkg packaging. If you'd take a look at Mach5 test logs, you will 
>> see that the same test is used to produce and verify pkg and dmg 
>> packages in one run. Similarly on Windows tests build and verify exe 
>> and msi installers in a single test run.
>>
>> So I'd suggest to remove PackageTest.isCurrentType() at all from 
>> PackageTest class. It is not needed.
>>
>> - Alexey
>>
>> On 10/29/2019 1:19 AM, Alexander Matveev wrote:
>>> Changes since last review:
>>>
>>> http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/
>>>
>>> - Hello.java combined into one test app and will be used by all tests.
>>> - appOutput.txt will be created in same folder as file used for file 
>>> association.
>>> - Other minor changes.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 10/23/19 10:07 AM, Andy Herrick wrote:
>>>> looks ok to me
>>>>
>>>> /ANdy
>>>>
>>>> On 10/22/2019 5:29 PM, Alexander Matveev wrote:
>>>>> Please review the jpackage fix for bug [1] at [2].
>>>>>
>>>>> This is a fix for the JDK-8200758-branch branch of the open 
>>>>> sandbox repository (jpackage).
>>>>>
>>>>> - Removed --mac-app-store-category.
>>>>> - Added Hello.java test app to support file association on OS X.
>>>>> - Modified Hello.java to write output file to user home location 
>>>>> if working directory is not writable.
>>>>> - Fixed MacHelper:getInstallationDirectory(). It was returning 
>>>>> extra /Applications when --install-dir is specified.
>>>>> - Fixed SigningPackageTest to use path returned by withExplodedDmg 
>>>>> correctly.
>>>>> - Added install/uninstall support for pkg and dmg to 
>>>>> manage_packages.sh.
>>>>> - Fixed replaceFileName(), otherwise on OS X it was not replacing 
>>>>> file name correctly, since file name does not have extension.
>>>>> - Added NameWithSpaceTest.
>>>>> - Removed OptionsTest which is covered by other tests.
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232186
>>>>>
>>>>> [2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>
>>
>


From david.holmes at oracle.com  Thu Oct 31 04:30:16 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 31 Oct 2019 14:30:16 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
 <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
 <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
 <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com>
Message-ID: <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com>

Hi Doug,

On 30/10/2019 10:06 pm, Doug Simon wrote:
> 
> 
>> On 30 Oct 2019, at 05:28, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Doug,
>>
>> Your proposed patch wasn't quite right. I made some adjustments but I'm still having issues with the test, HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see how to make the test execution conditional on the VM config.
> 
> Like this:

Thanks for that! One alteration below ...

> diff --git a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
> index 96e7d979d36..3c928b86961 100644
> --- a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
> +++ b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
> @@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite;
>   import java.lang.invoke.MethodHandles;
>   import java.lang.invoke.MethodType;
> 
> -import org.graalvm.compiler.nodes.IfNode;
> -import org.junit.Test;
> -
>   import org.graalvm.compiler.api.directives.GraalDirectives;
>   import org.graalvm.compiler.api.replacements.MethodSubstitution;
> +import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig;
> +import org.graalvm.compiler.hotspot.HotSpotBackend;
> +import org.graalvm.compiler.nodes.IfNode;
>   import org.graalvm.compiler.replacements.test.MethodSubstitutionTest;
> +import org.junit.Test;
> 
>   /**
>    * Tests HotSpot specific {@link MethodSubstitution}s.
> @@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest extends MethodSubstitutionTest {
> 
>       @Test
>       public void testThreadSubstitutions() {
> +        GraalHotSpotVMConfig config = ((HotSpotBackend) getBackend()).getRuntime().getVMConfig();
>           testGraph("currentThread");
> -        assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class);
> -        assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class);
> +        if (config.osThreadOffset != Integer.MAX_VALUE) {

s/osThreadOffset/osThreadInterruptedOffset/

This change removes the interrupted field from osThread but not osThread 
itself. Though as osThread is only used to then access the interrupted 
field, I could both the same. Here's updated webrev showing that:

http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/

All tests under compiler/graalunit now pass.

Thanks,
David
-----

> +            assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class);
> +            assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class);
> +        }
> 
>           Thread currentThread = Thread.currentThread();
>           test("currentThread", currentThread);
> -        test("threadIsInterrupted", currentThread);
> +        if (config.osThreadOffset != Integer.MAX_VALUE) {
> +            test("threadIsInterrupted", currentThread);
> +        }
>       }
> 
>       @SuppressWarnings("all")
> 
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/
>>
>> Thanks,
>> David
>> -----
>>
>>
>> On 29/10/2019 7:14 pm, Doug Simon wrote:
>>>> On 29 Oct 2019, at 10:12, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Doug,
>>>>
>>>> Thanks for taking a look so quickly! :)
>>>>
>>>> On 29/10/2019 6:55 pm, Doug Simon wrote:
>>>>> Hi David,
>>>>> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing:
>>>>
>>>> So to be clear I should revert all the Graal file changes I made and just apply the patch below?
>>> Yes please.
>>> -Doug
>>>>
>>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>>> index 0752a621215..baa2136a6ba 100644
>>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
>>>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase {
>>>>>       public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor");
>>>>>       public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE);
>>>>>       public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop");
>>>>> -    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*");
>>>>> +    public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE);
>>>>>       public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int");
>>>>>       public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop");
>>>>>       public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*");
>>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>>> index 6b37fff083d..ffc8032d2b0 100644
>>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
>>>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins {
>>>>>               }
>>>>>           });
>>>>>   -        r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>>>>> +        if (config.osThreadOffset != Integer.MAX_VALUE) {
>>>>> +            r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class);
>>>>> +        }
>>>>>       }
>>>>>         public static final String reflectionClass;
>>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>>> index 1d694fae2a4..8500c4de115 100644
>>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
>>>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil {
>>>>>         @Fold
>>>>>       public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) {
>>>>> +        assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE;
>>>>>           return config.osThreadOffset;
>>>>>       }
>>>>>   All the other JVMCI changes look good to me.
>>>>> -Doug
>>>>>> On 29 Oct 2019, at 08:42, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
>>>>>>
>>>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code.
>>>>>>
>>>>>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward:
>>>>>>
>>>>>> - old scheme
>>>>>>   - interrupted field is in osThread
>>>>>>   - VM can read/write directly
>>>>>>   - Java code calls into VM to read/write
>>>>>>
>>>>>> - new scheme
>>>>>>   - interrupted field is in java.lang.Thread
>>>>>>   - VM has to use javaCalls to read/write "directly"
>>>>>>   - Java code can read/write directly
>>>>>>
>>>>>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard!
>>>>>>
>>>>>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this.
>>>>>>
>>>>>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2.
>>>>>>
>>>>>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt:
>>>>>>
>>>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
>>>>>>
>>>>>> Testing:
>>>>>> - Tiers 1-3 on all Oracle platforms
>>>>>> - Focused testing on Linux x64:
>>>>>>     - Stress runs of JSR166TestCase
>>>>>>     - Anything that seems to use interrupt():
>>>>>>       - JDK
>>>>>>         - java/lang/Thread
>>>>>>         - java/util/concurrent
>>>>>>         - jdk/internal/loader/InterruptedClassLoad.java
>>>>>>         - javax/management
>>>>>>         - java/nio/file/Files
>>>>>>         - java/nio/channels
>>>>>>         - java/net/Socket/Timeouts.java
>>>>>>         - java/lang/Runtime/shutdown/
>>>>>>         - java/lang/ProcessBuilder/Basic.java
>>>>>>         - com/sun/jdi/
>>>>>>       - Hotspot
>>>>>>         - vmTestbase/nsk/monitoring/
>>>>>>         - vmTestbase/nsk/jdwp
>>>>>>         - vmTestbase/nsk/jdb/
>>>>>>         - vmTestbase/nsk/jdi/
>>>>>>         - vmTestbase/nsk/jvmti/
>>>>>>         - runtime/Thread
>>>>>>         - serviceability/jvmti/
>>>>>>         - serviceability/jdwp
>>>>>>         - serviceability/sa
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
> 

From fujie at loongson.cn  Thu Oct 31 06:13:19 2019
From: fujie at loongson.cn (Jie Fu)
Date: Thu, 31 Oct 2019 14:13:19 +0800
Subject: RFR: 8233291: [TESTBUG]
 tools/jlink/plugins/VendorInfoPluginsTest.java fails with debug VMs
Message-ID: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn>

Hi all,

May I get reviews for the small fix for the failure of 
VendorInfoPluginsTest.java in debug VMs?

JBS:??? https://bugs.openjdk.java.net/browse/JDK-8233291
Webrev: http://cr.openjdk.java.net/~jiefu/8233291/webrev.00/

Thanks a lot.
Best regards,
Jie



From doug.simon at oracle.com  Thu Oct 31 07:47:54 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 31 Oct 2019 08:47:54 +0100
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
 <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
 <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
 <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com>
 <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com>
Message-ID: <7E58F19E-5B78-4F96-B328-B9C485CABF86@oracle.com>



> On 31 Oct 2019, at 05:30, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Doug,
> 
> On 30/10/2019 10:06 pm, Doug Simon wrote:
>>> On 30 Oct 2019, at 05:28, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>> 
>>> Hi Doug,
>>> 
>>> Your proposed patch wasn't quite right. I made some adjustments but I'm still having issues with the test, HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see how to make the test execution conditional on the VM config.
>> Like this:
> 
> Thanks for that! One alteration below ...
> 
>> diff --git a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
>> index 96e7d979d36..3c928b86961 100644
>> --- a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
>> +++ b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
>> @@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite;
>>  import java.lang.invoke.MethodHandles;
>>  import java.lang.invoke.MethodType;
>> -import org.graalvm.compiler.nodes.IfNode;
>> -import org.junit.Test;
>> -
>>  import org.graalvm.compiler.api.directives.GraalDirectives;
>>  import org.graalvm.compiler.api.replacements.MethodSubstitution;
>> +import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig;
>> +import org.graalvm.compiler.hotspot.HotSpotBackend;
>> +import org.graalvm.compiler.nodes.IfNode;
>>  import org.graalvm.compiler.replacements.test.MethodSubstitutionTest;
>> +import org.junit.Test;
>>  /**
>>   * Tests HotSpot specific {@link MethodSubstitution}s.
>> @@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest extends MethodSubstitutionTest {
>>      @Test
>>      public void testThreadSubstitutions() {
>> +        GraalHotSpotVMConfig config = ((HotSpotBackend) getBackend()).getRuntime().getVMConfig();
>>          testGraph("currentThread");
>> -        assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class);
>> -        assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class);
>> +        if (config.osThreadOffset != Integer.MAX_VALUE) {
> 
> s/osThreadOffset/osThreadInterruptedOffset/

Good catch. Sorry about that.
> 
> This change removes the interrupted field from osThread but not osThread itself. Though as osThread is only used to then access the interrupted field, I could both the same. Here's updated webrev showing that:
> 
> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ <http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/>

Looks good.

-Doug

From david.holmes at oracle.com  Thu Oct 31 08:45:00 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 31 Oct 2019 18:45:00 +1000
Subject: RFR: 8229516: Thread.isInterrupted() always returns false after
 thread termination
In-Reply-To: <7E58F19E-5B78-4F96-B328-B9C485CABF86@oracle.com>
References: <be5fedb6-89c3-bfb3-a148-05acfb8caf32@oracle.com>
 <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com>
 <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com>
 <D56D2519-4DA8-4941-84B0-3A91650C675E@oracle.com>
 <c1d7fced-9256-539d-1df7-ff65b33139f3@oracle.com>
 <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com>
 <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com>
 <7E58F19E-5B78-4F96-B328-B9C485CABF86@oracle.com>
Message-ID: <57b1a2ad-2361-dfee-0085-2098fefe1d66@oracle.com>

Thanks Doug! Appreciate the help getting the Graal bits correct.

David

On 31/10/2019 5:47 pm, Doug Simon wrote:
> 
> 
>> On 31 Oct 2019, at 05:30, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> Hi Doug,
>>
>> On 30/10/2019 10:06 pm, Doug Simon wrote:
>>>> On 30 Oct 2019, at 05:28, David Holmes <david.holmes at oracle.com 
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>> Hi Doug,
>>>>
>>>> Your proposed patch wasn't quite right. I made some adjustments but 
>>>> I'm still having issues with the test, 
>>>> HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't 
>>>> see how to make the test execution conditional on the VM config.
>>> Like this:
>>
>> Thanks for that! One alteration below ...
>>
>>> diff --git 
>>> a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java 
>>> b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
>>> index 96e7d979d36..3c928b86961 100644
>>> --- 
>>> a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
>>> +++ 
>>> b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
>>> @@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite;
>>> ?import java.lang.invoke.MethodHandles;
>>> ?import java.lang.invoke.MethodType;
>>> -import org.graalvm.compiler.nodes.IfNode;
>>> -import org.junit.Test;
>>> -
>>> ?import org.graalvm.compiler.api.directives.GraalDirectives;
>>> ?import org.graalvm.compiler.api.replacements.MethodSubstitution;
>>> +import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig;
>>> +import org.graalvm.compiler.hotspot.HotSpotBackend;
>>> +import org.graalvm.compiler.nodes.IfNode;
>>> ?import org.graalvm.compiler.replacements.test.MethodSubstitutionTest;
>>> +import org.junit.Test;
>>> ?/**
>>> ??* Tests HotSpot specific {@link MethodSubstitution}s.
>>> @@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest 
>>> extends MethodSubstitutionTest {
>>> ?????@Test
>>> ?????public void testThreadSubstitutions() {
>>> + ???????GraalHotSpotVMConfig config = ((HotSpotBackend) 
>>> getBackend()).getRuntime().getVMConfig();
>>> ?????????testGraph("currentThread");
>>> - ???????assertInGraph(testGraph("threadIsInterrupted", 
>>> "isInterrupted", true), IfNode.class);
>>> - ???????assertInGraph(testGraph("threadInterrupted", 
>>> "isInterrupted", true), IfNode.class);
>>> + ???????if (config.osThreadOffset != Integer.MAX_VALUE) {
>>
>> s/osThreadOffset/osThreadInterruptedOffset/
> 
> Good catch. Sorry about that.
>>
>> This change removes the interrupted field from osThread but not 
>> osThread itself. Though as osThread is only used to then access the 
>> interrupted field, I could both the same. Here's updated webrev 
>> showing that:
>>
>> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/
> 
> Looks good.
> 
> -Doug

From andy.herrick at oracle.com  Thu Oct 31 12:29:42 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 31 Oct 2019 08:29:42 -0400
Subject: RFR: JDK-8232186: Add verification for pkg and dmg tests
In-Reply-To: <d61b2750-9f8a-a40d-ff65-177e84285ccc@oracle.com>
References: <a665b674-18a3-ba43-8b80-ad9d4c7bed6b@oracle.com>
 <2b6673e4-9b73-9e89-d46c-9bd0c7a72678@oracle.com>
 <c1d9497f-7654-40f1-69dc-886fec270bca@oracle.com>
 <0386461d-d470-f2e4-eb9a-0f4e6e1befd3@oracle.com>
 <d61b2750-9f8a-a40d-ff65-177e84285ccc@oracle.com>
Message-ID: <12e793b1-34f1-07d8-403a-dbbc5568d33d@oracle.com>

looks good

/Andy


On 10/30/19 8:37 PM, Alexander Matveev wrote:
> http://cr.openjdk.java.net/~almatvee/8232186/webrev.04/
>
> - Added trace to Hello.java.
> - Re-done how FA is excluded for DMG tests.
>
> Thanks,
> Alexander
>
> On 10/29/2019 10:42 AM, Alexey Semenyuk wrote:
>> http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/test/jdk/tools/jpackage/share/AdditionalLaunchersTest.java.sdiff.html: 
>>
>>
>> To disable running the test for dmg packaging, just call 
>> packageTest.excludeTypes(PackageType.MAC_DMG) like this is done in 
>> FileAssociationsTest test.
>>
>> The way PackageTest.isCurrentType() is used in 
>> AdditionalLaunchersTest would disable fa checks for pkg packaging if 
>> the test would be executed in the environment that supports both dmg 
>> and pkg packaging. If you'd take a look at Mach5 test logs, you will 
>> see that the same test is used to produce and verify pkg and dmg 
>> packages in one run. Similarly on Windows tests build and verify exe 
>> and msi installers in a single test run.
>>
>> So I'd suggest to remove PackageTest.isCurrentType() at all from 
>> PackageTest class. It is not needed.
>>
>> - Alexey
>>
>> On 10/29/2019 1:19 AM, Alexander Matveev wrote:
>>> Changes since last review:
>>>
>>> http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/
>>>
>>> - Hello.java combined into one test app and will be used by all tests.
>>> - appOutput.txt will be created in same folder as file used for file 
>>> association.
>>> - Other minor changes.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 10/23/19 10:07 AM, Andy Herrick wrote:
>>>> looks ok to me
>>>>
>>>> /ANdy
>>>>
>>>> On 10/22/2019 5:29 PM, Alexander Matveev wrote:
>>>>> Please review the jpackage fix for bug [1] at [2].
>>>>>
>>>>> This is a fix for the JDK-8200758-branch branch of the open 
>>>>> sandbox repository (jpackage).
>>>>>
>>>>> - Removed --mac-app-store-category.
>>>>> - Added Hello.java test app to support file association on OS X.
>>>>> - Modified Hello.java to write output file to user home location 
>>>>> if working directory is not writable.
>>>>> - Fixed MacHelper:getInstallationDirectory(). It was returning 
>>>>> extra /Applications when --install-dir is specified.
>>>>> - Fixed SigningPackageTest to use path returned by withExplodedDmg 
>>>>> correctly.
>>>>> - Added install/uninstall support for pkg and dmg to 
>>>>> manage_packages.sh.
>>>>> - Fixed replaceFileName(), otherwise on OS X it was not replacing 
>>>>> file name correctly, since file name does not have extension.
>>>>> - Added NameWithSpaceTest.
>>>>> - Removed OptionsTest which is covered by other tests.
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232186
>>>>>
>>>>> [2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>
>>
>

From mandy.chung at oracle.com  Thu Oct 31 18:09:15 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 31 Oct 2019 11:09:15 -0700
Subject: RFR: 8233291: [TESTBUG]
 tools/jlink/plugins/VendorInfoPluginsTest.java fails with debug VMs
In-Reply-To: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn>
References: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn>
Message-ID: <8d61987f-3134-00ab-613e-a25b03e4981f@oracle.com>

Hi Jie,

On 10/30/19 11:13 PM, Jie Fu wrote:
> Hi all,
>
> May I get reviews for the small fix for the failure of 
> VendorInfoPluginsTest.java in debug VMs?
>
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8233291
> Webrev: http://cr.openjdk.java.net/~jiefu/8233291/webrev.00/

Thanks for fixing this.

Changing the regex to ".*build.*$" is okay.? Perhaps checking if 
"jdk.debug" system property is present and prepend to the regex?

Mandy

From alexey.semenyuk at oracle.com  Thu Oct 31 19:11:12 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 31 Oct 2019 15:11:12 -0400
Subject: RFR: JDK-8233333: Incorrect comparison of number version strings in
 ToolValidator
In-Reply-To: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
References: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
Message-ID: <d5329cc7-ef2f-938b-14ee-b0526f89b364@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

Additionally:
- fixed issue with truncated log output of jtreg tests (added 
maxOutputSize=2000000 to TEST.properties)
- fixed issue in code looking up for WiX Toolkit when environment 
variables are not set

- Alexey

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

[2] http://cr.openjdk.java.net/~asemenyuk/8233333/webrev.00


From andy.herrick at oracle.com  Thu Oct 31 21:02:33 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 31 Oct 2019 17:02:33 -0400
Subject: RFR: JDK-8233265: jpackage --add-modules cannot find additional
 modules with non-modular app
Message-ID: <b5a96396-eefa-aa68-cdac-7af9d2223b78@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

This is a fixes a regression from the fix to JDK-8231882 
<https://bugs.openjdk.java.net/browse/JDK-8231882> and improves behavior 
when module listed is not in the module path.

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

[2] http://cr.openjdk.java.net/~herrick/8233265/

/Andy


From kevin.rushforth at oracle.com  Thu Oct 31 21:12:30 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 31 Oct 2019 14:12:30 -0700
Subject: RFR: JDK-8233265: jpackage --add-modules cannot find additional
 modules with non-modular app
In-Reply-To: <b5a96396-eefa-aa68-cdac-7af9d2223b78@oracle.com>
References: <b5a96396-eefa-aa68-cdac-7af9d2223b78@oracle.com>
Message-ID: <c273c2c1-9379-410c-efd0-452abeb6e23e@oracle.com>

Looks good.

-- Kevin


On 10/31/2019 2:02 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This is a fixes a regression from the fix to JDK-8231882 
> <https://bugs.openjdk.java.net/browse/JDK-8231882> and improves 
> behavior when module listed is not in the module path.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233265
>
> [2] http://cr.openjdk.java.net/~herrick/8233265/
>
> /Andy
>


From andy.herrick at oracle.com  Thu Oct 31 21:13:57 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 31 Oct 2019 17:13:57 -0400
Subject: RFR: JDK-8233333: Incorrect comparison of number version strings
 in ToolValidator
In-Reply-To: <d5329cc7-ef2f-938b-14ee-b0526f89b364@oracle.com>
References: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
 <d5329cc7-ef2f-938b-14ee-b0526f89b364@oracle.com>
Message-ID: <c5494971-c7d5-31c2-387a-1e7a5866be0d@oracle.com>

looks good.

/Andy

On 10/31/2019 3:11 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally:
> - fixed issue with truncated log output of jtreg tests (added 
> maxOutputSize=2000000 to TEST.properties)
> - fixed issue in code looking up for WiX Toolkit when environment 
> variables are not set
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233333
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233333/webrev.00
>

From alexey.semenyuk at oracle.com  Thu Oct 31 21:31:39 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 31 Oct 2019 17:31:39 -0400
Subject: RFR: JDK-8233265: jpackage --add-modules cannot find additional
 modules with non-modular app
In-Reply-To: <b5a96396-eefa-aa68-cdac-7af9d2223b78@oracle.com>
References: <b5a96396-eefa-aa68-cdac-7af9d2223b78@oracle.com>
Message-ID: <21f06f04-2532-cfe9-9acd-2d4d6d5efd9b@oracle.com>

Looks good.

- Alexey

On 10/31/2019 5:02 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This is a fixes a regression from the fix to JDK-8231882 
> <https://bugs.openjdk.java.net/browse/JDK-8231882> and improves 
> behavior when module listed is not in the module path.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233265
>
> [2] http://cr.openjdk.java.net/~herrick/8233265/
>
> /Andy
>


From alexander.matveev at oracle.com  Thu Oct 31 21:39:51 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 31 Oct 2019 14:39:51 -0700
Subject: RFR: JDK-8233333: Incorrect comparison of number version strings
 in ToolValidator
In-Reply-To: <d5329cc7-ef2f-938b-14ee-b0526f89b364@oracle.com>
References: <5240277e-b7fc-69c6-1dec-6044a9b70b07@oracle.com>
 <d5329cc7-ef2f-938b-14ee-b0526f89b364@oracle.com>
Message-ID: <efc143ef-8231-8b63-1b1e-9c3bef8b5666@oracle.com>

Looks good.

On 10/31/2019 12:11 PM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> Additionally:
> - fixed issue with truncated log output of jtreg tests (added 
> maxOutputSize=2000000 to TEST.properties)
> - fixed issue in code looking up for WiX Toolkit when environment 
> variables are not set
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233333
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8233333/webrev.00
>


From alexander.matveev at oracle.com  Thu Oct 31 21:55:12 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 31 Oct 2019 14:55:12 -0700
Subject: RFR: JDK-8233265: jpackage --add-modules cannot find additional
 modules with non-modular app
In-Reply-To: <b5a96396-eefa-aa68-cdac-7af9d2223b78@oracle.com>
References: <b5a96396-eefa-aa68-cdac-7af9d2223b78@oracle.com>
Message-ID: <b1b11edc-10e8-43be-6713-999f33eb84a9@oracle.com>

Looks good.

On 10/31/2019 2:02 PM, Andy Herrick wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This is a fixes a regression from the fix to JDK-8231882 
> <https://bugs.openjdk.java.net/browse/JDK-8231882> and improves 
> behavior when module listed is not in the module path.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233265
>
> [2] http://cr.openjdk.java.net/~herrick/8233265/
>
> /Andy
>


From brent.christian at oracle.com  Thu Oct 31 22:50:01 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 31 Oct 2019 15:50:01 -0700
Subject: RFR 8233091 : Backout JDK-8212117: Class.forName loads a class but
 not linked if class is not initialized
Message-ID: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com>

Hi,

Please review my change to backout JDK-8212117:
http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/

Background:

A couple months ago, JDK-8212117[1] was fixed[2].  It changed the 
behavior of the 2-arg and 3-arg Class.forName methods to ensure that 
linking is performed.  This conforms to the specification[3], which 
states that the method "attempts to locate, load, and link the class". 
In the process, 8181144[7] was also resolved.

It was acknowledged that new LinkageErrors could be introduced as a 
result - for instance, in cases where Class.forName() loads, but never 
uses, an unlinkable class.  Such uncovered errors would need to be fixed.

Well, after a few promoted builds with the JDK-8212117 change, it looks 
like new LinkageErrors will be more widespread than anticipated 
(JDK-8231924[4], for example).  This change to long-standing behavior 
would cause too great an incompatibility.  (See Mandy's comment[5] for 
more.)

So the proposal is to revert the JDK-8212117 change, along with a couple 
follow-up tasks:

* Update the Class::forName API spec to match the long-standing behavior 
(i.e. no linking if initialize=false) - JDK-8233272 [6]

* Reopen JDK-8181144[7] for further investigation of JDI 
VirtualMachine::allClasses and JVM TI AllLoadedClasses

Thanks,
-Brent

==============
1. https://bugs.openjdk.java.net/browse/JDK-8212117

2. 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062142.html

3. 
https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)

4. https://bugs.openjdk.java.net/browse/JDK-8231924

5. 
https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14297501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297501

6. https://bugs.openjdk.java.net/browse/JDK-8233272

7. https://bugs.openjdk.java.net/browse/JDK-8181144



From david.holmes at oracle.com  Thu Oct 31 23:04:33 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 1 Nov 2019 09:04:33 +1000
Subject: RFR 8233091 : Backout JDK-8212117: Class.forName loads a class
 but not linked if class is not initialized
In-Reply-To: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com>
References: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com>
Message-ID: <748167a8-e763-387e-4508-bae371137de2@oracle.com>

Hi Brent,

This looks like an accurate backout to me.

Thanks,
David
-----

On 1/11/2019 8:50 am, Brent Christian wrote:
> Hi,
> 
> Please review my change to backout JDK-8212117:
> http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/
> 
> Background:
> 
> A couple months ago, JDK-8212117[1] was fixed[2].? It changed the 
> behavior of the 2-arg and 3-arg Class.forName methods to ensure that 
> linking is performed.? This conforms to the specification[3], which 
> states that the method "attempts to locate, load, and link the class". 
> In the process, 8181144[7] was also resolved.
> 
> It was acknowledged that new LinkageErrors could be introduced as a 
> result - for instance, in cases where Class.forName() loads, but never 
> uses, an unlinkable class.? Such uncovered errors would need to be fixed.
> 
> Well, after a few promoted builds with the JDK-8212117 change, it looks 
> like new LinkageErrors will be more widespread than anticipated 
> (JDK-8231924[4], for example).? This change to long-standing behavior 
> would cause too great an incompatibility.? (See Mandy's comment[5] for 
> more.)
> 
> So the proposal is to revert the JDK-8212117 change, along with a couple 
> follow-up tasks:
> 
> * Update the Class::forName API spec to match the long-standing behavior 
> (i.e. no linking if initialize=false) - JDK-8233272 [6]
> 
> * Reopen JDK-8181144[7] for further investigation of JDI 
> VirtualMachine::allClasses and JVM TI AllLoadedClasses
> 
> Thanks,
> -Brent
> 
> ==============
> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
> 
> 2. 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062142.html 
> 
> 
> 3. 
> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader) 
> 
> 
> 4. https://bugs.openjdk.java.net/browse/JDK-8231924
> 
> 5. 
> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14297501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297501 
> 
> 
> 6. https://bugs.openjdk.java.net/browse/JDK-8233272
> 
> 7. https://bugs.openjdk.java.net/browse/JDK-8181144
> 
> 

From mandy.chung at oracle.com  Thu Oct 31 23:20:51 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 31 Oct 2019 16:20:51 -0700
Subject: RFR 8233091 : Backout JDK-8212117: Class.forName loads a class
 but not linked if class is not initialized
In-Reply-To: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com>
References: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com>
Message-ID: <67aa28d7-4d1c-f886-c909-2cdbdf3a536f@oracle.com>

This looks good to me.

Mandy

On 10/31/19 3:50 PM, Brent Christian wrote:
> Hi,
>
> Please review my change to backout JDK-8212117:
> http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/
>
> Background:
>
> A couple months ago, JDK-8212117[1] was fixed[2].? It changed the 
> behavior of the 2-arg and 3-arg Class.forName methods to ensure that 
> linking is performed.? This conforms to the specification[3], which 
> states that the method "attempts to locate, load, and link the class". 
> In the process, 8181144[7] was also resolved.
>
> It was acknowledged that new LinkageErrors could be introduced as a 
> result - for instance, in cases where Class.forName() loads, but never 
> uses, an unlinkable class.? Such uncovered errors would need to be fixed.
>
> Well, after a few promoted builds with the JDK-8212117 change, it 
> looks like new LinkageErrors will be more widespread than anticipated 
> (JDK-8231924[4], for example).? This change to long-standing behavior 
> would cause too great an incompatibility. (See Mandy's comment[5] for 
> more.)
>
> So the proposal is to revert the JDK-8212117 change, along with a 
> couple follow-up tasks:
>
> * Update the Class::forName API spec to match the long-standing 
> behavior (i.e. no linking if initialize=false) - JDK-8233272 [6]
>
> * Reopen JDK-8181144[7] for further investigation of JDI 
> VirtualMachine::allClasses and JVM TI AllLoadedClasses
>
> Thanks,
> -Brent
>
> ==============
> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>
> 2. 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062142.html
>
> 3. 
> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)
>
> 4. https://bugs.openjdk.java.net/browse/JDK-8231924
>
> 5. 
> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14297501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297501
>
> 6. https://bugs.openjdk.java.net/browse/JDK-8233272
>
> 7. https://bugs.openjdk.java.net/browse/JDK-8181144
>
>