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

[Rony G. Flatscher]

On 17.09.2023 22:31, Glavo wrote:
>
>     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.
>
>
> As the developer, compatibility problems should be resolved by me. But even after I solved the 
> problem, Java still gave false warnings.
>
>     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.
>
>
> There is no misunderstanding here. I understand how jlink works, but a program that 
> supports plugins is built without knowing the std modules that the plugin requires, so it needs a 
> "more complete" runtime.
> Therefore, it makes no sense for users to use jlink to build runtime themselves. It is a better 
> choice to directly use the "JRE" provided by the vendor.
>
>     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).
>
>
> For some applications, the new deployment model does have advantages.
> But for more programs, it either has no advantages or gives up the unique advantages of Java and 
> becomes an inferior alternative to Golang.
>
> I realized I shouldn't continue this topic, it was just a waste of my time.

It is still very important IMHO, maybe the communication in the thread starting with 
<https://mail.openjdk.org/pipermail/panama-dev/2023-September/019869.html> (moved to panama-dev per 
Mark Reinhold's suggestion) can help explain the problem at hand?

> I've started a new project [1] that I believe will be far more meaningful to most people than jlink.

Very interesting. Have you considered jpackage (JEP 392, <https://openjdk.org/jeps/392>) too? What 
would be the difference compared to your idea?

---rony


> Glavo
>
> [1]: https://github.com/Glavo/japp
>
>
> On Thu, Sep 7, 2023 at 9:08 PM Ron Pressler <ron.pressler at oracle.com> wrote:
>
>
>
>     > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230919/14473a92/attachment-0001.htm>