Alternative to fatJar - modular solution?

[Gregg G Wonderly]

Desktop apps have long been passed around as single jars.  I have done all kinds of things to pack fatjars full of things that needed recursive unpacking.  Including JNI shared libraries that I could then load to provide missing OS support functions not in Java.

Sent from my iPhone

> On Oct 7, 2021, at 3:05 AM, Glavo <zjx001202 at gmail.com> wrote:
> 
> Of course, this is feasible and will not introduce many new problems
> like jlink. It's just not that convenient. It just introduces some
> additional deployment steps, which is not so convenient. I believe that
> it is very attractive to only distribute and deploy a single file,
> which is proved by the popularity of fatJar and Golang.
> 
> Mantas Gridinas <mgridinas at gmail.com> 于2021年10月7日周四 下午3:35写道：
> 
>> I am a tad bit confused. How come packaging everything into a regular zip
>> file and extracting it during deployment is not feasable solution? If
>> anything, you retain ability to do partial updates to your deployments.
>> Such approach also removes the need for special classloader that is capable
>> of loading nested jars. This in turn makes packaging and runtime much
>> simpler too, as you dont need to repackage the runtime jar.
>> 
>>> On Thu, Oct 7, 2021, 06:57 Glavo <zjx001202 at gmail.com> wrote:
>>> 
>>> Emmm... My words caused some misunderstanding. I should say that jpackage
>>> is good, but without it, we can easily achieve the same function in
>>> other ways, so it doesn't cause real trouble. What really causes trouble
>>> and needs to be solved by fatjar is a different problem. It is difficult
>>> for me to achieve close results by third-party means (e.g., let's bundle
>>> program jars in lancher jar, decompress them to a temporary location
>>> at runtime and load them dynamically. But compared with this scheme,
>>> I would rather give up JPMS and go back to fatJar).
>>> 
>>> Ioi Lam <ioi.lam at oracle.com> 于2021年10月7日周四 上午8:36写道：
>>> 
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 
>>> 
>>