Re: Proposal to enhance Stream.collect

Hello! > A less intrusive API direction might be a version of Collector whose > supplier function took a size-estimate argument; this might even help in > parallel since it allows for intermediate results to start with a better > initial size guess. (And this could be implemented as a default

RFR: JDK-8219144 : Cannot find installed application on Mac

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). By default pkgbuild generates package with BundleIsRelocatable set to true, which means if an application already exist on system (installed,

Re: RFR: JDK-8217902: jpackage fails with --app-image option on mac

Hi Andy, http://cr.openjdk.java.net/~herrick/8217902/webrev.01/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinAppBundler.java.frames.html Line 135 - Did you mean to put error message in else statement before throwing exception? Otherwise looks fine. Thanks, Alexander On 2/26/2019

[JDK 13] RFR 8219802: Problem list java/net/MulticastSocket/SetGetNetworkInterfaceTest.java

java/net/MulticastSocket/SetGetNetworkInterfaceTest.java Test fails due to JDK-8219083 (failures observed on windows-x64) and should be problem listed before mentioned issue fixed. Please review the patch. bug: https://bugs.openjdk.java.net/browse/JDK-8219802 Thanks, Amy ---

Re: RFR: JDK-8191709 : javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code

The comparison isn't quite right. It will fail if either the major or minor is less than the minimum. This means, for example, that 4.1 will be considered less than 3.6. -- Kevin On 2/26/2019 3:25 PM, Alexander Matveev wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix

RFR: JDK-8191709 : javapackager detects WiX 3.10 as 3.1 and fails to use WiX 3.6+ compatible code

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). - Problem was in how we compare versions. We used to compare it as float number, so 3.10 -> 3.1 which was less then 3.6. - Fixed by comparing major

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

Hi Dmitry, This seems fine to me too - much simpler. Thanks, David On 27/02/2019 6:23 am, Dmitry Chuyko wrote: I made mentioned cleanups in changed code, just in case here is a webrev without functional changes: function renaming, comments, indents (just a couple), void*.

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

I made mentioned cleanups in changed code, just in case here is a webrev without functional changes: function renaming, comments, indents (just a couple), void*. http://cr.openjdk.java.net/~dchuyko/8215009/webrev.04/ Started dev-submit for that patch. -Dmitry On 2/25/19 9:37 PM, Roger Riggs

Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

Hi Andrew, Thanks for verifying the suggested patch.  I created https://bugs.openjdk.java.net/browse/JDK-8219774 to follow up this. Mandy On 2/26/19 8:46 AM, Andrew Leonard wrote: Hi Mandy, I think your last proposal sounds a good plan, push 8219378 to fix the immediate issue and create a

Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

On 2/26/19 8:56 AM, Roger Riggs wrote: Hi Andrew, I've got the changeset you sent earlier and have tested it as well. I'll push it today unless there any objections. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reflectionfactory-8219378-2/ +1 Mandy Roger On 02/26/2019 11:46

Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

Hi Andrew, I've got the changeset you sent earlier and have tested it as well. I'll push it today unless there any objections. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reflectionfactory-8219378-2/ Roger On 02/26/2019 11:46 AM, Andrew Leonard wrote: Hi Mandy, I think your last

Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

Hi Mandy, I think your last proposal sounds a good plan, push 8219378 to fix the immediate issue and create a new change to refactor the clinit location... As I am not a "Committer" (yet! working on it!) I can't use the Submit repo. I have built your patch and run a bunch of tests locally and it

Re: RFR: JDK-8219695: Use a copy of javac's implementation of @argfile in jpackager

Hi, The copyright in CommandLine.java should be 2019, the package declaration changed, though probably nothing else. $.02, Roger On 02/26/2019 08:35 AM, Kevin Rushforth wrote: Looks good to me. -- Kevin On 2/26/2019 5:20 AM, Andy Herrick wrote: Please review the jpackage fix for bug

Re: RFR: JDK-8219695: Use a copy of javac's implementation of @argfile in jpackager

Looks good to me. -- Kevin On 2/26/2019 5:20 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). The fix is to include the code for processing @argfile from javac into

RFR: JDK-8219695: Use a copy of javac's implementation of @argfile in jpackager

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). The fix is to include the code for processing @argfile from javac into jpackage. [1] https://bugs.openjdk.java.net/browse/JDK-8219695 [2]

RFR: JDK-8217902: jpackage fails with --app-image option on mac

 JDK-8217902: jpackage fails with --app-image option on mac 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). The fix is to remove the over-aggressive validation in DeployParams.validate() and update