Alternative to fatJar - modular solution?

Glavo zjx001202 at gmail.com
Thu Oct 7 01:38:12 UTC 2021


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


More information about the jigsaw-dev mailing list