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

[Glavo]

>
> 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.
I've started a new project [1] that I believe will be far more meaningful
to most people than jlink.

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/20230918/c80d3da4/attachment-0001.htm>