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

[Ron Pressler]

> On 7 Sep 2023, at 04:09, Glavo <zjx001202 at gmail.com> wrote:
> 
> Yes, my program may not be compatible with the runtime. If I find a problem like this, I open an issue and fix it. 
> However I have no way to work with JPMS to report it to the user's Java, so the user's Java will continue to scare the user into dealing with non-existent problems with false warnings.

I don’t know what you mean by “work with JPMS”, and the warning is not about a non-existent problem but about a very real upcoming compatibility issue, that whoever chooses the runtime must deal with.

> 
> jlink is really good for a small subset of programs, but it is not suitable for many programs.
> 
> For servers, Java versions tend to be stable and unchanging. It is a better choice to package this stable environment into a basic image and only update the program itself each time.
> For small utilities, an important reason to choose Java is cross-platform. The reason I prefer Java over Golang is that I don't need to distribute different binaries for different architectures.

The old JRE model indeed had its upsides, but it also suffered from serious downsides. There has always been a program/runtime potential incompatibility problem with the old model that application authors had to deal with. We’ve worked for *years* to deliver a solution to that problem. Sure, maybe it’s not entirely free, but no solution to such a hard problem would be. The new Java deployment model has, overall, more upsides and fewer downsides. 

I think what you’re saying is that you wish we’d found a way to provide the new model for all those who’ve asked for it, and in addition somehow solve the incompatibility problem within the old model. I doubt that is possible, and in any event it’s not practically possible because we don’t have the resources work on a new thing and an old thing forever, so we’ve picked whatever we think gives the best tradeoff overall.

Yes, you may choose to use to use something similar to the old model (although I don’t think you’ve properly evaluated the new one), but in that case you must live with its downsides and suffer from the very problems the new solution was created to solve. In particular, those who assemble your application, must be warned about any upcoming incompatibility, just as they have been warned over the last five years (first with encapsulation, then with SecurityManager, and in JDK 21 with dynamically loaded agents).


> Small utilities usually do not have strict requirements on the Java version and can be used as long as a package such as default-java is installed through the package manager.
> Using jlink will expand the program size dozens or even hundreds of times and make it more difficult to update.
> 
> jlink is really suitable only for medium or large applications that do not support plugins.

Jlink is suitable for small, medium, or large applications, with or without plugins. With further work on Leyden it will become even better in all these cases.

Since you’ve brought up plugins, I’m afraid you might misunderstand something about what jlink does. Jlink produces something called a runtime image, which is made up of modules. *On top* of that runtime, you run your regular Java application, which can have plugins, load things dynamically, etc.. As an option you can choose to take your application and ask jlink to also bake it into the runtime image so that there’s no more application on top, but you really don’t have to do that, nor is that the common way people use jlink.

— Ron