Alternative to fatJar - modular solution?

[Mike Hearn]

-jdk-dev

I'm currently working on a new packaging product for JVM apps so this sort
of request is of interest. However it produces platform native packages,
not uber-jars. May I ask:

1. Why do you need it to be a single file?
2. Why an installable jlinked image doesn't meet your workflow
requirements? Is it about the difficulty of creating an e.g. MSI / DEB, or
is it about the difficulty of installing them for the end user?
3. How do you distribute updates to your fat JARs at present, if at all?
4. How do you distribute and install the JRE at present?

Technically, making a launcher for a new generation of fat JAR that
supports JPMS better is quite easy. However, that doesn't solve a whole lot
of other problems, like proper online updates or how to keep the underlying
"JRE" up to date. The direction of travel set by OpenJDK is away from the
notion of a general runtime and towards bundled and customized runtimes for
each application, so I suspect trying to keep fat JARs alive is mostly just
pushing the problem around rather than solving it.



On Wed, Oct 6, 2021 at 7:24 PM Glavo <zjx001202 at gmail.com> wrote:

> 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.
>