Re: RFR 8223174 : Pattern.compile() can throw confusing NegativeArraySizeException

2019-05-03 Thread Martin Buchholz
OK, sounds reasonable! On Fri, May 3, 2019 at 6:32 PM Ivan Gerasimov wrote: > Thank you Martin for review! > > On 5/3/19 6:05 PM, Martin Buchholz wrote: > > Test should check that Pattern.compile does not return normally, e.g. by > throwing AssertionError. Otherwise LGTM. > > Well. I think,

Re: RFR 8223174 : Pattern.compile() can throw confusing NegativeArraySizeException

2019-05-03 Thread Ivan Gerasimov
Thank you Martin for review! On 5/3/19 6:05 PM, Martin Buchholz wrote: Test should check that Pattern.compile does not return normally, e.g. by throwing AssertionError. Otherwise LGTM. Well. I think, that OOM in this scenario is a limitation of the current implementation. If the

Re: RFR 8223174 : Pattern.compile() can throw confusing NegativeArraySizeException

2019-05-03 Thread Martin Buchholz
Test should check that Pattern.compile does not return normally, e.g. by throwing AssertionError. Otherwise LGTM. On Fri, May 3, 2019 at 5:54 PM Ivan Gerasimov wrote: > Hello! > > A private method Pattern. RemoveQEQuoting() contains calculation of an > array size, which can result in numeric

RFR 8223174 : Pattern.compile() can throw confusing NegativeArraySizeException

2019-05-03 Thread Ivan Gerasimov
Hello! A private method Pattern. RemoveQEQuoting() contains calculation of an array size, which can result in numeric overflow, and cause a confusing NegativeArraySizeException. Would you please help review the fix? Please note, that expressions `j + 2` and `pLen - i` cannot overflow

Re: RFR: 8222819: Remove setting of headless property on MacOS from launcher code.

2019-05-03 Thread Sergey Bylokhov
+1 On 03/05/2019 11:21, Roger Riggs wrote: Hi Phil, Looks good, thanks for the cleanup. Roger On 05/03/2019 02:08 PM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8222819 Webrev: http://cr.openjdk.java.net/~prr/8222819/ After fixing

Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods

2019-05-03 Thread Alan Bateman
On 01/05/2019 21:48, Joe Darcy wrote: I'd prefer to push a version without the explicit map variable, but the max line length is slightly longer:   * - *   MapString,String env = new HashMap(); - *   env.put("capacity", "16G"); - *   env.put("blockSize", "4k"); - *  

Re: RFR: JDK-8223318: jpackage --mac-bundle-name option doesn't work

