Alternative to fatJar - modular solution?

[Samuel Audet]

Hi,

There are many reasons why modules have not become popular, but this is 
a new interesting perspective. Thanks for bringing this up! I also 
believe modules need to support uber JARs to become relevant...

Samuel

On 10/7/21 2:24 AM, Glavo 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.
>