Alternative to fatJar - modular solution?

[Ioi Lam]

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.stenzel at 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 <zjx001202 at 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.