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

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 need to be addressed prior to integration. 1. I found a few more classes that do I/O and could benefit from using try-with-resources:    IOUtils, Li

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

Hi all, Please review these spec and implementation changes to remove the "optimization" to AbstractSet.removeAll. Briefly, this method was specified (and implemented) to iterate one collection or the other depending on the relative sizes of the collections. The problem is that this would caus

Re: jpackage producing non-working binaries on Windows

Hi Kevin, Aha! That explains it, and yes, adding that flag fixes the issue. Thanks! The only documentation i have seen is this: https://openjdk.java.net/jeps/343 And while that does mention this flag, the mention is deep in the section describing all the flags, which i have to confess i did n

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

Ideally the wix code should be generated by running the heat.exe tool on the application image. Scott > On May 2, 2019, at 5:08 PM, Andy Herrick wrote: > > Alexey: > > Please file Bugs for these two issues. > > /Andy > > >> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: >> Some findings: >>

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

Here are a few follow-on comments. As with my earlier comments, none of these need to be addressed prior to integration. 1. I found a few more classes that do I/O and could benefit from using try-with-resources:    IOUtils, LinuxAppImageBuilder, LinuxDebBundler, LinuxRpmBundler, MacAppImageBu

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

PS Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8223265 Note that the particular implementation used in Objects.equals was recommended in its initial code review back in 2009: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-September/002580.html Thanks,

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

Hi Joe, Looks good. Brian > On May 2, 2019, at 2:42 PM, Joe Darcy wrote: > > Bug JDK-8223112 notes indirectly that if Objects.equals is called with (foo, > null) and foo has a buggy equals method that returns true for null, the wrong > result will be computed. > > I don't think code should

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

Hello, Bug JDK-8223112 notes indirectly that if Objects.equals is called with (foo, null) and foo has a buggy equals method that returns true for null, the wrong result will be computed. I don't think code should be added to Objects.equals itself to guard against this case. Instead, I think

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

Alexey: Please file Bugs for these two issues. /Andy On 5/2/2019 1:49 PM, Alexey Semenyuk wrote: Some findings: http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPAC

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

JDK-8223264 has been filed to address this. /Andy On 5/2/2019 2:25 PM, Phil Race wrote: Although our build system doesn't complain, my local Linux gcc generates several warnings which prevent jpackage from building. The attached patch makes

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

Semyon: Although we removed --mac-app-store-entitlements and --mac-app-store-category options from help text, and disabled the mac-app-store target (so these two options have no effect) when we decided to drop support for this in the the initial release, we never actually removed the options,

Re: 8223254: DataOutputStream/WriteUTF.java fails due to "OutOfMemoryError: Java heap space"

+1 2nd time is a charm :-) > On May 2, 2019, at 3:24 PM, Brian Burkhalter > wrote: > > It looks like the memory bump in [1, 2] was not enough. This patch [3] would > add 1GB to the required Java heap size. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8221568 > [2]

Re: 8223254: DataOutputStream/WriteUTF.java fails due to "OutOfMemoryError: Java heap space"

ok,  +1 On 05/02/2019 03:24 PM, Brian Burkhalter wrote: It looks like the memory bump in [1, 2] was not enough. This patch [3] would add 1GB to the required Java heap size. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8221568 [2] http://mail.openjdk.java.net/pipermail/core-libs

8223254: DataOutputStream/WriteUTF.java fails due to "OutOfMemoryError: Java heap space"

It looks like the memory bump in [1, 2] was not enough. This patch [3] would add 1GB to the required Java heap size. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8221568 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059355.html [3] patch --- a/test/jdk/java/

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

Although our build system doesn't complain, my local Linux gcc generates several warnings which prevent jpackage from building. The attached patch makes it happy. There are several of these :- jpackage/open/src/jdk.jpackage/share/native/libapplauncher/IniFile.cpp: In member function ‘virtual

Re: jpackage producing non-working binaries on Windows

Hi Alexey, Here is a demo project: https://github.com/tomwhoiscontrary/jpackage-demo If i run this on Windows (Windows 10 in a VM), it produces this output: https://gist.github.com/tomwhoiscontrary/ee33dda3c124d8a67bd5bba5b8d5e32d Which includes the following command line: [create-app-image,

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

Some findings: http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/

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

The --mac-app-store-entitlements option was only used for the Mac App Store deployment. Since it is not supported anymore this option is not used anywhere and need to be removed. Also the jdk.jpackage.internal. MacAppStoreBundler class and related resources are the dead code. --Semyon On 4/

Re: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null

thanks, Vicente On 5/1/19 6:47 PM, Joseph D. Darcy wrote: Hi Vicente, Revised version looks good; thanks, -Joe On 5/1/2019 1:08 PM, Vicente Romero wrote: Hi Joe, Thanks for the reviews, I have updated the webrev after you suggestion [1], Vicente [1] http://cr.openjdk.java.net/~vromero/

Re: jpackage producing non-working binaries on Windows

You need to run jpackage the "--win-console" option in order to get a console app. This is intentional and documented. -- Kevin On 5/2/2019 9:19 AM, Alexey Semenyuk wrote: Hi Tom, Thank for providing a reference to the demo project and build output. In your example you use jpackage to produ

Re: jpackage producing non-working binaries on Windows

Hi Tom, Thank for providing a reference to the demo project and build output. In your example you use jpackage to produce an application image, not an exe or msi installers. Just to be clear on the test scenario. Test app prints "Hello, world!" to stdout as far as I can tell from https://git

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

Hi, Some comments, a initial batch... Having support for the ToolProvider is great. However, there is no indication about whether it is valid to use it from multiple threads. The implementation is structured to be deliberately single thread use only with the invocation being via a static metho

Re: RFR: jsr166 integration 2019-05

Thanks Martin. :) Best Regards Adam Farley IBM Runtimes Martin Buchholz wrote on 02/05/2019 15:14:32: > From: Martin Buchholz > To: Adam Farley8 > Cc: David Holmes , Chris Hegarty > , core-libs-dev d...@openjdk.java.net>, Doug Lea , Jonathan Gibbons > > Date: 02/05/2019 15:14 > Subject:

Re: RFR: jsr166 integration 2019-05

Changes were pushed (except of course for 203662: remove increment of modCount from ArrayList and Vector replaceAll() Adam, Nothing more for you to do here. I will shepherd the fix for 8222930: ConcurrentSkipListMap.clone() shares size variable between original and clone into jdk12u and jdk11u

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

I filed JDK-8223241 to address each of these issues, and included import statement wildcard usage as suggested (removing it from JDK-8223189 ) /Andy On 5/1/2019 7:17 PM, Kevin Rushforth wrote

Re: RFR: 8222895: StackOverflowError in custom security manager that relies on ClassSpecializer

On 2019-05-01 19:00, Alan Bateman wrote: Webrev: http://cr.openjdk.java.net/~redestad/8222895/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222895 This looks okay as a temporary solution to fix the regression. Thanks Alan! Yes, using the shared secrets API for this is a bit of a ha