2019-05-03 Thread Andy Herrick
Semyon: This webrev also includes your fix for 8223038 (http://cr.openjdk.java.net/~ssadetsky/8223038/). Both fixes look good, but should wait till after JEP is targeted. /Andy On 5/3/2019 3:08 PM, semyon.sadet...@oracle.com wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8223318

RFR: JDK-8223318: jpackage --mac-bundle-name option doesn't work

2019-05-03 Thread semyon . sadetsky
bug: https://bugs.openjdk.java.net/browse/JDK-8223318 webrev: http://cr.openjdk.java.net/~ssadetsky/8223318/webrev.00/ The fix adds reading of --mac-bundle-name option to the application image builder. --Semyon

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Andy Herrick
looks good. /Andy On 5/3/2019 2:08 PM, Kevin Rushforth wrote: Here is the webrev to document the threading limitation: https://bugs.openjdk.java.net/browse/JDK-8223321 http://cr.openjdk.java.net/~kcr/8223321/webrev.00/ Once reviewed, Andy can include this in the next version of the webrev

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Kevin Rushforth
OK, thanks. -- Kevin On 5/3/2019 11:31 AM, Roger Riggs wrote: Hi Kevin, I'm fine with the disclaimer; undefined behavior is fine. Thanks, Roger p.s. synchronizing the run method would prevent filing of issues when someone does it anyway, keeping the noise to a minimum. On 05/03/2019 02:08

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Phil Race
Looks good to me. We can live with this limitation for a little while, since there aren't exactly thousands of users who will need to run this concurrently. And concurrent use of the command line tool - ie using separate VMs works fine - per Kevin. But we do need to get to it. -phil. On

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Roger Riggs
Hi Kevin, I'm fine with the disclaimer; undefined behavior is fine. Thanks, Roger p.s. synchronizing the run method would prevent filing of issues when someone does it anyway, keeping the noise to a minimum. On 05/03/2019 02:08 PM, Kevin Rushforth wrote: Here is the webrev to document the

Re: RFR: 8222819: Remove setting of headless property on MacOS from launcher code.

2019-05-03 Thread Roger Riggs
Hi Phil, Looks good, thanks for the cleanup. Roger On 05/03/2019 02:08 PM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8222819 Webrev: http://cr.openjdk.java.net/~prr/8222819/ After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code in the launcher which

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Kevin Rushforth
Here is the webrev to document the threading limitation: https://bugs.openjdk.java.net/browse/JDK-8223321 http://cr.openjdk.java.net/~kcr/8223321/webrev.00/ Once reviewed, Andy can include this in the next version of the webrev (and we'll update the CSR). -- Kevin On 5/3/2019 10:23 AM,

RFR: 8222819: Remove setting of headless property on MacOS from launcher code.

2019-05-03 Thread Phil Race
Bug: https://bugs.openjdk.java.net/browse/JDK-8222819 Webrev: http://cr.openjdk.java.net/~prr/8222819/ After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code in the launcher which sets the java.awt.headless property on MacOS is defunct since the java.desktop module figures it

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Alexey Semenyuk
Andy, I've created the following CRs to track the findings: https://bugs.openjdk.java.net/browse/JDK-8223325 https://bugs.openjdk.java.net/browse/JDK-8223323 - Alexey On 5/2/2019 5:08 PM, Andy Herrick wrote: Alexey: Please file Bugs for these two issues. /Andy On 5/2/2019 1:49 PM, Alexey

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Kevin Rushforth
Thanks for your feedback. I filed two issues [1][2] for the thread concurrency issue. The first one needs to be solved for JDK 13, which is to either document the existing limitation (which is probably what we'll do) or serialize access by synchronizing on the JPackageToolProvider class (or,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Kevin Rushforth
Thanks for your feedback. I filed two issues [1][2] for the thread concurrency issue. The first one needs to be solved for JDK 13, which is to either document the existing limitation (which is probably what we'll do) or serialize access by synchronizing on the JPackageToolProvider class (or,

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Alexey Semenyuk
Hi Scott, I agree this a good option. Though we still need to create some custom wix source code for shortcuts, so we can't get rid completely of Java code generating wix sources. - Alexey On 5/2/2019 8:54 PM, Scott Palmer wrote: Ideally the wix code should be generated by running the

Re: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

2019-05-03 Thread Tagir Valeev
I'm not a reviewer, but strongly support this change. Simpler is better. Thanks! With best regards, Tagir Valeev. пт, 3 мая 2019 г., 7:37 Stuart Marks : > Hi all, > > Please review these spec and implementation changes to remove the > "optimization" > to AbstractSet.removeAll. Briefly, this

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

2019-05-03 Thread Kevin Rushforth
Hi Alexander, I'll file cleanup issues (or add to existing bugs) for the rest. Thanks. -- Kevin On 5/2/2019 6:33 PM, Alexander Matveev wrote: Hi Kevin, See below. On 5/2/2019 5:38 PM, Kevin Rushforth wrote: Here are a few follow-on comments. As with my earlier comments, none of these

Re: JDK 13 RFR of JDK-8223112: Clarify operational semantics of java.util.Objects.equals()

2019-05-03 Thread Alan Bateman
On 02/05/2019 22:42, Joe Darcy wrote: : I don't think code should be added to Objects.equals itself to guard against this case. Instead, I think the operational semantics of the implementation should be made explicit in the specification. I agree, I think the proposed clarification and the