<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 17.09.2023 22:31, Glavo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJL5A3m5TO95w8cZW4b7KSdxHDMDYhxCB359jxMtmAjPHLRV7Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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 class="moz-txt-link-rfc2396E" href="https://mail.openjdk.org/pipermail/panama-dev/2023-September/019869.html"><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"
cite="mid:CAJL5A3m5TO95w8cZW4b7KSdxHDMDYhxCB359jxMtmAjPHLRV7Q@mail.gmail.com">
<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 class="moz-txt-link-rfc2396E" href="https://openjdk.org/jeps/392"><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"
cite="mid:CAJL5A3m5TO95w8cZW4b7KSdxHDMDYhxCB359jxMtmAjPHLRV7Q@mail.gmail.com">
<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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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>
</body>
</html>