Re: jpackager
Hi Scott, thank you for you answer and explainationr, I did another test the weekend, with a JFrame Window and this is shown. Thomas Am 16.12.2019 um 02:46 schrieb Scott Palmer: Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas
Re: jpackager
I 've tried with the recommended jpackage from JDK14 EA. The syntax has slightly changed, with the option --win-console it now shows the output as expected: > .\test01.exe Dec 16, 2019 6:41:01 PM simpleapp.SimpleApp main INFO: SimpleApp says hello Thomas Am 16.12.2019 um 15:14 schrieb Andy Herrick: That was my initial reaction too, but I don't believe that is the problem here. The arguments to jpackage used indicate you are using an older early access version of jpackage. Can you try again using the jpackage in the latest JDK14 EA from https://jdk.java.net/14/ ? /Andy On 12/15/2019 8:46 PM, Scott Palmer wrote: Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas
Re: jpackager
Thank you, yes. In fact I'm packaging a GUI Application, I was just having a first try with a simple console application. Thomas Am 16.12.2019 um 16:05 schrieb Schnoor Jonas: Notice the different naming: jpackage*r* vs. jpackage (without the trailing *r*). The primary purpose of JPackage*r* seems to be to package JavaFX (read: GUI) applications and AFAIK is a backport by GluonHQ of an EA version of JPackage that probably did not yet have the --win-console option. If you want to package a Windows console application you will have to use JPackage from JDK14 with the --win-console option. Jonas -Ursprüngliche Nachricht- Von: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] Im Auftrag von Thomas Vatter Gesendet: Montag, 16. Dezember 2019 15:44 An: core-libs-dev@openjdk.java.net Betreff: Re: jpackager I first read on https://openjdk.java.net/jeps/343 Then I was looking for the download and somewhere found the links http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip Since I'm on windows with OpenJDK11 installed I downloaded http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip and extracted it to the JDK bin directory. Running it from the command line with the --version option gives > jpackager.exe --version "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin\java.exe" -Xmx512M --module-path "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin" --add-opens jdk.jlink/jdk.tools.jlink.internal.packager=jdk.packager -m jdk.packager/jdk.packager.Main "--version"jpackager version 11 Thomas Am 16.12.2019 um 15:14 schrieb Andy Herrick: That was my initial reaction too, but I don't believe that is the problem here. The arguments to jpackage used indicate you are using an older early access version of jpackage. Can you try again using the jpackage in the latest JDK14 EA from https://jdk.java.net/14/ ? /Andy On 12/15/2019 8:46 PM, Scott Palmer wrote: Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas Please see our data privacy policy: https://www.scheidt-bachmann.de/en/data-privacy/ Important Notice: This E-Mail and any files attached are confidential and may contain privileged information. If you are not the intended recipient, do not forward or disclose this E-Mail, open any attachments, make any copies or save this E-Mail anywhere. Please delete this E-Mail from your system and notify the sender (as applicable also by phone +49 2166 266-0). Thank you very much. To send this email we must process the following personal data: Your email address, first name and surname. Your data is processed solely for the purpose of sending this email and passed on to third parties only for this purpose. You have been included in the circle of recipients for our emails due to your professional, social or political position. If this position changes, or you inform us that you do not want to receive emails from us, or you object to the further processing of your data, we will delete your data and no longer use it.
AW: jpackager
Notice the different naming: jpackage*r* vs. jpackage (without the trailing *r*). The primary purpose of JPackage*r* seems to be to package JavaFX (read: GUI) applications and AFAIK is a backport by GluonHQ of an EA version of JPackage that probably did not yet have the --win-console option. If you want to package a Windows console application you will have to use JPackage from JDK14 with the --win-console option. Jonas -Ursprüngliche Nachricht- Von: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] Im Auftrag von Thomas Vatter Gesendet: Montag, 16. Dezember 2019 15:44 An: core-libs-dev@openjdk.java.net Betreff: Re: jpackager I first read on https://openjdk.java.net/jeps/343 Then I was looking for the download and somewhere found the links http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip Since I'm on windows with OpenJDK11 installed I downloaded http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip and extracted it to the JDK bin directory. Running it from the command line with the --version option gives > jpackager.exe --version "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin\java.exe" -Xmx512M --module-path "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin" --add-opens jdk.jlink/jdk.tools.jlink.internal.packager=jdk.packager -m jdk.packager/jdk.packager.Main "--version"jpackager version 11 Thomas Am 16.12.2019 um 15:14 schrieb Andy Herrick: > That was my initial reaction too, but I don't believe that is the > problem here. > > The arguments to jpackage used indicate you are using an older early > access version of jpackage. > > Can you try again using the jpackage in the latest JDK14 EA from > https://jdk.java.net/14/ ? > > /Andy > > On 12/15/2019 8:46 PM, Scott Palmer wrote: >> Welcome to Windows. >> >> The .exe is a Windows app not a Console app. This is a distinction >> that only Microsoft seemed to think was needed. All other platforms >> are sane. >> There is command line option to make a console app. >> >> --win-console >> >> >> Scott >> >> >> >>> On Dec 14, 2019, at 12:22 PM, Thomas Vatter >>> wrote: >>> >>> Hi, >>> >>> I've created a modular jar and jre image by jlink. >>> >>> I tested it with this command: >>> >>> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp >>> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main >>> INFO: SimpleApp says hello >>> >>> It says "SimpleApp says hello" in the powershell window. >>> >>> >>> Then I packaged it by >>> >>> jpackager.exe create-image --input dist --output jp_out --name test01 >>> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar >>> >>> This creates in the output folder a file structure with an exe file >>> in it. >>> >>> When I execute the exe file fron the powershell there is no error >>> message, but it doesn't say "SimpleApp says hello" any more. >>> >>> Is something wrong? >>> >>> regards >>> >>> Thomas >>> >>> >>> >>> >>> >>> > Please see our data privacy policy: https://www.scheidt-bachmann.de/en/data-privacy/ Important Notice: This E-Mail and any files attached are confidential and may contain privileged information. If you are not the intended recipient, do not forward or disclose this E-Mail, open any attachments, make any copies or save this E-Mail anywhere. Please delete this E-Mail from your system and notify the sender (as applicable also by phone +49 2166 266-0). Thank you very much. To send this email we must process the following personal data: Your email address, first name and surname. Your data is processed solely for the purpose of sending this email and passed on to third parties only for this purpose. You have been included in the circle of recipients for our emails due to your professional, social or political position. If this position changes, or you inform us that you do not want to receive emails from us, or you object to the further processing of your data, we will delete your data and no longer use it.
Re: jpackager
I first read on https://openjdk.java.net/jeps/343 Then I was looking for the download and somewhere found the links http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip Since I'm on windows with OpenJDK11 installed I downloaded http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip and extracted it to the JDK bin directory. Running it from the command line with the --version option gives > jpackager.exe --version "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin\java.exe" -Xmx512M --module-path "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin" --add-opens jdk.jlink/jdk.tools.jlink.internal.packager=jdk.packager -m jdk.packager/jdk.packager.Main "--version"jpackager version 11 Thomas Am 16.12.2019 um 15:14 schrieb Andy Herrick: That was my initial reaction too, but I don't believe that is the problem here. The arguments to jpackage used indicate you are using an older early access version of jpackage. Can you try again using the jpackage in the latest JDK14 EA from https://jdk.java.net/14/ ? /Andy On 12/15/2019 8:46 PM, Scott Palmer wrote: Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas
Re: jpackager
That was my initial reaction too, but I don't believe that is the problem here. The arguments to jpackage used indicate you are using an older early access version of jpackage. Can you try again using the jpackage in the latest JDK14 EA from https://jdk.java.net/14/ ? /Andy On 12/15/2019 8:46 PM, Scott Palmer wrote: Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas
Re: jpackager
Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott > On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: > > Hi, > > I've created a modular jar and jre image by jlink. > > I tested it with this command: > > PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp > Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main > INFO: SimpleApp says hello > > It says "SimpleApp says hello" in the powershell window. > > > Then I packaged it by > > jpackager.exe create-image --input dist --output jp_out --name test01 > --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar > > This creates in the output folder a file structure with an exe file in it. > > When I execute the exe file fron the powershell there is no error > message, but it doesn't say "SimpleApp says hello" any more. > > Is something wrong? > > regards > > Thomas > > > > > >
jpackager
Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas
Re: RFR: JDK-8231972: Build a stable list of jpackager tests for SQE
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/
Re: RFR: JDK-8231972: Build a stable list of jpackager tests for SQE
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/
RFR: JDK-8231972: Build a stable list of jpackager tests for SQE
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/
Re: RFR: JDK-8229334: JPackager .exe packages cannot be executed due to missing DLL
Looks good. On 8/9/2019 9:31 AM, 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). - Add build flag to statically link exe wrapper for msi files with MS runtime lib. [1] https://bugs.openjdk.java.net/browse/JDK-8229334 [2] http://cr.openjdk.java.net/~asemenyuk/8229334/webrev.00/ Thanks, Alexey
Re: RFR: JDK-8229334: JPackager .exe packages cannot be executed due to missing DLL
looks good. /Andy On 8/9/19 12:31 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). - Add build flag to statically link exe wrapper for msi files with MS runtime lib. [1] https://bugs.openjdk.java.net/browse/JDK-8229334 [2] http://cr.openjdk.java.net/~asemenyuk/8229334/webrev.00/ Thanks, Alexey
RFR: JDK-8229334: JPackager .exe packages cannot be executed due to missing DLL
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). - Add build flag to statically link exe wrapper for msi files with MS runtime lib. [1] https://bugs.openjdk.java.net/browse/JDK-8229334 [2] http://cr.openjdk.java.net/~asemenyuk/8229334/webrev.00/ Thanks, Alexey
Re: RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly
looks good /Andy On 6/28/2019 10:03 PM, Alexander Matveev wrote: Hi, http://cr.openjdk.java.net/~almatvee/8224486/webrev.01/ - Original fix was missing (not sure why) setting Java options map flag to allow duplicates. Without it fix does not work. See OrderedMap.h line 92 and 261 and Package.cpp. - Old loop is kept to avoid possible regression in case if we want to add values from OrderedMap which does not have duplicates flag set to true. Thanks, Alexander On 6/26/2019 7:21 AM, Andy Herrick wrote: then I'm fine with original fix. /Andy On 6/25/2019 6:08 PM, Alexander Matveev wrote: Hi Alexey, I cannot use index to get items from map. At least I did not figure it out how to do this. We need to use iterator when getting values from map. Thanks, Alexander On 6/25/2019 4:52 AM, Alexey Semenyuk wrote: In http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html, JavaOptions::AppendValues(), why do we need branching based on the result of Values.GetAllowDuplicates()? Why can't we use the same logic that was introduced by your patch to read values from the map in which duplicate keys are not allowed? - Alexey On 6/24/2019 9:18 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). - Duplicated Java options were not read correctly from OrderedMap, instead we read only unique from map. Fixed by reading duplicated Java options. [1] https://bugs.openjdk.java.net/browse/JDK-8224486 [2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/ Thanks, Alexander
Re: RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly
Hi, http://cr.openjdk.java.net/~almatvee/8224486/webrev.01/ - Original fix was missing (not sure why) setting Java options map flag to allow duplicates. Without it fix does not work. See OrderedMap.h line 92 and 261 and Package.cpp. - Old loop is kept to avoid possible regression in case if we want to add values from OrderedMap which does not have duplicates flag set to true. Thanks, Alexander On 6/26/2019 7:21 AM, Andy Herrick wrote: then I'm fine with original fix. /Andy On 6/25/2019 6:08 PM, Alexander Matveev wrote: Hi Alexey, I cannot use index to get items from map. At least I did not figure it out how to do this. We need to use iterator when getting values from map. Thanks, Alexander On 6/25/2019 4:52 AM, Alexey Semenyuk wrote: In http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html, JavaOptions::AppendValues(), why do we need branching based on the result of Values.GetAllowDuplicates()? Why can't we use the same logic that was introduced by your patch to read values from the map in which duplicate keys are not allowed? - Alexey On 6/24/2019 9:18 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). - Duplicated Java options were not read correctly from OrderedMap, instead we read only unique from map. Fixed by reading duplicated Java options. [1] https://bugs.openjdk.java.net/browse/JDK-8224486 [2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/ Thanks, Alexander
Re: RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly
then I'm fine with original fix. /Andy On 6/25/2019 6:08 PM, Alexander Matveev wrote: Hi Alexey, I cannot use index to get items from map. At least I did not figure it out how to do this. We need to use iterator when getting values from map. Thanks, Alexander On 6/25/2019 4:52 AM, Alexey Semenyuk wrote: In http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html, JavaOptions::AppendValues(), why do we need branching based on the result of Values.GetAllowDuplicates()? Why can't we use the same logic that was introduced by your patch to read values from the map in which duplicate keys are not allowed? - Alexey On 6/24/2019 9:18 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). - Duplicated Java options were not read correctly from OrderedMap, instead we read only unique from map. Fixed by reading duplicated Java options. [1] https://bugs.openjdk.java.net/browse/JDK-8224486 [2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/ Thanks, Alexander
Re: RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly
Hi Alexey, I cannot use index to get items from map. At least I did not figure it out how to do this. We need to use iterator when getting values from map. Thanks, Alexander On 6/25/2019 4:52 AM, Alexey Semenyuk wrote: In http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html, JavaOptions::AppendValues(), why do we need branching based on the result of Values.GetAllowDuplicates()? Why can't we use the same logic that was introduced by your patch to read values from the map in which duplicate keys are not allowed? - Alexey On 6/24/2019 9:18 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). - Duplicated Java options were not read correctly from OrderedMap, instead we read only unique from map. Fixed by reading duplicated Java options. [1] https://bugs.openjdk.java.net/browse/JDK-8224486 [2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/ Thanks, Alexander
Re: RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly
I'm fine with this either way. The ini file will have GetAllowDuplicates() true, but any OrderedMap that doesn't will have count of 1. /Andy On 6/25/2019 7:52 AM, Alexey Semenyuk wrote: In http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html, JavaOptions::AppendValues(), why do we need branching based on the result of Values.GetAllowDuplicates()? Why can't we use the same logic that was introduced by your patch to read values from the map in which duplicate keys are not allowed? - Alexey On 6/24/2019 9:18 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). - Duplicated Java options were not read correctly from OrderedMap, instead we read only unique from map. Fixed by reading duplicated Java options. [1] https://bugs.openjdk.java.net/browse/JDK-8224486 [2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/ Thanks, Alexander
Re: RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly
In http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html, JavaOptions::AppendValues(), why do we need branching based on the result of Values.GetAllowDuplicates()? Why can't we use the same logic that was introduced by your patch to read values from the map in which duplicate keys are not allowed? - Alexey On 6/24/2019 9:18 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). - Duplicated Java options were not read correctly from OrderedMap, instead we read only unique from map. Fixed by reading duplicated Java options. [1] https://bugs.openjdk.java.net/browse/JDK-8224486 [2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/ Thanks, Alexander
RFR: JDK-8224486: Arguments from jpackager cfg file not processed correctly
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). - Duplicated Java options were not read correctly from OrderedMap, instead we read only unique from map. Fixed by reading duplicated Java options. [1] https://bugs.openjdk.java.net/browse/JDK-8224486 [2] http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/ Thanks, Alexander
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 [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] http://cr.openjdk.java.net/~herrick/8219695/ /Andy
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 jpackage. [1] https://bugs.openjdk.java.net/browse/JDK-8219695 [2] http://cr.openjdk.java.net/~herrick/8219695/ /Andy
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] http://cr.openjdk.java.net/~herrick/8219695/ /Andy
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Jörg, I don't think it will be very much work to bring service bundler code from JFX packager into OpenJDK jpackager. Though I can't give you estimates on amount of work needed to be done for this at the moment. - Alexey On 7/23/2018 7:47 AM, Buchberger, Joerg wrote: Thanks for the insight. @Alexey: Then, how much work do you see in reactivating service bundler? Cheers Jörg -Original Message- From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Donnerstag, 12. Juli 2018 01:09 To: Buchberger, Joerg ; core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: Hi thanks for the update/info. I had a quick look at the changes. So, here some thoughts... As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.) What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place? Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all? Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.ne t_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jD eSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK hVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0k ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java .net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR W_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHq hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE dQ22wI9I= On 6/27/2018 3:30 PM, Kevin Rushforth wrote: We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager. We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development. Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP. -- Kevin
RE: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Thanks for the insight. @Alexey: Then, how much work do you see in reactivating service bundler? Cheers Jörg -Original Message- From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Donnerstag, 12. Juli 2018 01:09 To: Buchberger, Joerg ; core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: > Hi > > thanks for the update/info. I had a quick look at the changes. So, here some > thoughts... > > As described in JDK-8200758, and therefore expected, WinExeBundler has been > removed in favor of putting focus on WinMsiBundler. > (Although, I regret that decision - since my personal experience has > been that InnoSetup based WinExeBundler has worked much better than > wix based WinMsiBundler for our use cases - I can live with that.) > > What is much more disturbing: WinServiceBundler has also been actively > removed, although that was working fine together with both wix/msi and > exe/iss. Why has service wrapping been removed as well, while the command > line option for it is kept in place? > > Is there any chance of service bundler coming back into scope of JDK-8200758 > or coming back in at all? > > Cheers > Jörg > > > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On > Behalf Of Kevin Rushforth > Sent: Freitag, 6. Juli 2018 22:14 > To: core-libs-dev@openjdk.java.net > Cc: Alexey Semenyuk ; Andy Herrick > > Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP > proposal: JDK-8200758: Packaging Tool] > > An initial prototype of the jpackager tool has been pushed to a new > 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested > in taking a look, you can clone it as follows: > > hg clone > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= > cd ./sandbox > hg update JDK-8200758-branch > > I plan to reply to the feedback already provided, and update the JEP [2] next > week some time, but in the mean time if you have additional questions or > comments, feel free to reply. > > -- Kevin > > [1] > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.ne > t_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jD > eSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK > hVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0k > ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java > .net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR > W_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHq > hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE > dQ22wI9I= > > > On 6/27/2018 3:30 PM, Kevin Rushforth wrote: >> We're aiming to get this into JDK 12 early enough so that an EA build >> would be available around the time JDK 11 ships. That will allow you >> to take a jlinked image with JDK 11 and package it up using (the EA) >> jpackager. >> >> We will create a development branch in the JDK sandbox [1] some time >> in the next week or so so you can follow the development. >> >> Also, thank you to those who have provided feedback. I'll reply to >> feedback soon and then incorporate it into an updated JEP. >> >> -- Kevin
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Since support for services/daemons was already in javapackager, why does this have to be a stretch goal? Isn’t it mostly already done? I would like to see this in the initial implementation. It is something I’m currently using via javapackager. I’m still trying to figure out the best strategy from bridging the gap in Java 11 where suddenly no packager is available. My company has already decided to skip Java 9 and 10 altogether. Modules were too disruptive when they came in Java 9, which didn’t last long until Java 10. Given that Java 11 unbundled JavaFX, we decided not to bother trying to go to 10 just to have to re-jig everything for 11. Now 11 is missing key tools (javapackager) that we began to rely on, so we keep falling behind, unable to adopt the newer JDK/JRE because the cost is so high. The first time ever in the history of Java where we couldn’t just adapt the new JDK and tweak for minor issues if any. Migrating projects beyond Java 8 is a big pain. It would suck if Java 12 lacks what was available in Java 8. (Please excuse the rant.) Scott > On Jul 11, 2018, at 7:08 PM, Kevin Rushforth > wrote: > > We will likely be able to deliver the .exe installer (with its dependency on > Inno Setup). > > As for the service bundler, this will be a "nice to have" (a stretch goal) > for this version, but isn't on the list of committed features. Alexsei might > be able to comment further on how much work it would be to provide it, > including documenting and testing it. This might give you, and other > interested developers, a sense of how likely this is to make it for this > version. > > -- Kevin > > >> On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: >> Hi >> >> thanks for the update/info. I had a quick look at the changes. So, here some >> thoughts... >> >> As described in JDK-8200758, and therefore expected, WinExeBundler has been >> removed in favor of putting focus on WinMsiBundler. >> (Although, I regret that decision - since my personal experience has been >> that InnoSetup based WinExeBundler has worked much better than wix based >> WinMsiBundler for our use cases - I can live with that.) >> >> What is much more disturbing: WinServiceBundler has also been actively >> removed, although that was working fine together with both wix/msi and >> exe/iss. Why has service wrapping been removed as well, while the command >> line option for it is kept in place? >> >> Is there any chance of service bundler coming back into scope of JDK-8200758 >> or coming back in at all? >> >> Cheers >> Jörg >> >> >> -Original Message- >> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On >> Behalf Of Kevin Rushforth >> Sent: Freitag, 6. Juli 2018 22:14 >> To: core-libs-dev@openjdk.java.net >> Cc: Alexey Semenyuk ; Andy Herrick >> >> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: >> JDK-8200758: Packaging Tool] >> >> An initial prototype of the jpackager tool has been pushed to a new >> 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested >> in taking a look, you can clone it as follows: >> >> hg clone >> https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= >> cd ./sandbox >> hg update JDK-8200758-branch >> >> I plan to reply to the feedback already provided, and update the JEP [2] >> next week some time, but in the mean time if you have additional questions >> or comments, feel free to reply. >> >> -- Kevin >> >> [1] >> https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= >> [2] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I= >> >> >>> On 6/27/2018 3:30 PM, Kevin Rushforth wrote: >>> We're aiming to get this into JDK 12 early enough so that an EA build >>> would be available around the time JDK 11 ships. That will allow you >>> to take a jlinked image with JDK 11 and package it up using (the EA) >>> jpackager. >>> >>> We will create a development branch in the JDK sandbox [1] some time >>> in the next week or so so you can follow the development. >>> >>> Also, thank you to those who have provided feedback. I'll reply to >>> feedback soon and then incorporate it into an updated JEP. >>> >>> -- Kevin >
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: Hi thanks for the update/info. I had a quick look at the changes. So, here some thoughts... As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.) What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place? Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all? Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I= On 6/27/2018 3:30 PM, Kevin Rushforth wrote: We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager. We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development. Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP. -- Kevin
RE: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Hi thanks for the update/info. I had a quick look at the changes. So, here some thoughts... As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.) What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place? Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all? Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I= On 6/27/2018 3:30 PM, Kevin Rushforth wrote: > We're aiming to get this into JDK 12 early enough so that an EA build > would be available around the time JDK 11 ships. That will allow you > to take a jlinked image with JDK 11 and package it up using (the EA) > jpackager. > > We will create a development branch in the JDK sandbox [1] some time > in the next week or so so you can follow the development. > > Also, thank you to those who have provided feedback. I'll reply to > feedback soon and then incorporate it into an updated JEP. > > -- Kevin
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
For the first point, it means that jpackager should use jopt for the argument
parsing (to be fully compatible with the GNU style of options).
For the second point, it means to change a lot of code that may break because
it's less mechanical than introducing try-with-resources.
This seems quite a reasonable suggestion. Thanks.
-- Kevin
On 7/7/2018 7:10 AM, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Kevin Rushforth"
À: "Remi Forax"
Cc: "core-libs-dev" , "Alexey Semenyuk"
, "Andy Herrick"
Envoyé: Samedi 7 Juillet 2018 15:47:01
Objet: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
JDK-8200758: Packaging Tool]
Hi Remy,
Thank you for taking a look.
Yes, the javapackager code that forms the basis for the jpackager
prototype was initially developed on older JDKs and evolved from there.
I'm sure the improvements you suggest are all good ones, and it doesn't
seem like it would be too hard to address the most important of them,
especially the try-with-resources or anything else that would affect the
robustness of the tool. As long as we do address the robustness issues,
I think it is more important to get the feature set right, and make sure
that the public interfaces -- the command line options and ToolProvider
interface -- are clean. I don't see the need to rewrite the tool or take
an extra couple of months to modernize all of the implementation to use
JDK 11 APIs everywhere.
Also, I don't agree that jpackager is too large for jdk/sandbox or that
it needs it own project. The jdk/sandbox is perfect for new modules /
new tools that don't impact other parts of the JDK.
-- Kevin
Hi Kevin,
like you, i don't think that a full rewrite is necessary, as you said having
the right public 'interfaces' is enough,
but reducing the size the duplicated code (with the JDK and internally) is as
important in my opinion.
For the first point, it means that jpackager should use jopt for the argument
parsing (to be fully compatible with the GNU style of options).
For the second point, it means to change a lot of code that may break because
it's less mechanical than introducing try-with-resources.
regards,
Rémi
On 7/6/2018 3:07 PM, Remi Forax wrote:
I've just taking a look at the patch,
i don't see how this can be integrated soon, the code is consistently
inconsistent as one of my colleague would say, even the coding conventions are
not respected.
i believe that's it's because the code have been written first in Java 6 an
without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so
most of the try/finally are not safe,
a lot of code like new BufferedWriter(new FileWriter(file)) instead of
Files.newBufferedWriter, etc. The code should use the package java.nio.file,
and not the old java.io,
most of the code try to manage the exception right were they appear instead of
propagating them so there are too many try/catch,
a lot of catch are ignored which is a code smell, some codes use the internal
logger (jdk.packager.internal.Log), but a lot of codes doesn't,
for the collection code, there is a lot of copy of data small structures (which
suggest that published collections are not immutable),
there are dubious @SuppressWarnings("unchecked"), some or them are due to the
fact that the code use Class as a type token instead of using lambdas,
Stream are not used when they should (to avoid multiple copy between data
structures) and streams that need to be closed are not (the result of
Files.list by example),
there are usual "don't do that in Java" like a loop using an integer index to
traverse a List without knowing if it's a random access list or not,
there is a lot of nullchecks instead of using Optional,
a lot of code initialize local variables to null which is a code smell (and a
side effect of having a lot of try/catch but not only),
constructors should not do work, just initialization, use static factory method
instead (so you will not have to debug half constructed objects),
the code uses BigIntegers to parse a bundle version, just in case,
the code uses an AtomicReference as a box that a lambda can mutate, instead of
wrapping the exception into a runtime and unwrapping it at call site,
The code of jdk.packager.internal.IOUtils should be updated to use methods of
the JDK 11 and methods like readFully should be replaced by the JDK's one.
listOfPathToString and setOfStringToString are just WTF, like in
getRedistributableModules(), where the variable stream is an Optional,
A class like Platform should be used everywhere to do platform specific stuff, a
lot of code still use String matching (the version parsing should use
System.Version).
All the argument parsing should be delegated to JOpt (the one integrated with
the JDK), so it will be consistent with the other JDK tools,
There is a UnsupportedPlatformException but a Platfo
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
- Mail original -
> De: "Kevin Rushforth"
> À: "Remi Forax"
> Cc: "core-libs-dev" , "Alexey Semenyuk"
> , "Andy Herrick"
>
> Envoyé: Samedi 7 Juillet 2018 15:47:01
> Objet: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
> JDK-8200758: Packaging Tool]
> Hi Remy,
>
> Thank you for taking a look.
>
> Yes, the javapackager code that forms the basis for the jpackager
> prototype was initially developed on older JDKs and evolved from there.
> I'm sure the improvements you suggest are all good ones, and it doesn't
> seem like it would be too hard to address the most important of them,
> especially the try-with-resources or anything else that would affect the
> robustness of the tool. As long as we do address the robustness issues,
> I think it is more important to get the feature set right, and make sure
> that the public interfaces -- the command line options and ToolProvider
> interface -- are clean. I don't see the need to rewrite the tool or take
> an extra couple of months to modernize all of the implementation to use
> JDK 11 APIs everywhere.
>
> Also, I don't agree that jpackager is too large for jdk/sandbox or that
> it needs it own project. The jdk/sandbox is perfect for new modules /
> new tools that don't impact other parts of the JDK.
>
> -- Kevin
Hi Kevin,
like you, i don't think that a full rewrite is necessary, as you said having
the right public 'interfaces' is enough,
but reducing the size the duplicated code (with the JDK and internally) is as
important in my opinion.
For the first point, it means that jpackager should use jopt for the argument
parsing (to be fully compatible with the GNU style of options).
For the second point, it means to change a lot of code that may break because
it's less mechanical than introducing try-with-resources.
regards,
Rémi
>
>
> On 7/6/2018 3:07 PM, Remi Forax wrote:
>> I've just taking a look at the patch,
>> i don't see how this can be integrated soon, the code is consistently
>> inconsistent as one of my colleague would say, even the coding conventions
>> are
>> not respected.
>> i believe that's it's because the code have been written first in Java 6 an
>> without refactoring was moved to use Java 7, 8, 9, 10 and 11.
>>
>> The I/O code still using java.io.File for some parts, no try-with-resources
>> so
>> most of the try/finally are not safe,
>> a lot of code like new BufferedWriter(new FileWriter(file)) instead of
>> Files.newBufferedWriter, etc. The code should use the package java.nio.file,
>> and not the old java.io,
>> most of the code try to manage the exception right were they appear instead
>> of
>> propagating them so there are too many try/catch,
>> a lot of catch are ignored which is a code smell, some codes use the internal
>> logger (jdk.packager.internal.Log), but a lot of codes doesn't,
>> for the collection code, there is a lot of copy of data small structures
>> (which
>> suggest that published collections are not immutable),
>> there are dubious @SuppressWarnings("unchecked"), some or them are due to the
>> fact that the code use Class as a type token instead of using lambdas,
>> Stream are not used when they should (to avoid multiple copy between data
>> structures) and streams that need to be closed are not (the result of
>> Files.list by example),
>> there are usual "don't do that in Java" like a loop using an integer index to
>> traverse a List without knowing if it's a random access list or not,
>> there is a lot of nullchecks instead of using Optional,
>> a lot of code initialize local variables to null which is a code smell (and a
>> side effect of having a lot of try/catch but not only),
>> constructors should not do work, just initialization, use static factory
>> method
>> instead (so you will not have to debug half constructed objects),
>> the code uses BigIntegers to parse a bundle version, just in case,
>> the code uses an AtomicReference as a box that a lambda can mutate, instead
>> of
>> wrapping the exception into a runtime and unwrapping it at call site,
>> The code of jdk.packager.internal.IOUtils should be updated to use methods of
>> the JDK 11 and methods like readFully should be replaced by the JDK's one.
>> listOfPathToString and setOfStringToString are just WTF, like in
>> getRedistributableModules(), where the variable stream is an Optional,
>> A class like Platform should be used everywhere to do platform specific
>> stuff, a
>> lot of code still use String matching (the version parsing should use
>> System.Version).
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Hi Remy,
Thank you for taking a look.
Yes, the javapackager code that forms the basis for the jpackager
prototype was initially developed on older JDKs and evolved from there.
I'm sure the improvements you suggest are all good ones, and it doesn't
seem like it would be too hard to address the most important of them,
especially the try-with-resources or anything else that would affect the
robustness of the tool. As long as we do address the robustness issues,
I think it is more important to get the feature set right, and make sure
that the public interfaces -- the command line options and ToolProvider
interface -- are clean. I don't see the need to rewrite the tool or take
an extra couple of months to modernize all of the implementation to use
JDK 11 APIs everywhere.
Also, I don't agree that jpackager is too large for jdk/sandbox or that
it needs it own project. The jdk/sandbox is perfect for new modules /
new tools that don't impact other parts of the JDK.
-- Kevin
On 7/6/2018 3:07 PM, Remi Forax wrote:
I've just taking a look at the patch,
i don't see how this can be integrated soon, the code is consistently
inconsistent as one of my colleague would say, even the coding conventions are
not respected.
i believe that's it's because the code have been written first in Java 6 an
without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so
most of the try/finally are not safe,
a lot of code like new BufferedWriter(new FileWriter(file)) instead of
Files.newBufferedWriter, etc. The code should use the package java.nio.file,
and not the old java.io,
most of the code try to manage the exception right were they appear instead of
propagating them so there are too many try/catch,
a lot of catch are ignored which is a code smell, some codes use the internal
logger (jdk.packager.internal.Log), but a lot of codes doesn't,
for the collection code, there is a lot of copy of data small structures (which
suggest that published collections are not immutable),
there are dubious @SuppressWarnings("unchecked"), some or them are due to the
fact that the code use Class as a type token instead of using lambdas,
Stream are not used when they should (to avoid multiple copy between data
structures) and streams that need to be closed are not (the result of
Files.list by example),
there are usual "don't do that in Java" like a loop using an integer index to
traverse a List without knowing if it's a random access list or not,
there is a lot of nullchecks instead of using Optional,
a lot of code initialize local variables to null which is a code smell (and a
side effect of having a lot of try/catch but not only),
constructors should not do work, just initialization, use static factory method
instead (so you will not have to debug half constructed objects),
the code uses BigIntegers to parse a bundle version, just in case,
the code uses an AtomicReference as a box that a lambda can mutate, instead of
wrapping the exception into a runtime and unwrapping it at call site,
The code of jdk.packager.internal.IOUtils should be updated to use methods of
the JDK 11 and methods like readFully should be replaced by the JDK's one.
listOfPathToString and setOfStringToString are just WTF, like in
getRedistributableModules(), where the variable stream is an Optional,
A class like Platform should be used everywhere to do platform specific stuff,
a lot of code still use String matching (the version parsing should use
System.Version).
All the argument parsing should be delegated to JOpt (the one integrated with
the JDK), so it will be consistent with the other JDK tools,
There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of cleaning that should
appear before the code is integrated into the JDK and given the size of the
code, i wonder if it's not better to start an OpenJDK project for it and
iterate on the code before trying to include it in the JDK. For me, the code is
too big to use the jdk/sandbox.
regards,
Rémi
- Mail original -
De: "Kevin Rushforth"
À: "core-libs-dev"
Cc: "Alexey Semenyuk" , "Andy Herrick"
Envoyé: Vendredi 6 Juillet 2018 22:14:29
Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new
'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is
interested in taking a look, you can clone it as follows:
hg clone http://hg.openjdk.java.net/jdk/sandbox
cd ./sandbox
hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2]
next week some time, but in the mean time if you have additional
questions or comments, feel free to reply.
-- Kevin
[1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
I've just taking a look at the patch,
i don't see how this can be integrated soon, the code is consistently
inconsistent as one of my colleague would say, even the coding conventions are
not respected.
i believe that's it's because the code have been written first in Java 6 an
without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so
most of the try/finally are not safe,
a lot of code like new BufferedWriter(new FileWriter(file)) instead of
Files.newBufferedWriter, etc. The code should use the package java.nio.file,
and not the old java.io,
most of the code try to manage the exception right were they appear instead of
propagating them so there are too many try/catch,
a lot of catch are ignored which is a code smell, some codes use the internal
logger (jdk.packager.internal.Log), but a lot of codes doesn't,
for the collection code, there is a lot of copy of data small structures (which
suggest that published collections are not immutable),
there are dubious @SuppressWarnings("unchecked"), some or them are due to the
fact that the code use Class as a type token instead of using lambdas,
Stream are not used when they should (to avoid multiple copy between data
structures) and streams that need to be closed are not (the result of
Files.list by example),
there are usual "don't do that in Java" like a loop using an integer index to
traverse a List without knowing if it's a random access list or not,
there is a lot of nullchecks instead of using Optional,
a lot of code initialize local variables to null which is a code smell (and a
side effect of having a lot of try/catch but not only),
constructors should not do work, just initialization, use static factory method
instead (so you will not have to debug half constructed objects),
the code uses BigIntegers to parse a bundle version, just in case,
the code uses an AtomicReference as a box that a lambda can mutate, instead of
wrapping the exception into a runtime and unwrapping it at call site,
The code of jdk.packager.internal.IOUtils should be updated to use methods of
the JDK 11 and methods like readFully should be replaced by the JDK's one.
listOfPathToString and setOfStringToString are just WTF, like in
getRedistributableModules(), where the variable stream is an Optional,
A class like Platform should be used everywhere to do platform specific stuff,
a lot of code still use String matching (the version parsing should use
System.Version).
All the argument parsing should be delegated to JOpt (the one integrated with
the JDK), so it will be consistent with the other JDK tools,
There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of cleaning that should
appear before the code is integrated into the JDK and given the size of the
code, i wonder if it's not better to start an OpenJDK project for it and
iterate on the code before trying to include it in the JDK. For me, the code is
too big to use the jdk/sandbox.
regards,
Rémi
- Mail original -
> De: "Kevin Rushforth"
> À: "core-libs-dev"
> Cc: "Alexey Semenyuk" , "Andy Herrick"
>
> Envoyé: Vendredi 6 Juillet 2018 22:14:29
> Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
> JDK-8200758: Packaging Tool]
> An initial prototype of the jpackager tool has been pushed to a new
> 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is
> interested in taking a look, you can clone it as follows:
>
> hg clone http://hg.openjdk.java.net/jdk/sandbox
> cd ./sandbox
> hg update JDK-8200758-branch
>
> I plan to reply to the feedback already provided, and update the JEP [2]
> next week some time, but in the mean time if you have additional
> questions or comments, feel free to reply.
>
> -- Kevin
>
> [1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch
> [2] https://bugs.openjdk.java.net/browse/JDK-8200758
>
>
> On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
>> We're aiming to get this into JDK 12 early enough so that an EA build
>> would be available around the time JDK 11 ships. That will allow you
>> to take a jlinked image with JDK 11 and package it up using (the EA)
>> jpackager.
>>
>> We will create a development branch in the JDK sandbox [1] some time
>> in the next week or so so you can follow the development.
>>
>> Also, thank you to those who have provided feedback. I'll reply to
>> feedback soon and then incorporate it into an updated JEP.
>>
> > -- Kevin
Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone http://hg.openjdk.java.net/jdk/sandbox cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch [2] https://bugs.openjdk.java.net/browse/JDK-8200758 On 6/27/2018 3:30 PM, Kevin Rushforth wrote: We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager. We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development. Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP. -- Kevin
