JDK-8208405 : Application Bundle without including Java Runtime
  • Type: Enhancement
  • Component: tools
  • Sub-Component: jpackage
  • Affected Version: 14,15,16,17
  • Priority: P2
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2018-07-27
  • Updated: 2024-08-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25Unresolved
Related Reports
Relates :  
JDK-8275073 - Allow additional msi installers in jpackage exe build
Relates :  
JDK-8263155 - Allow additional contents for DMG
Relates :  
JDK-8250950 - Allow per-user and system wide configuration of a jpackaged app
Description
The current implementation of jpackager requires that each application to be bundled with it's own Java runtime.
It should be possible to NOT include the full runtime, but instead just specify a set of runtime requirements and let the applauncher discover the existence of a confirming java runtime.
Comments
A new implementation is being considered. Existing jpackage allows target of --runtime-image to be most anything, and jpackage will successfully build the application. (at least on windows, checks need to be made on other platforms and code adjusted if necessary) Naturally, although an application built with a runtime-image that contained only the release file can not run (It will currently get a message saying "Failed to find a JVM in .../<app-name>/runtime"), that leaves only changes needed to implement this is the code in applauncher to 1.) recognize if there is no runtime there. 2.) search a list of well-known locations for that platform for a JDK or other runtime conforming to the "release" file. 3.) use such a runtime if found, 4.) show a more user friendly error message if not found.
04-11-2020
Although we may return to this topic, the team has indicated we do not want this enhancement at this time.
31-01-2020
It's now a future release and this is being considered. adding an options such as --local-runtime-image seems fairly strait forward. prototyping this raises the following questions. 1.) do we need to implement https://bugs.openjdk.java.net/browse/JDK-8230863 first ? without it, do we need to have the specified runtime installed on the dev machine to copy dlls from ?, otherwise we can create the app without the target runtime. 2.) native launcher works fine when runtime exists where it is specified, but we could improve error messaging when runtime is not installed. 3.) do we need full path to runtime, or based on runtime-name could we look in (windows example) "C:\Program Files\<runtime-name>, C:\Users\<user-name>\AppData\Local\<runtime-name>" or those names adding <vendor> sub-dir
27-01-2020
Support for packaging application without java runtime is not part of JEP 343 and may be considered for a future release.
18-04-2019