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

[Glavo]

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

First, it is extremely tempting to package a program into a single
executable file. Whether it is distribution, installation, management,
upgrade, or uninstallation, it becomes very simple.
For the old deployment model, although users had to install Java, the
related matters were already handled by the Java vendor. For program
developers, they can enjoy the benefits of a single executable file.
But if we need to use jlink/jpackage, then this part of the responsibility
shifts to the program developer. Many times this is more of a headache than
dealing with program compatibility issues with Java.

Next is something I've said a few times.

For small utility programs, using jlink will bloat the program size to the
point where it becomes annoying to the user, while at the same time the
binary files losing cross-platform capabilities.
I get a little benefit out of it, but at the cost of all the reasons I
chose Java. I would choose to rewrite the program in Golang, which will
make the program smaller, start faster, and have a lower memory footprint.

For servers, programs change much more frequently than for Java, I would
like to install Java into the system or base image.
The server environment is stable and controllable, and I understand
everything about this environment.
Since I understand the Java environment, it is impossible for the program
to be incompatible with Java.
There is nothing that needs to be solved by jlink. Using jlink will make
building and deploying more cumbersome.

Finally my complaint as an end user.

With the old deployment model, programs defaulted to running on all
platforms where Java was available, unless the developer explicitly
declined.
But for jlink, program developers need to provide distribution for each
platform.
Because Java has excellent cross-platform capabilities, program developers
may not know all the platforms on which their programs can run.
This will make it impossible to run programs on many platforms on which
they would otherwise run.

I am a user of Debian RISC-V 64 and Arch Linux LoongArch 64 and now I can
easily run JetBrains GoLand on these platforms.
But if JetBrains had used jlink, the experience would never have been so
pleasant.
This is the same for other programs. The program's developer must provide
distribution for each platform.
It's worth noting that a single Java vendor often doesn't provide support
for all platforms.
As far as I know, builds for Linux RISC-V 64 are now only available from
the Linux distribution's software repositories.
So as a user, I can only ask developers to perform some cumbersome
operations to provide support for these niche platforms. I think such a
request would be rejected by most developers.
I think this is terrible.

Glavo


On Tue, Sep 19, 2023 at 5:39 PM Rony G. Flatscher <Rony.Flatscher at wu.ac.at>
wrote:

> 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>
> <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> <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/20230920/12405a00/attachment-0001.htm>