Alternative to fatJar - modular solution?

[Mike Hearn]

Thanks for your insightful reply, Glavo. Here are some thoughts. I should
note that I don't work for Oracle or on OpenJDK, in case that wasn't
already clear.

*Forum.* Although it's logical that you ended up on this list,
realistically the JPMS is "done" and not being worked on since Java 9. Any
solutions or improvements have to come from the user community so it may
make more sense to have this discussion on Reddit, or some other Java forum.

*Alternative approach. *Given this constraint, it can make sense to think
wider or bigger than just updating previous approaches. Would your needs be
met or even met better by a re-imagining of Web Start, but one suitable for
servers and the CLI? For example:

$ alias glavos="jrun glavos-cool-app.com"
$ glavos --flag --another-flag

Here an imaginary "jrun" command (re)downloads an app and stores it to a
local cache, perhaps downloading an appropriate JVM/jlinked image alongside
it if none is available already locally. It's given a URL but in a
convenient form for typing, e.g. with assumed protocols and paths if only a
domain name is specified. The tool would occasionally check for updates and
run from the cache the rest of the time. This doesn't make apps into a
single file but it tackles other problems you mention having to roll your
own solutions for, like writing your own update checker and asking users to
download the right file. Unlike tools like apt-get or brew there would be
no notion of adding a repository beforehand, so for CLI / server apps, it
retains its usability.

For desktop apps a simple .jrun file association could be used to do the
same thing.

For building Docker images you could have:

$ jrun --cache-only glavos-cool-app.com

which would populate a cache during the docker build, but not run the
program itself.

I've often wished for such a tool. At one point I built one that did Maven
resolution, but it for GUI apps. Although my new venture is about
self-updating desktop/server app packages, I've been planning an extension
in this direction later because once you can distribute a generic runtime
as a self-updating "app" you can easily bring back the JRE model for those
who want it.

*Jimage.* In your first mail you proposed a new kind of fat-jar based on
the jimage format the modules file uses. JImage isn't a documented format,
or rather, it's documented only in the source code, but it has quite a
clever design. The upside is that it's highly optimized. The downsides are:

1. Write only. ZIPs have some basic support for editing but jimage doesn't.
This is a pain for things like config files, where you may want to make
specialized versions of an app by adjusting the internal files. It can be
easily fixed using a classloader that checks local disk for resources first.

2. No built-in support for native code libraries. There was a related
discussion of this problem a week or so ago on this list. Of course, JARs
have the same problem.

3. No support for multiple versions of the same JAR in the same file, even
though the core JPMS *can* support this via the
defineModulesWithManyLoaders API, and even though this would be a very
useful thing to support. Fat JARs have the same problem so this is not a
downside compared to the status quo.

4. The format is deliberately undocumented so it can be changed in future
JVM versions. Thus using it would actually mean cloning it, and/or
rewriting parts of the code because otherwise the GPL2 might kick in.

Overall, the downsides are not that big! The worst is the need to clone the
format to avoid depending on JVM internals. On the other hand, ZIPs work
well enough and don't require writing any new code except a little stub
entry point that uses custom classloaders.

*Bandwidth optimization and rare machines.* This is interesting because
it's a requirement that feels like it may be more common in China than
elsewhere. I'd be keen to learn more about your bandwidth constraints,
unless this is more of a theoretical concern?

You mention you actually have users on LoongArch64 for example. Indeed, the
chances that non-Chinese developers will produce jlinked images for this
CPU any time soon is very low.

*Product potential.* As mentioned, I'm setting up a new venture that is
starting with app distribution, and particularly distribution for the JVM
world. JPackage is good as far as it goes, but it doesn't solve all the
problems developers face. Given your list of target machines it feels like
you're probably a commercial organization with a wide customer base. If
you're in the market for better approaches please send an email to
mike at hydraulic.software and maybe your needs can influence our product
direction.