Alternative to fatJar - modular solution?

[Mantas Gridinas]

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