Draft JEP proposal: JDK-8200758: Packaging Tool

Andy Herrick andy.herrick at oracle.com
Fri Jul 27 14:14:36 UTC 2018

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)"


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 
>>> <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://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

More information about the core-libs-dev mailing list