Alternative to fatJar - modular solution?

[Glavo]

>
> 1. Why do you need it to be a single file?


Because it's convenient. In any case, a single file is more convenient
than multiple files. I believe this is the reason why fatjar is popular.
A single file is more robust (easier to ensure integrity), easier to
distribute, easier to deploy, easier to copy and move without missing,
more portable...We can avoid many simple but boring actions, e.g.,
unzip, enter and exit folders, create shortcuts or launch scripts,
specify replication override policies, and more. These piecemeal steps
are very simple, but we get tired of it when we often do them. Using
single file distribution can avoid many of them.

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?


Because platform based operation is very cumbersome and frustrating.

As an example, we have developed many cross platform tools in Java,
which work well on any platform with JDK. They range in size from tens
of KB to tens of MB, can be easily distributed without compressing
and decompressing again, don't worry about losing some files at all...

What happens if we use jlink? We need to care about every platform,
even if the program works well on any platform. We need to prepare
a separate distribution for each of them: Seven mainstream platforms
(Windows x86, Windows x86-64, Windows AArch64, Linux x86-64,
Linux AArch64, Mac OS x86-64, Mac OS AArch64), some non mainstream
platforms but we have users (Linux ARM32, Linux MIPS64el, Linux LoongArch64,
FreeBSD x86-64), and some platforms with potential users (Linux PPC64le,
Linux s390x, AIX PPC64le, and more).

This is crazy. This will make our build process more cumbersome. We have
to pay service providers from tens to thousands of times the cost of
storage and bandwidth. What will we get? Worse cross platform, more
bloated software, more cumbersome use steps and longer download time,
but there is no better user experience.

As for my server deployment... Whether it is a traditional deployment
scheme or a container scheme such as docker, I don't understand what
benefits jlink can bring to me. I don't think I need to provide a
reason for this, because only when I'm crazy will I use jlink to deploy
my server.

3. How do you distribute updates to your fat JARs at present, if at all?


Because it has only one file, it is an acceptable choice to directly
let users download and overwrite. Because it's not cumbersome and
almost error free.

Of course, we still have a simple automatic update mechanism. We only
need to download the new version file as a temporary file, exit the
program itself, start the new version with specific parameters, and
let the new version program overwrite the old file.

 4. How do you distribute and install the JRE at present?


It is feasible for users to install themselves, because this only needs
to be done once. However, for some platforms (especially windows),
we attached an exe file as the launcher before jar (this is allowed by
ZIP format, so it is both exe and jar). The function of automatically
downloading JRE can be implemented in launcher.

...like proper online updates or how to keep the underlying "JRE" up to
> date...
>

I think jlink has only a negative meaning for automatic update. It makes
it impossible for programs to update themselves without upgrading the
runtime. The need to upgrade the Java runtime is far less than the n
eed to upgrade only the program itself, this will only result in a
lot of meaningless bandwidth expenditure.

 It is no more difficult to detect and upgrade the version of Java
runtime alone than to upgrade applications bundled with JRE. In some
cases, jlink does make sense to me, but I will only use it to tailor
JRE and still keep the application independent, which will allow us
to choose a more flexible and fast upgrade strategy.

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

I think this is a very frustrating development direction, which is
giving up one of the biggest advantages of Java. I will consider
giving up Java gradually because there are more and better choices
waiting for me, if regardless of its advantages as a platform.

I really don't understand why Java chose this direction. This may have
some value in the client, but it really lacks meaning on the server.
In the most widely used server of Java, it is not a difficult problem
to ensure the Java version. Whether we install Java globally or use
docker, it is better than jlink. Because upgrading Java is rarely
considered, bundling JRE is often just a hindrance to deployment, and
fatjar is often easier to use and faster.

Mike Hearn <mike at plan99.net> 于2021年10月7日周四 上午1:45写道：

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