On Oct 7, 2021, at 7:41 AM, Glavo <zjx001...@gmail.com> wrote:
*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?
Ah, in fact, in Chinese mainland, server bandwidth is a very real
problem. In China, many websites such as GitHub and cloudflare cannot
provide services normally. The cost of civil broadband is low, but
commercial bandwidth is more expensive, which costs several times or
even more than ten times higher than other parts of the world.
Our average income level also lags behind that of developed countries,
so we will pay more attention to the cost of bandwidth.
Mike Hearn <m...@plan99.net> 于2021年10月7日周四 下午7:31写道：
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@hydraulic.software and maybe your needs can influence our product
direction.
