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

[Ron Pressler]

You may do your own calculation and choose to give your users the responsibility of assembling your application. But if you choose to do that, there are tradeoffs involved, because there may be incompatibilities between the two parts of your application that you’re asking your users to assemble. That has *always* been the case, but more so in the last five years since we’ve given application authors the simple option of assembling the application themselves and ensuring there are no incompatibilities. In that time, we’ve emitted warnings to prepare whoever it is that assembles the application to prepare for a future incompatibility.

It’s reasonable to choose to assemble the application yourself and ensure there are no incompatibilities, making life easier for your users. In your case, you may also decide that it’s reasonable to task your users with assembling your application and dealing with potential incompatibilities. But I don’t think it’s reasonable to task someone else with assembling the application and then ask us not to issue a warning about an incompatibility to them. Anyway, this has been the policy for the past five years and there’s nothing unusual here.

To answer your question about Java being a dependency: absolutely not. That was the situation until JDK 11. Things changed. They are not as they used to be. Now the recommended (though not enforced) distribution model is one that puts the responsibility on the application author, or at least gives them the choice. Ever since we did away with the JRE, application users need not (and the recommendation is that they should not) bother themselves with obtaining a Java runtime (and, to the best of my knowledge, no vendors offers a runtime with the same qualities of the JRE, RIP, that optimise it for an end-user experience).

BTW, if you’re worried about your uplink cost and want to pass that on to JDK/Java runtime providers, you can have a launcher that downloads the appropriate runtime rather than ask your users to obtain it themselves, but that’s also up to you. Either way, thanks to years of hard work, Java now offers an easy way for your application to control all aspects of the runtime. Use it or don’t, but you’ll have to accept the tradeoffs either way.

— Ron

> On 6 Sep 2023, at 16:58, Glavo <zjx001202 at gmail.com> wrote:
> 
> But you’re requiring your users to download the JDK, which is ~300MB.
> 
> Specifically, where we are (mainland China), home broadband is very cheap, but commercial broadband is more expensive.
> The cost of commercial uplink bandwidth can exceed five hundred times that of home downlink bandwidth.
> For us, getting users to download more content is irrelevant, but the cost to the distributor of the content is painful.
> 
> Also, it is not true that users need to download the complete JDK.
> "JRE is deprecated" is just a technical talk.
> In reality, JDK vendors usually provide a small JDK image called "JRE", which is sufficient for users.
> You can't prevent users from downloading these small images provided by the vendor just because "JRE is deprecated".
> 
> 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.
> 
> If the operating environment cannot satisfy our program, we will actively report to the user and exit.
> We don't need these false warnings to drown out our real warnings,
> 
> Additionally, even if JNI/Panama is not available, our programs can safely fall back to other implementations.
> The only way our program can crash because of FFI is if you crash it on purpose.
> 
> 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.
>  We should be the ones with the knowledge, so why should control of these warnings be in the hands of users who may know nothing about it?
> They just need to download the JRE from the place specified in our documentation or install it through the package manager.
> We have almost a million users, most of whom don't know Java, but few complain about it.
> 
> 
> As for the other things you said, I won’t reply to them one by one.
> You seem to want users to feel that treating Java as an internal part of the program is the only way to use it?
> Isn't Java more often seen as a dependency, as a platform?
> For Windows users, they just need to download the MSI installer for JDK or JRE (in a broad sense), install it, and double-click to run the program.
> For Linux users, they only need to enter `apt install default-java` or `pacman -S jdk-openjdk`, as they often do, and then run the program.
> 
> You asked and we delivered. That official replacement is jlink. In the future it may be enhanced by something similar to Hermetic Java.
> 
> The shadow jar is based on Java as a platform, jlink is not a direct replacement.
> 
> The frequency with which the program itself is updated does not often match the frequency with which Java is updated, either for the server or the user.
> 
> For servers, we tend to think of Java as part of the environment. They often require special processes to be updated and do not need to be updated every time the program is updated.
> They can be part of the base image.
> In this case, deploying shadow jars is far more convenient and faster than using jlink and requires less transmission.
> This is a usage scenario I often see.
> 
> As a user, I have many small tools developed in Java. None of them require a fixed Java version, only a minimum Java version.
> I'd much rather install just one JDK than have dozens of jlink-generated images containing JVMs.
> 
> So, I agree with the point of jlink, but I still think another replacement for the shadow jar is necessary.
> 
> Glavo
> 
> 
> On Wed, Sep 6, 2023 at 8:51 PM Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> > 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
> 
>