Re: Draft JEP proposal: JDK-8200758: Packaging Tool
I'm concerned about the possible loss of the packager service, i.e. the UserJvmOptionsService class and associated underlying machinery in the jpackager. Background: I'm developing and maintaining an internal GUI tool for log analysis. It reads, parses and aggregates data from many different kinds of logs from our production systems. The amount of memory needed to process all the data can vary quite a lot from run to run, so I've found it very convenient to utilise the UserJvmOptionsService to enable my users to set and manage the JVM settings of the JVM-bundled application created by javapackager. As far as I know, the javapackager, and the packager services, were omitted from JDK 11. While I can still use the javapackager of JDK 10 to package a JDK 11 application, I don't see how I could use the packager services, since they are not present. neither in JDK 11 nor in openjfx 11. I would like to suggest the UserJvmOptionsService, or equivalent, be retained in the successor tool, jpackager. Best regards, /Lennart Börjeson
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Right, I explicitly want to make the distinction between this and the “Multiple launchers” stretch goal. I want to use the "multiple launchers” as well. One way that I have used multiple launchers (on Linux, I don’t think I could get it to work on Windows) is to have one launcher be a service/daemon and a second launcher be a configuration utility for the service. I have some cases where multiple services are installed, each can be independent, but normally they are part of several different product suites. The total product itself can share a JRE, that’s where I want the option to specify a private, shared JRE. The JRE often makes up the majority of the application’s size. This can come down with jlink of course, but because of the nature of our product - with many plugins that are installed after the fact, we need a full JRE as we can’t anticipate what modules the plugins will need. Scott > On Jul 27, 2018, at 10:14 AM, Andy Herrick wrote: > > I don't see why this isn't feasible, and will file such an enhancement > request, but should be possible to deliver a suite of apps in one bundle. > This is the third 'stretch goal' : "Multiple launchers (enables a suite of > applications to be bundled in a single self-contained application package)" > > /Andy > > > On 7/27/2018 9:13 AM, Kevin Rushforth wrote: >> > Will it be possible to NOT include the JRE, but specify instead a >> > pre-existing location for the JRE? >> >> This does seem like an interesting use case. As you say, it is similar in >> many ways to both the Multiple Launchers and system JRE, but not quite the >> same as either. The mechanism to manage and locate these shared-but-private >> JREs seems like the most challenging part. We can add it to the "if there is >> time" list of features, but I don't know how feasible it is for the first >> version. Andy or Alexey can comment as to whether the current prototype has >> done anything that would make this difficult. >> >> -- Kevin >> >> >> On 7/26/2018 7:38 AM, Scott Palmer wrote: >>> "The input to jpackager includes: a Java runtime image, and a Java >>> application in one of several formats..." >>> >>> Will it be possible to NOT include the JRE, but specify instead a >>> pre-existing location for the JRE? >>> >>> As an example use-case consider an office productivity suite where there >>> are separate installers for a word processor and a spreadsheet application. >>> These applications are independent and can be installed in any combination >>> (word processor only, both, spreadsheet only). However they are part of >>> the same versioned application suite and have been developed and tested >>> with a particular JRE. Only a single JRE needs to be installed. The >>> applications can share it. This is not the same as using a system-wide JRE >>> (is that even supported for Java 11 and beyond?). But a shared private JRE >>> controlled by the application developer. >>> >>> This is similar but not the same as the proposed "Multiple launchers" >>> feature (if time allows), as the shared JRE could be used by different >>> software packages. >>> >>> In many cases the JRE is a very large part of the software installation, >>> both in terms of the size of the distributed installer package and the >>> storage requirements of the installed application. JRE sharing can help >>> with this. >>> >>> I'm thinking that eventually we could get to the point where developers >>> could treat the JRE as a versioned dependency, also covering the case of >>> customized JRE images. I don't propose that this jpackager tool be >>> involved in creating or distributing such JRE images, only that it supports >>> running applications using a pre-installed JRE where the location can be >>> determined at installer build time or perhaps install time. >>> >>> This was possible with the javapackager tool. >>> >>> Scott >>> On Jul 25, 2018, at 7:12 PM, Kevin Rushforth wrote: Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth wrote: > I would like to propose the following Draft JEP [1] for discussion. > > JDK-8200758: Packaging Tool > > This is intended as a JDK-scope replacement for the existing javapackager > tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and > was
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
I don't see why this isn't feasible, and will file such an enhancement request, but should be possible to deliver a suite of apps in one bundle. This is the third 'stretch goal' : "Multiple launchers (enables a suite of applications to be bundled in a single self-contained application package)" /Andy On 7/27/2018 9:13 AM, Kevin Rushforth wrote: > Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? This does seem like an interesting use case. As you say, it is similar in many ways to both the Multiple Launchers and system JRE, but not quite the same as either. The mechanism to manage and locate these shared-but-private JREs seems like the most challenging part. We can add it to the "if there is time" list of features, but I don't know how feasible it is for the first version. Andy or Alexey can comment as to whether the current prototype has done anything that would make this difficult. -- Kevin On 7/26/2018 7:38 AM, Scott Palmer wrote: "The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott On Jul 25, 2018, at 7:12 PM, Kevin Rushforth wrote: Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth wrote: I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
With the existing javapackager there are some limitations.
On Windows I only use it to go as far as creating the application image. I
then run the WiX commands in my Gradle build script to finish creating an
installer that has an added custom component used to tweak the .cfg file.
(Creating just the application image is something that should still be possible
with the new tool.) On Linux the full install package can be built directly
with javapackager.
The idea is to set the packager to use the system JRE. This creates an
application image with the .cfg file configured with no JRE path
("app.runtime=“) and no JRE files bundled.
For Linux builds, I customize the .spec file used by the packager (in verbose
mode the packager tells you where it put the generated file .spec file so you
can customize it). I add a simple command to modify the application’s .cfg
file with a simple search/replace of the app.runtime= line.
E.g. for MyApplication which installs in /opt:
# Tweak .cfg to point to JRE if it is not already specified. E.g.: change
“app.runtime=" to "app.runtime=/usr/java/latest"
sed -e 's/^app\.runtime=$/app\.runtime=\/usr\/java\/latest/'
%{_sourcedir}/MyApplication/app/MyApplication.cfg >
%{buildroot}/opt/MyApplication/app/MyApplication.cfg
On Windows, I take advantage of the fact that the .cfg file follows the
convention of a Windows .ini file and MSI/WiX has a mechanism to add or modify
.ini file entries.
This WiX code added to some component, where the jre64FolderId is refers to the
install location of the private JRE, and appDirId refers the the ‘app’
sub-folder of the application image. My Gradle build script sets some of these
variables:
In both cases I use a separate module for the private JRE that can be shared
among other applications. The JRE installs to a common company folder in a
versioned sub-folder so we can have multiple private JREs as we migrate
products to newer JREs, but only ever one copy of any given version of the JRE.
My concern with the new tool is that removal of support for a “system JRE”
would make it impossible to build a package that doesn't contain a JRE,
bloating the sizes of both the installer and installed image footprint (since
applications can’t share a common JRE easily).
Having the applications run on the same JRE may also have benefits related to
class data sharing.
Scott
> On Jul 27, 2018, at 7:59 AM, Buchberger, Joerg
> wrote:
>
> Thanks for the info - I was not aware of these possibilities in javapackager.
>
> @Kevin: just fyi, this would be also a very useful feature for the company I
> work for and for our projects
>
> @Scott: please, let me know, how to achieve this with javapackager
>
> Cheers
> Jörg
>
>
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net
> <mailto:core-libs-dev-boun...@openjdk.java.net>] On Behalf Of Scott Palmer
> Sent: Donnerstag, 26. Juli 2018 16:39
> To: Kevin Rushforth <mailto:kevin.rushfo...@oracle.com>>
> Cc: core-libs-dev@openjdk.java.net <mailto:core-libs-dev@openjdk.java.net>
> Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
>
> "The input to jpackager includes: a Java runtime image, and a Java
> application in one of several formats..."
>
> Will it be possible to NOT include the JRE, but specify instead a
> pre-existing location for the JRE?
>
>
> This was possible with the javapackager tool.
>
> Scott
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
> Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? This does seem like an interesting use case. As you say, it is similar in many ways to both the Multiple Launchers and system JRE, but not quite the same as either. The mechanism to manage and locate these shared-but-private JREs seems like the most challenging part. We can add it to the "if there is time" list of features, but I don't know how feasible it is for the first version. Andy or Alexey can comment as to whether the current prototype has done anything that would make this difficult. -- Kevin On 7/26/2018 7:38 AM, Scott Palmer wrote: "The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott On Jul 25, 2018, at 7:12 PM, Kevin Rushforth wrote: Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth wrote: I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758
RE: Draft JEP proposal: JDK-8200758: Packaging Tool
Thanks for the info - I was not aware of these possibilities in javapackager. @Kevin: just fyi, this would be also a very useful feature for the company I work for and for our projects @Scott: please, let me know, how to achieve this with javapackager Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Scott Palmer Sent: Donnerstag, 26. Juli 2018 16:39 To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool "The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott > On Jul 25, 2018, at 7:12 PM, Kevin Rushforth > wrote: > > Thank you to all who provided feedback. I have updated the draft JEP [1], and > I think I have incorporated most of the feedback I received. Specifically, I > have reorganized and reworded a few things for clarity, added '.exe' and > '.app in a .dmg' native package format to the list of features, and added the > service bundler (daemon) feature to the "if we have time" list (at the top of > that list). > > Please let me know if I missed an important point. I hope to submit this JEP > in the next week or two. > > -- Kevin > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758&d=DwIFAg&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=KlUfgj63empIAez-vk164MMdqh0UIH4raiiK6AKkZmE&s=_R35pRHxi2Ndq3uYY8hHyYuFLWB2IGONK0xIZ_D7GfU&e= > > > On 5/30/2018 5:10 PM, Kevin Rushforth wrote: >> I would like to propose the following Draft JEP [1] for discussion. >> >> JDK-8200758: Packaging Tool >> >> This is intended as a JDK-scope replacement for the existing javapackager >> tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and >> was delivered as part of the JavaFX build. The javapackager tool has been >> removed from Oracle JDK 11 along with the removal of JavaFX. >> >> Comments on this JEP are welcome. It is currently not targeted for a >> specific release, but we are aiming for JDK 12. >> >> -- Kevin >> >> [1] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758&d=DwIFAg&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=KlUfgj63empIAez-vk164MMdqh0UIH4raiiK6AKkZmE&s=_R35pRHxi2Ndq3uYY8hHyYuFLWB2IGONK0xIZ_D7GfU&e= >> >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
"The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott > On Jul 25, 2018, at 7:12 PM, Kevin Rushforth > wrote: > > Thank you to all who provided feedback. I have updated the draft JEP [1], and > I think I have incorporated most of the feedback I received. Specifically, I > have reorganized and reworded a few things for clarity, added '.exe' and > '.app in a .dmg' native package format to the list of features, and added the > service bundler (daemon) feature to the "if we have time" list (at the top of > that list). > > Please let me know if I missed an important point. I hope to submit this JEP > in the next week or two. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 > > > On 5/30/2018 5:10 PM, Kevin Rushforth wrote: >> I would like to propose the following Draft JEP [1] for discussion. >> >> JDK-8200758: Packaging Tool >> >> This is intended as a JDK-scope replacement for the existing javapackager >> tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and >> was delivered as part of the JavaFX build. The javapackager tool has been >> removed from Oracle JDK 11 along with the removal of JavaFX. >> >> Comments on this JEP are welcome. It is currently not targeted for a >> specific release, but we are aiming for JDK 12. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >> >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Hello, Will there be: - support for displaying and asking for acceptance of license text - asking for target directory (installing outside of programfiles) - starting optional post-Installation class - menu entries - user vs. System wide Installation (on windows) - the new launchers also be available as jlink plugin - theming Installer Gruss Bernd -- http://bernd.eckenfels.net Von: -974640832m Auftrag von Gesendet: Donnerstag, Juli 26, 2018 2:12 AM An: core-libs-dev@openjdk.java.net Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth wrote: > I would like to propose the following Draft JEP [1] for discussion. > > JDK-8200758: Packaging Tool > > This is intended as a JDK-scope replacement for the existing > javapackager tool that ships with Oracle JDK 10 (and earlier Oracle > JDK releases), and was delivered as part of the JavaFX build. The > javapackager tool has been removed from Oracle JDK 11 along with the > removal of JavaFX. > > Comments on this JEP are welcome. It is currently not targeted for a > specific release, but we are aiming for JDK 12. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth wrote: I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758
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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0&e= 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&d=DwIFaQ&c=uD3W7j5M6i1jD eSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK hVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=F-CqPAWlz-Cfb0k ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java .net_browse_JDK-2D8200758&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR W_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHq hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE dQ22wI9I&e= 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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0&e= > 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&d=DwIFaQ&c=uD3W7j5M6i1jD > eSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK > hVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=F-CqPAWlz-Cfb0k > ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA&e= [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java > .net_browse_JDK-2D8200758&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR > W_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHq > hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE > dQ22wI9I&e= > > > 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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0&e= >> 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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA&e= >> [2] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I&e= >> >> >>> 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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0&e= 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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I&e= 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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0&e= 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&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I&e= 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 co
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 cod
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 f
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
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
- Mail original - > De: "Bernd Eckenfels" > À: "core-libs-dev" > Envoyé: Jeudi 28 Juin 2018 22:47:23 > Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > You can add-modules from the JDK (only), so if you „—add-modules > lang.base,JDK.jcmd,jdk.crypto.mscapi“ you get a super compact JRE which still > can start your app from the classpath. You mean you select by hand the modules of the JDK you need and use the classpath for your application, ok, that's work with jlink :) > > Gruss > Bernd Rémi > -- > http://bernd.eckenfels.net > > Von: Remi Forax > Gesendet: Donnerstag, 28. Juni 2018 22:05 > An: Bernd Eckenfels > Cc: core-libs-dev > Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > > no you can't, > --add-modules requires the module to have a module-info, being an automatic > module is not good enough. > > regards, > Rémi > > - Mail original ----- >> De: "Bernd Eckenfels" >> À: "core-libs-dev" >> Envoyé: Jeudi 28 Juin 2018 17:34:35 >> Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > >> you can jlink without any/complete module info files by specifying the module >> names on the command line (--add-modules)as well. It produces a jre like >> Directory including Java launcher which allows additions on the classpath. >> >> -- >> https://Bernd.eckenfels.net >> ________ >> From: core-libs-dev on behalf of >> Scott >> Palmer >> Sent: Thursday, June 28, 2018 2:32:13 PM >> To: Kevin Rushforth >> Cc: core-libs-dev@openjdk.java.net >> Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool >> >> Doesn’t jlink require a *fully* modularized application? I.e. no non-module >> dependencies. >> The packaging tool should work with all runnable Java applications, not just >> fully modularized ones. >> >> Modularization seems to be a bit of an effort and is one of the main reasons >> my >> application(s) are still stuck on Java 8. >> >> Scott >> >> >> >>> On Jun 27, 2018, at 6: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 >>> >>> >>> On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: >>>> Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I >>>> really mean it] >>>> >>>> But, to sum up my comprehension... >>>> >>>> anyone who placed their bets on javapackager, starting with last LTS Java 8 >>>> will be left in the rain with followup LTS Java 11, because their ain't >>>> neither >>>> javapackager (anymore), nor jpackager (yet). >>>> >>>> Is this correct? >>>> >>>> So, strategic choice boils down to either throw away all work done based on >>>> javapackager so far and the associated distribution concepts (reworking >>>> everything from scratch) >>>> or neglect Java 11 completely, thus placing all bets on jpackager really >>>> coming >>>> w/ Java 12 or even waiting for Java 14 as next LTS thereafter. >>>> >>>> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink >>>> in ... >>>> >>>> Cheers >>>> Jörg >>>> >>>> >>>> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >>>>> I would like to propose the following Draft JEP [1] for discussion. >>>>> >>>>> JDK-8200758: Packaging Tool >>>>> >>>>> This is intended as a JDK-scope replacement for the existing >>>>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK >>>>> releases), and was delivered as part of the JavaFX build. The >>>>> javapackager tool has been removed from Oracle JDK 11 along with the >>>>> removal of JavaFX. >>>>> >>>>> Comments on this JEP are welcome. It is currently not targeted for a >>>>> specific release, but we are aiming for JDK 12. >>>>> >>>>> -- Kevin >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
You can add-modules from the JDK (only), so if you „—add-modules lang.base,JDK.jcmd,jdk.crypto.mscapi“ you get a super compact JRE which still can start your app from the classpath. Gruss Bernd -- http://bernd.eckenfels.net Von: Remi Forax Gesendet: Donnerstag, 28. Juni 2018 22:05 An: Bernd Eckenfels Cc: core-libs-dev Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool no you can't, --add-modules requires the module to have a module-info, being an automatic module is not good enough. regards, Rémi - Mail original - > De: "Bernd Eckenfels" > À: "core-libs-dev" > Envoyé: Jeudi 28 Juin 2018 17:34:35 > Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > you can jlink without any/complete module info files by specifying the module > names on the command line (--add-modules)as well. It produces a jre like > Directory including Java launcher which allows additions on the classpath. > > -- > https://Bernd.eckenfels.net > > From: core-libs-dev on behalf of > Scott > Palmer > Sent: Thursday, June 28, 2018 2:32:13 PM > To: Kevin Rushforth > Cc: core-libs-dev@openjdk.java.net > Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > > Doesn’t jlink require a *fully* modularized application? I.e. no non-module > dependencies. > The packaging tool should work with all runnable Java applications, not just > fully modularized ones. > > Modularization seems to be a bit of an effort and is one of the main reasons > my > application(s) are still stuck on Java 8. > > Scott > > > >> On Jun 27, 2018, at 6: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 >> >> >> On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: >>> Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I >>> really mean it] >>> >>> But, to sum up my comprehension... >>> >>> anyone who placed their bets on javapackager, starting with last LTS Java 8 >>> will be left in the rain with followup LTS Java 11, because their ain't >>> neither >>> javapackager (anymore), nor jpackager (yet). >>> >>> Is this correct? >>> >>> So, strategic choice boils down to either throw away all work done based on >>> javapackager so far and the associated distribution concepts (reworking >>> everything from scratch) >>> or neglect Java 11 completely, thus placing all bets on jpackager really >>> coming >>> w/ Java 12 or even waiting for Java 14 as next LTS thereafter. >>> >>> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in >>> ... >>> >>> Cheers >>> Jörg >>> >>> >>> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >>>> I would like to propose the following Draft JEP [1] for discussion. >>>> >>>> JDK-8200758: Packaging Tool >>>> >>>> This is intended as a JDK-scope replacement for the existing >>>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK >>>> releases), and was delivered as part of the JavaFX build. The >>>> javapackager tool has been removed from Oracle JDK 11 along with the >>>> removal of JavaFX. >>>> >>>> Comments on this JEP are welcome. It is currently not targeted for a >>>> specific release, but we are aiming for JDK 12. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
no you can't, --add-modules requires the module to have a module-info, being an automatic module is not good enough. regards, Rémi - Mail original - > De: "Bernd Eckenfels" > À: "core-libs-dev" > Envoyé: Jeudi 28 Juin 2018 17:34:35 > Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > you can jlink without any/complete module info files by specifying the module > names on the command line (--add-modules)as well. It produces a jre like > Directory including Java launcher which allows additions on the classpath. > > -- > https://Bernd.eckenfels.net > > From: core-libs-dev on behalf of > Scott > Palmer > Sent: Thursday, June 28, 2018 2:32:13 PM > To: Kevin Rushforth > Cc: core-libs-dev@openjdk.java.net > Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > > Doesn’t jlink require a *fully* modularized application? I.e. no non-module > dependencies. > The packaging tool should work with all runnable Java applications, not just > fully modularized ones. > > Modularization seems to be a bit of an effort and is one of the main reasons > my > application(s) are still stuck on Java 8. > > Scott > > > >> On Jun 27, 2018, at 6: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 >> >> >> On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: >>> Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I >>> really mean it] >>> >>> But, to sum up my comprehension... >>> >>> anyone who placed their bets on javapackager, starting with last LTS Java 8 >>> will be left in the rain with followup LTS Java 11, because their ain't >>> neither >>> javapackager (anymore), nor jpackager (yet). >>> >>> Is this correct? >>> >>> So, strategic choice boils down to either throw away all work done based on >>> javapackager so far and the associated distribution concepts (reworking >>> everything from scratch) >>> or neglect Java 11 completely, thus placing all bets on jpackager really >>> coming >>> w/ Java 12 or even waiting for Java 14 as next LTS thereafter. >>> >>> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in >>> ... >>> >>> Cheers >>> Jörg >>> >>> >>> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >>>> I would like to propose the following Draft JEP [1] for discussion. >>>> >>>> JDK-8200758: Packaging Tool >>>> >>>> This is intended as a JDK-scope replacement for the existing >>>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK >>>> releases), and was delivered as part of the JavaFX build. The >>>> javapackager tool has been removed from Oracle JDK 11 along with the >>>> removal of JavaFX. >>>> >>>> Comments on this JEP are welcome. It is currently not targeted for a >>>> specific release, but we are aiming for JDK 12. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
you can jlink without any/complete module info files by specifying the module names on the command line (--add-modules)as well. It produces a jre like Directory including Java launcher which allows additions on the classpath. -- https://Bernd.eckenfels.net From: core-libs-dev on behalf of Scott Palmer Sent: Thursday, June 28, 2018 2:32:13 PM To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones. Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8. Scott > On Jun 27, 2018, at 6: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 > > > On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: >> Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I >> really mean it] >> >> But, to sum up my comprehension... >> >> anyone who placed their bets on javapackager, starting with last LTS Java 8 >> will be left in the rain with followup LTS Java 11, because their ain't >> neither javapackager (anymore), nor jpackager (yet). >> >> Is this correct? >> >> So, strategic choice boils down to either throw away all work done based on >> javapackager so far and the associated distribution concepts (reworking >> everything from scratch) >> or neglect Java 11 completely, thus placing all bets on jpackager really >> coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter. >> >> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in >> ... >> >> Cheers >> Jörg >> >> >> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >>> I would like to propose the following Draft JEP [1] for discussion. >>> >>> JDK-8200758: Packaging Tool >>> >>> This is intended as a JDK-scope replacement for the existing >>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK >>> releases), and was delivered as part of the JavaFX build. The >>> javapackager tool has been removed from Oracle JDK 11 along with the >>> removal of JavaFX. >>> >>> Comments on this JEP are welcome. It is currently not targeted for a >>> specific release, but we are aiming for JDK 12. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>> >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones. Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8. Scott > On Jun 27, 2018, at 6: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 > > > On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: >> Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I >> really mean it] >> >> But, to sum up my comprehension... >> >> anyone who placed their bets on javapackager, starting with last LTS Java 8 >> will be left in the rain with followup LTS Java 11, because their ain't >> neither javapackager (anymore), nor jpackager (yet). >> >> Is this correct? >> >> So, strategic choice boils down to either throw away all work done based on >> javapackager so far and the associated distribution concepts (reworking >> everything from scratch) >> or neglect Java 11 completely, thus placing all bets on jpackager really >> coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter. >> >> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in >> ... >> >> Cheers >> Jörg >> >> >> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >>> I would like to propose the following Draft JEP [1] for discussion. >>> >>> JDK-8200758: Packaging Tool >>> >>> This is intended as a JDK-scope replacement for the existing >>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK >>> releases), and was delivered as part of the JavaFX build. The >>> javapackager tool has been removed from Oracle JDK 11 along with the >>> removal of JavaFX. >>> >>> Comments on this JEP are welcome. It is currently not targeted for a >>> specific release, but we are aiming for JDK 12. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>> >
RE: Draft JEP proposal: JDK-8200758: Packaging Tool
Hi Kevin Thanks for the helpful reply. If you don't mind, I add my feedback here below. My concern is about the options -BserviceHint and -singleton which make javapackager one of the best things since sliced bread. It seems like next to no one is really aware of these valuable features, no wonder since they are by and large undocumented. So, people out there keep fiddling around with all kinds of service wrapper tools and also with strange approaches to ensure an app is started only once, completely unaware of the fact, that JDK 10 supports this out of the box, by the tip of a finger so to say. According to JDK-8200758, for Windows only msi is required deployment objective. Others only optional. Note in this regard that in contrary to exe (innosetup) deployment, msi installer lacks icon support for the installer itself and resulting msi installer is around 35% bigger in size. Documentation is also of concern. Luckily, the source is open to read, so one can for example find out, how to enable and read debug output for WinLauncherSvc using DebugView and that "-BserviceHint" option exists. Yippie ;-) Cheers Jörg -Original Message- From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Donnerstag, 28. Juni 2018 00:31 To: Buchberger, Joerg ; core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool 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 On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: > Thanks for the info! And thanks for the efforts. [no irony, no > sarcasm - I really mean it] > > But, to sum up my comprehension... > > anyone who placed their bets on javapackager, starting with last LTS > Java 8 will be left in the rain with followup LTS Java 11, because their > ain't neither javapackager (anymore), nor jpackager (yet). > > Is this correct? > > So, strategic choice boils down to either throw away all work done > based on javapackager so far and the associated distribution concepts > (reworking everything from scratch) or neglect Java 11 completely, thus > placing all bets on jpackager really coming w/ Java 12 or even waiting for > Java 14 as next LTS thereafter. > > Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in > ... > > Cheers > Jörg > > > On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >> I would like to propose the following Draft JEP [1] for discussion. >> >> JDK-8200758: Packaging Tool >> >> This is intended as a JDK-scope replacement for the existing >> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle >> JDK releases), and was delivered as part of the JavaFX build. The >> javapackager tool has been removed from Oracle JDK 11 along with the >> removal of JavaFX. >> >> Comments on this JEP are welcome. It is currently not targeted for a >> specific release, but we are aiming for JDK 12. >> >> -- Kevin >> >> [1] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.jav >> a.net_browse_JDK-2D8200758&d=DwIDaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFm >> xRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=k3PBuMbi >> PBU9Ni8nXxqYD_VD9uEULpswQedWmbRiF-4&s=vBSYLYnENsNahwwRNz0r-gPNrs90xST >> Ebm0wFA2iPWs&e= >>
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Hi Kevin, Just a small request, can you call it something like jbundler and not jpackager, because usually in build tools the packager step is the step that create the jars, not the one that bundle the whole application ? regards, Rémi - Mail original - > De: "Kevin Rushforth" > À: "core-libs-dev" > Envoyé: Jeudi 31 Mai 2018 02:10:48 > Objet: Draft JEP proposal: JDK-8200758: Packaging Tool > I would like to propose the following Draft JEP [1] for discussion. > > JDK-8200758: Packaging Tool > > This is intended as a JDK-scope replacement for the existing > javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK > releases), and was delivered as part of the JavaFX build. The > javapackager tool has been removed from Oracle JDK 11 along with the > removal of JavaFX. > > Comments on this JEP are welcome. It is currently not targeted for a > specific release, but we are aiming for JDK 12. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
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 On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it] But, to sum up my comprehension... anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet). Is this correct? So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter. Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ... Cheers Jörg On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it] But, to sum up my comprehension... anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet). Is this correct? So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter. Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ... Cheers Jörg On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: > I would like to propose the following Draft JEP [1] for discussion. > > JDK-8200758: Packaging Tool > > This is intended as a JDK-scope replacement for the existing > javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK > releases), and was delivered as part of the JavaFX build. The > javapackager tool has been removed from Oracle JDK 11 along with the > removal of JavaFX. > > Comments on this JEP are welcome. It is currently not targeted for a > specific release, but we are aiming for JDK 12. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
On 5/30/18 5:10 PM, Kevin Rushforth wrote: I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-820075 Good to see this moving along. A couple of comments: I think the JEP may need to mention the layout of an application image and define what's supported and unsupported to make it clear for developers what should or should not depend on, for example, the location of the application launcher and user-editable configuration files etcs. javapackager strips the tool launchers from the run-time image and enables compression. Does jpackager do something similar? As the development moves along, it'd be useful to include some command-line examples and describe the content of the run-time image produced. As part of this JEP, we need to look at the difference of the native launcher created by jpackager and by jlink. jlink creates a native launcher for modular application and possibly share same mechanism in creating native launchers. Mandy
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Hi Kevin, Looks good, I assume as part of the work several existing javapackager bugs will be swept up along the way? We use javapackager and are very happy with what it gives us considering it is "free as in beer", but there are some significant workarounds required for code signing, especially on Mac OS X. Sign us (jClarity) up as early testers :-). Cheers, Martijn On 1 June 2018 at 08:53, Alan Bateman wrote: > On 31/05/2018 01:10, Kevin Rushforth wrote: > >> I would like to propose the following Draft JEP [1] for discussion. >> >> JDK-8200758: Packaging Tool >> >> This is intended as a JDK-scope replacement for the existing javapackager >> tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and >> was delivered as part of the JavaFX build. The javapackager tool has been >> removed from Oracle JDK 11 along with the removal of JavaFX. >> >> Comments on this JEP are welcome. It is currently not targeted for a >> specific release, but we are aiming for JDK 12. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >> >> I read through the draft. > > The Goals and Non-Goals looks very reasonable. > > The Summary includes "self-contained Java Server ... applications" but the > JEP doesn't say too much about that part. Can we assume it can be started > and stopped with /etc/init.d or equivalent scripts, logs with the server > output etc? A general observation is that most of the issues around > end-user/GUI applications are clearly documented in the draft, the headless > application environment case less so. It makes me wonder if this JEP should > be split so that it initially focuses on the former. > > I think it would be useful if the JEP explained what an "application" is. > Is it a JAR file (with a Main-Class) that is deployed on the class path? > Can it be a module? What about modules and libraries that the application > uses. Users of javapackager might know these things but readers of the JEP > may not. > > The JEP mentions that JavaFX will be removed in JDK 11. I assume this > should be clarified so that it's clear it will no longer be shipped in > Oracle's JDK. It's a none issue for those using OpenJDK builds as the the > JavaFX modules were never bundled/imported by default. > > There are several references to "server JRE" that probably should be > clarified as this notion does not exist in OpenJDK. It may be that the JEP > just needs to clearer as to the modules that it links into the run-time > image. > > There are several references to "application launcher" and "native > launcher". At some point we need to work out some issues with jlink as it > it will need to generate native launchers too. The JEP could list it as an > issue as the development of this JEP will at least touch on some of this. > > The draft doesn't have a section on testing. If someone is building > OpenJDK then will they will require additional tools in the build > environment and can the tests be run without manual interaction? Also how > about a developer using the tool, will the generated native packages be > easy to un-install so they can easily test in a local environment? > > -Alan >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
On 31/05/2018 01:10, Kevin Rushforth wrote: I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 I read through the draft. The Goals and Non-Goals looks very reasonable. The Summary includes "self-contained Java Server ... applications" but the JEP doesn't say too much about that part. Can we assume it can be started and stopped with /etc/init.d or equivalent scripts, logs with the server output etc? A general observation is that most of the issues around end-user/GUI applications are clearly documented in the draft, the headless application environment case less so. It makes me wonder if this JEP should be split so that it initially focuses on the former. I think it would be useful if the JEP explained what an "application" is. Is it a JAR file (with a Main-Class) that is deployed on the class path? Can it be a module? What about modules and libraries that the application uses. Users of javapackager might know these things but readers of the JEP may not. The JEP mentions that JavaFX will be removed in JDK 11. I assume this should be clarified so that it's clear it will no longer be shipped in Oracle's JDK. It's a none issue for those using OpenJDK builds as the the JavaFX modules were never bundled/imported by default. There are several references to "server JRE" that probably should be clarified as this notion does not exist in OpenJDK. It may be that the JEP just needs to clearer as to the modules that it links into the run-time image. There are several references to "application launcher" and "native launcher". At some point we need to work out some issues with jlink as it it will need to generate native launchers too. The JEP could list it as an issue as the development of this JEP will at least touch on some of this. The draft doesn't have a section on testing. If someone is building OpenJDK then will they will require additional tools in the build environment and can the tests be run without manual interaction? Also how about a developer using the tool, will the generated native packages be easy to un-install so they can easily test in a local environment? -Alan
Draft JEP proposal: JDK-8200758: Packaging Tool
I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758
