<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Very interesting. Have you considered jpackage (JEP 392, <a href="https://openjdk.org/jeps/392" target="_blank"><https://openjdk.org/jeps/392></a>) too? What would be the difference compared to your idea?<br></blockquote><div><br></div><div>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.<br></div><div>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.<br></div><div>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.<br></div><div><br></div><div>Next is something I've said a few times.<br></div><div><br></div><div>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.<br></div><div>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.</div><div><br></div><div>For servers, programs change much more frequently than for Java, I would like to install Java into the system or base image.<br></div><div>The server environment is stable and controllable, and I understand everything about this environment.<br></div><div>Since I understand the Java environment, it is impossible for the program to be incompatible with Java.<br></div><div>There is nothing that needs to be solved by jlink. Using jlink will make building and deploying more cumbersome.<br></div><div><br></div><div>Finally my complaint as an end user.<br></div><div><br></div><div>With the old deployment model, programs defaulted to running on all platforms where Java was available, unless the developer explicitly declined.<br></div><div>But for jlink, program developers need to provide distribution for each platform.<br></div><div>Because Java has excellent cross-platform capabilities, program developers may not know all the platforms on which their programs can run.<br></div><div>This will make it impossible to run programs on many platforms on which they would otherwise run.<br></div><div><br></div><div>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.<br></div><div>But if JetBrains had used jlink, the experience would never have been so pleasant.<br></div><div>This is the same for other programs. The program's developer must provide distribution for each platform.<br></div><div>It's worth noting that a single Java vendor often doesn't provide support for all platforms.<br></div><div>As far as I know, builds for Linux RISC-V 64 are now only available from the Linux distribution's software repositories.<br></div><div>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.<br></div><div>I think this is terrible.<br></div><div><br></div><div>Glavo</div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 19, 2023 at 5:39 PM Rony G. Flatscher <<a href="mailto:Rony.Flatscher@wu.ac.at" target="_blank">Rony.Flatscher@wu.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 17.09.2023 22:31, Glavo wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
</blockquote>
<div><br>
</div>
<div>As the developer, compatibility
problems should be resolved by
me. But even after I solved the
problem, Java still gave false
warnings.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<font color="#888888"><br>
</font></blockquote>
<div><br>
</div>
<div>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.</div>
<div>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.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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).<br>
</blockquote>
<div><br>
</div>
<div>For some applications, the new
deployment model does have
advantages.</div>
<div>But for more programs, it
either has no advantages or gives
up the unique advantages of Java
and becomes an inferior
alternative to Golang.<br>
</div>
<div><br>
</div>
<div>I realized I shouldn't continue
this topic, it was just a waste of
my time. <br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p>It is still very important IMHO, maybe the communication in the
thread starting with
<a href="https://mail.openjdk.org/pipermail/panama-dev/2023-September/019869.html" target="_blank"><https://mail.openjdk.org/pipermail/panama-dev/2023-September/019869.html></a>
(moved to panama-dev per Mark Reinhold's suggestion) can help
explain the problem at hand?<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>I've started a new project [1]
that I believe will be far more
meaningful to most people than
jlink.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p>Very interesting. Have you considered jpackage (JEP 392,
<a href="https://openjdk.org/jeps/392" target="_blank"><https://openjdk.org/jeps/392></a>) too? What would be the
difference compared to your idea?</p>
<p>---rony<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Glavo<br>
</div>
<br>
<div>[1]: <a href="https://github.com/Glavo/japp" target="_blank">https://github.com/Glavo/japp</a></div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Sep 7, 2023 at 9:08 PM
Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 7 Sep 2023, at 04:09, Glavo <<a href="mailto:zjx001202@gmail.com" target="_blank">zjx001202@gmail.com</a>>
wrote:<br>
> <br>
> Yes, my program may not be compatible with the runtime.
If I find a problem like this, I open an issue and fix it. <br>
> 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.<br>
<br>
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.<br>
<br>
> <br>
> jlink is really good for a small subset of programs, but
it is not suitable for many programs.<br>
> <br>
> 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.<br>
> 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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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).<br>
<br>
<br>
> 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.<br>
> Using jlink will expand the program size dozens or even
hundreds of times and make it more difficult to update.<br>
> <br>
> jlink is really suitable only for medium or large
applications that do not support plugins.<br>
<br>
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.<br>
<br>
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.<br>
<br>
— Ron<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>