Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

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:

Re: RFR: JDK-8231706: Investigate if we can change "Java" dir to "app" dir in jpackage app image

Please remove “investigate” from the synopsis. Everywhere. -Phil. > On Oct 2, 2019, at 7:48 PM, Alexey Semenyuk > 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

Re: RFR: JDK-8231706: Investigate if we can change "Java" dir to "app" dir in jpackage app image

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]

RFR: JDK-8231706: Investigate if we can change "Java" dir to "app" dir in jpackage app image

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]

JDK 14 RFR of JDK-8231777: Remove extraneous @serial javadoc tag in NodeChangeEvent.java

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.

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

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

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

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:

jpackage: Build 14-jpackage+1-49 (2019/10/2)

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 option isn't working on Windows 10 unless

Re: RFR: 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call

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

Re: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

2019/10/2 5:45:10 -0700, goetz.lindenma...@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

RFR: JDK-8215895: Verify and create tests for Mac installer specific signing options

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

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

Re: Comments on jpackage (JEP 343)

ons. 2. okt. 2019 kl. 19:14 skrev Alexey Semenyuk < alexey.semen...@oracle.com>: > > > On 10/2/2019 12:33 PM, Sverre Moe wrote: > > ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk < > alexey.semen...@oracle.com>: > >> Hi Sverre, >> >> Thank you for doing this research. I don't think we should

Re: Comments on jpackage (JEP 343)

On 10/2/2019 12:33 PM, Sverre Moe wrote: ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk mailto:alexey.semen...@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

RE: 8231663: Incorrect GPL header in some RMI/SQL package-info.java files

Hi, Roger. http://cr.openjdk.java.net/~rriggs/webrev-header-cleanup-8231663/ +1 Thanks, Iris

Re: RFR: 8231717: Improve performance of EBCDIC charset decoding for COMPACT_STRINGS

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

Re: Comments on jpackage (JEP 343)

ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk < alexey.semen...@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

Re: 8231663: Incorrect GPL header in some RMI/SQL package-info.java files

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

Jpackage EA build available

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"

Re: 8231663: Incorrect GPL header in some RMI/SQL package-info.java files

Hi Roger, +1 Brian > On Oct 2, 2019, at 7:53 AM, Roger Riggs wrote: > > Please review a few trivial changes in rmi and sql to remove extraneous > tags. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-header-cleanup-8231663/ > > Issue: >

8231663: Incorrect GPL header in some RMI/SQL package-info.java files

Please review a few trivial changes in rmi and sql to remove extraneous tags. Webrev:   http://cr.openjdk.java.net/~rriggs/webrev-header-cleanup-8231663/ Issue:   https://bugs.openjdk.java.net/browse/JDK-8231663 Thanks, Roger

Re: Comments on jpackage (JEP 343)

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

Re: RFR: 8231717: Improve performance of EBCDIC charset decoding for COMPACT_STRINGS

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

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

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

Re: Comments on jpackage (JEP 343)

ons. 25. sep. 2019 kl. 15:45 skrev Sverre Moe : > 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

RE: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

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.

Re: RFR (XS): 8231161: Wrong return type in code sample in Collector API documentation

Hi Julia, This looks good. Best Lance > On Oct 2, 2019, at 5:36 AM, Julia Boes 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

Re: 8229022: BufferedReader performance can be improved by using StringBuilder

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

RFR (XS): 8231161: Wrong return type in code sample in Collector API documentation

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:

RFR: 8231717: Improve performance of EBCDIC charset decoding for COMPACT_STRINGS

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