Re: Packaging applications with JVM version restrictions
Hi,
> I’m a bit wary of auto-selecting something. I’d instead check whether
> ${JAVA:-java} has the right version and complain when not. Possibly
> check whether $JAVA_HOME is set (which it isn’t in a regular Debian
> one-JRE installation) and use that if suitable instead of complaining.
> (Where complaining means echo "E: some msg" >&2; exit 1)
I find this approach of failing in case the default java alternative is
not matching the expected version to run your application far from ideal.
If you have two java applications, one requiring JDK 11 but not yet 17
compatible and one requiring JDK 17, you can not easily write a script
using both programs.
In order for this to work, it will require both:
- Engineering effort on the applications side to read specific environment variables
- User manual environment setup of the JVM for those application in order to work
The biggest issue is the user manual effort here as it severly affect the user
experience for Java applications. This might be fine if you only have one major
version every 10 years (python 2 to 3). But the JVM has a six months delivery cycle.
This problem is so annoying I even wrote an article about it
https://loicrouchon.com/posts/distributing-java-cli-app/
where I do not have a satisfactory solution.
One possibility could be to provide versioned stable paths or links.
For example:
- /usr/lib/jvm/11/bin/java -> targets the lowest installed JVM which version is greater or equals to 11
- /usr/lib/jvm/17/bin/java -> targets the lowest installed JVM which version is greater or equals to 11
- /usr/lib/jvm/latest/bin/java -> targets the latest installed JVM
This is not perfect as it's not taking the vendor into account but maybe
could default to openjdk. Also, every time a new JDK is installed/removed,
a script to re-generate all of those links would be required.
I also took a look at Fedora and installed JDK 17 and the latest JDK (20)
and see the following things:
# ls -l /usr/lib/jvm
java-17-openjdk-17.0.6.0.10-1.fc37.aarch64
java-20-openjdk-20.0.0.0.36-1.rolling.fc37.aarch64
jre -> /etc/alternatives/jre
jre-17 -> /etc/alternatives/jre_17
jre-17-openjdk -> /etc/alternatives/jre_17_openjdk
jre-17-openjdk-17.0.6.0.10-1.fc37.aarch64 -> java-17-openjdk-17.0.6.0.10-1.fc37.aarch64
jre-20 -> /etc/alternatives/jre_20
jre-20-openjdk -> /etc/alternatives/jre_20_openjdk
jre-20-openjdk-20.0.0.0.36-1.rolling.fc37.aarch64 -> java-20-openjdk-20.0.0.0.36-1.rolling.fc37.aarch64
jre-openjdk -> /etc/alternatives/jre_openjdk
It seems they are generating additional entries for update-alternatives
that could be used for querying.
I'm not here to push a particular solution, what I mentioned above are just
ideas. But I think this is a serious issue because of the high frequency release
of the JDK. I would love this problem to find a solution and I'd be happy
to help in discussing ideas and designing a solution. However, I'm no
Debian expert and I am very unaware of Debian constraints or best practices
to address such a problem.
Regards,
PS: first time I'm posting here, so let me know if I missed some guidelines
------- Original Message -------
On Monday, April 17th, 2023 at 21:53, Thorsten Glaser <t.glaser@tarent.de> wrote:
>
>
> On Mon, 17 Apr 2023, Rob Browning wrote:
>
> > Is there Is there a policy or preferred way to handle a package that
> > needs a particular version or versions of java? e.g. say it doesn't
> > work with < 9.
>
>
> From a Depends standpoint, java9-runtime-headless or java9-runtime. But…
>
> > I could imagine it might not want to just rely on /usr/bin/java because
> > you might not want it to break if the system has 8 and 11 installed, and
> > then the local admin changes the default to 8 via update-alternatives.
>
>
> … this is, indeed, possible: the Depends simply means it’s present,
> not the default. (And that is a good thing.)
>
> > To avoid that, I imagine the application's /usr/bin/something could
> > examine $(update-alternatives --list java) to find a suitable version,
> > but is that reasonable, or is there a preferable approach?
>
>
> I’m a bit wary of auto-selecting something. I’d instead check whether
> ${JAVA:-java} has the right version and complain when not. Possibly
> check whether $JAVA_HOME is set (which it isn’t in a regular Debian
> one-JRE installation) and use that if suitable instead of complaining.
> (Where complaining means echo "E: some msg" >&2; exit 1)
>
>
> bye,
> //mirabilos
> --
> Infrastrukturexperte • tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
> Telephon +49 228 54881-393 • Fax: +49 228 54881-235
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> ****************************************************
> /⁀\ The UTF-8 Ribbon
> ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
> ╳ HTML eMail! Also, https://www.tarent.de/newsletter
> ╱ ╲ header encryption!
> ****************************************************
Reply to: