Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Ron Pressler]

> On 6 Sep 2023, at 13:16, Glavo <zjx001202 at gmail.com> wrote:
> 
> Why? You can now easily pick whichever runtime you want (a minimal one is only 40MB!) and not require the end user to install Java or even know that your application is written in Java. Also, the proposed change would have no impact on anyone using a client JRE (8 is the *highest* version for which a JRE is available).
> 
> At least for us, 40M is very large. 
> 
> We have an application, and we carefully ensure that the application size is within 5MB.
> An increase in program size means a multifold increase in server network expenditures.
> Not all parts of the world have the same cheap internet access, nor are free CDNs available everywhere.

But you’re requiring your users to download the JDK, which is ~300MB.

In any event, if your placing the responsibility of choosing an appropriate runtime on your users, then surely your users need to know that a particular version of the application may not run on all versions of the runtime. If they’re required to assemble your application together, they are the just the right target for the warning.

> 
> Also, jimage is not suitable for all scenarios.
> We provide support for Windows (x86, x86-64, ARM64), Linux (x86, x86-64, ARM32, ARM64, MIPS64EL, LoongArch64, RISC-V 64), macOS (x86-64, ARM64) equally.
> We only need to distribute a jar file of less than 5MB to work on these platforms.
> jlink? Do you mean we have to distribute a dozen huge programs at a time?
> 

jlink supports all platforms for which there’s a supported runtime. Again, someone has to obtain a runtime and assemble the application, either you or your users (and it’s a smaller distribution if it comes from you). If you want your users to find and supply the runtime, they need to be aware of any compatibility issue between the runtime they need to obtain and your application.


> But we are looking forward to a better alternative than shadow jar.
> I think it is an unfortunate fact that the module path and classpath must be specified, and many people want to get rid of it,
> which is why the shadow jar plugin is so popular. 
> So I don't think "the Java program already needs a lot of options" is a reason to keep adding more options that have to be used.
> Why can't we integrate this information inside the program?

You can have all these things, and we’ve worked very hard to provide them to you. The solution is called jlink, but if choose not to use it, you’ll still have all those problems.

Now, a shadow JAR isn’t anywhere close to one file anymore because the JRE is gone. It’s one 5MB file plus 300MB of many JDK files (aimed at developers, not users) that your users must download and manage.

> When we have to use startup scripts, we sacrifice some cross-platform capabilities, and make it harder for users to configure the JVM in a standard way.
> They have to use the one provided by the script, or the JAVA_TOOL_OPTIONS environment variable.
> Before that, they need to distinguish between "necessary options for the program" and "unnecessary tuning options" provided by default by scripts mixed together,
> carefully avoid their options conflicting with the default options.

If you’re talking about users who may want to configure JVM options, then these are very sophisticated users, because that’s a very sophisticated configuration.

> In addition, since the startup script and the program bytecode are not bundled in the same file, users may mistakenly update only part of the program, 
> resulting in a mismatch between the startup script and the program, causing the program to crash during runtime.

Again, you’re talking about users who are really developers (or at least sophisticated operations users). Nevertheless, you may search the mailing lists for recent discussions about “Hermetic Java”. The application will still be as large as a jlinked-one (though not nearly as large as what you have now, which requires the JDK), all in one file. 

> 
> jlink and jpackage are suitable for some scenarios, but they are not suitable for many scenarios.

Perhaps, but they are, however suitable for the scenarios you’ve described.

> Many times, a single file that does not require complex configuration, is not bundled with JRE, and can be directly cross-platform is more popular.
> We are looking forward to an official replacement for the shadow jar so that we can use JPMS more.

You asked and we delivered. That official replacement is jlink. In the future it may be enhanced by something similar to Hermetic Java.

— Ron