On 10/6/21 12:45 PM, Glavo wrote:
I know this doesn't remotely satisfy all your requirements, but are you
aware you can jpackage an app *without* bundling a JRE?
Ah, this is what I missed, but it won't solve any of my problems, otherwise
I have implemented a similar function by myself.
Doesn't jpackage always bundle a Java runtime with the app? From the docs:
https://docs.oracle.com/en/java/javase/17/jpackage/packaging-overview.html
"To eliminate the need for users to install a Java runtime, one is
packaged with your applications. The packaging tool generates a runtime
image based on the packages or modules that your application needs.
If no Java runtime image is passed to the packaging tool, then jpackage
uses the jlink tool to create a runtime for the application."
Thanks
- Ioi
Sebastian Stenzel <sebastian.sten...@gmail.com> 于2021年10月7日周四 上午2:06写道：
Interesting topic and I'm keen to know what is the answer to the general
problem of modular fat or shaded jars.
I know this doesn't remotely satisfy all your requirements, but are you
aware you can jpackage an app *without* bundling a JRE?
Am 06.10.2021 um 19:25 schrieb Glavo <zjx001...@gmail.com>:
For a long time, unpacking and repackaging all dependencies into a file
called fatJar was the first choice for single file distribution of Java
programs. However, the compatibility of this solution with JPMS is very
poor - it breaks up all the modules and works with classpath.
I think many programmers may expect JDK to provide a native lightweight
solution that bundles multiple modules into a single file. From users'
enthusiasm for fatjar, we can see that they have a keen demand for such
a format. jlink and jpackage cannot solve the problem that fatjar wants
to solve. We now have the jimage file format, but it seems that it is
only the internal format of JDK and is only used in the modules file.
The lack of such a solution has caused us some trouble about whether to
modularize. So I earnestly request JDK to add support for such a file
format:
1. It can bundle multiple modules in one file (It may be based on jimage
or other compression/archive format).
2. It should only bundle application dependencies without carrying JDK
standard library or even complete JRE.
3. It should have a manifest file like the MANIFEST.MF for jar,
allows we to add descriptions of entry points, Add-Opens, module path,
and so on.
4. Allows simple execution, such as `java -jimage foo.jimage`. In
this case, use the contents described in the above manifest file.
5. Associate this file format during JDK/JRE installation, and
execute it in the above manner when double clicking it.
6. Like the ZIP (JAR) format, allow other content to be appended
before its content. This makes it easy to attach a launcher (usually
exe or bash) before its content.
