Draft JEP proposal: JDK-8200758: Packaging Tool

Buchberger, Joerg Joerg.Buchberger at pruftechnik.com
Fri Jul 27 11:59:04 UTC 2018

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


-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer
Sent: Donnerstag, 26. Juli 2018 16:39
To: Kevin Rushforth <kevin.rushforth at oracle.com>
Cc: core-libs-dev at 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.


> On Jul 25, 2018, at 7:12 PM, Kevin Rushforth <kevin.rushforth at oracle.com> 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=

More information about the core-libs-dev mailing list