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

[Glavo]

>
> But you’re requiring your users to download the JDK, which is ~300MB.
>

Specifically, where we are (mainland China), home broadband is very cheap,
but commercial broadband is more expensive.
The cost of commercial uplink bandwidth can exceed five hundred times that
of home downlink bandwidth.
For us, getting users to download more content is irrelevant, but the cost
to the distributor of the content is painful.

Also, it is not true that users need to download the complete JDK.
"JRE is deprecated" is just a technical talk.
In reality, JDK vendors usually provide a small JDK image called "JRE",
which is sufficient for users.
You can't prevent users from downloading these small images provided by the
vendor just because "JRE is deprecated".

In any event, if your placing the responsibility of choosing an appropriate
> runtime on your users, then surely your users need to know that a
> particular version of the application may not run on all versions of the
> runtime. If they’re required to assemble your application together, they
> are the just the right target for the warning.
>

If the operating environment cannot satisfy our program, we will actively
report to the user and exit.
We don't need these false warnings to drown out our real warnings,

Additionally, even if JNI/Panama is not available, our programs can safely
fall back to other implementations.
The only way our program can crash because of FFI is if you crash it on
purpose.

jlink supports all platforms for which there’s a supported runtime. Again,
> someone has to obtain a runtime and assemble the application, either you or
> your users (and it’s a smaller distribution if it comes from you). If you
> want your users to find and supply the runtime, they need to be aware of
> any compatibility issue between the runtime they need to obtain and your
> application.
>

We should be the ones with the knowledge, so why should control of these
warnings be in the hands of users who may know nothing about it?
They just need to download the JRE from the place specified in our
documentation or install it through the package manager.
We have almost a million users, most of whom don't know Java, but few
complain about it.


As for the other things you said, I won’t reply to them one by one.
You seem to want users to feel that treating Java as an internal part of
the program is the only way to use it?
Isn't Java more often seen as a dependency, as a platform?
For Windows users, they just need to download the MSI installer for JDK or
JRE (in a broad sense), install it, and double-click to run the program.
For Linux users, they only need to enter `apt install default-java` or
`pacman -S jdk-openjdk`, as they often do, and then run the program.

You asked and we delivered. That official replacement is jlink. In the
> future it may be enhanced by something similar to Hermetic Java.
>

The shadow jar is based on Java as a platform, jlink is not a direct
replacement.

The frequency with which the program itself is updated does not often match
the frequency with which Java is updated, either for the server or the user.

For servers, we tend to think of Java as part of the environment. They
often require special processes to be updated and do not need to be updated
every time the program is updated.
They can be part of the base image.
In this case, deploying shadow jars is far more convenient and faster than
using jlink and requires less transmission.
This is a usage scenario I often see.

As a user, I have many small tools developed in Java. None of them require
a fixed Java version, only a minimum Java version.
I'd much rather install just one JDK than have dozens of jlink-generated
images containing JVMs.

So, I agree with the point of jlink, but I still think another replacement
for the shadow jar is necessary.

Glavo


On Wed, Sep 6, 2023 at 8:51 PM Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 6 Sep 2023, at 13:16, Glavo <zjx001202 at gmail.com> wrote:
> >
> > Why? You can now easily pick whichever runtime you want (a minimal one
> is only 40MB!) and not require the end user to install Java or even know
> that your application is written in Java. Also, the proposed change would
> have no impact on anyone using a client JRE (8 is the *highest* version for
> which a JRE is available).
> >
> > At least for us, 40M is very large.
> >
> > We have an application, and we carefully ensure that the application
> size is within 5MB.
> > An increase in program size means a multifold increase in server network
> expenditures.
> > Not all parts of the world have the same cheap internet access, nor are
> free CDNs available everywhere.
>
> But you’re requiring your users to download the JDK, which is ~300MB.
>
> In any event, if your placing the responsibility of choosing an
> appropriate runtime on your users, then surely your users need to know that
> a particular version of the application may not run on all versions of the
> runtime. If they’re required to assemble your application together, they
> are the just the right target for the warning.
>
> >
> > Also, jimage is not suitable for all scenarios.
> > We provide support for Windows (x86, x86-64, ARM64), Linux (x86, x86-64,
> ARM32, ARM64, MIPS64EL, LoongArch64, RISC-V 64), macOS (x86-64, ARM64)
> equally.
> > We only need to distribute a jar file of less than 5MB to work on these
> platforms.
> > jlink? Do you mean we have to distribute a dozen huge programs at a time?
> >
>
> jlink supports all platforms for which there’s a supported runtime. Again,
> someone has to obtain a runtime and assemble the application, either you or
> your users (and it’s a smaller distribution if it comes from you). If you
> want your users to find and supply the runtime, they need to be aware of
> any compatibility issue between the runtime they need to obtain and your
> application.
>
>
> > But we are looking forward to a better alternative than shadow jar.
> > I think it is an unfortunate fact that the module path and classpath
> must be specified, and many people want to get rid of it,
> > which is why the shadow jar plugin is so popular.
> > So I don't think "the Java program already needs a lot of options" is a
> reason to keep adding more options that have to be used.
> > Why can't we integrate this information inside the program?
>
> You can have all these things, and we’ve worked very hard to provide them
> to you. The solution is called jlink, but if choose not to use it, you’ll
> still have all those problems.
>
> Now, a shadow JAR isn’t anywhere close to one file anymore because the JRE
> is gone. It’s one 5MB file plus 300MB of many JDK files (aimed at
> developers, not users) that your users must download and manage.
>
> > When we have to use startup scripts, we sacrifice some cross-platform
> capabilities, and make it harder for users to configure the JVM in a
> standard way.
> > They have to use the one provided by the script, or the
> JAVA_TOOL_OPTIONS environment variable.
> > Before that, they need to distinguish between "necessary options for the
> program" and "unnecessary tuning options" provided by default by scripts
> mixed together,
> > carefully avoid their options conflicting with the default options.
>
> If you’re talking about users who may want to configure JVM options, then
> these are very sophisticated users, because that’s a very sophisticated
> configuration.
>
> > In addition, since the startup script and the program bytecode are not
> bundled in the same file, users may mistakenly update only part of the
> program,
> > resulting in a mismatch between the startup script and the program,
> causing the program to crash during runtime.
>
> Again, you’re talking about users who are really developers (or at least
> sophisticated operations users). Nevertheless, you may search the mailing
> lists for recent discussions about “Hermetic Java”. The application will
> still be as large as a jlinked-one (though not nearly as large as what you
> have now, which requires the JDK), all in one file.
>
> >
> > jlink and jpackage are suitable for some scenarios, but they are not
> suitable for many scenarios.
>
> Perhaps, but they are, however suitable for the scenarios you’ve described.
>
> > Many times, a single file that does not require complex configuration,
> is not bundled with JRE, and can be directly cross-platform is more popular.
> > We are looking forward to an official replacement for the shadow jar so
> that we can use JPMS more.
>
> You asked and we delivered. That official replacement is jlink. In the
> future it may be enhanced by something similar to Hermetic Java.
>
> — Ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230906/2846e6ac/attachment-0001.htm>