Re: Packaging applications with JVM version restrictions
------- Original Message -------
On Wednesday, April 19th, 2023 at 09:18, Thorsten Glaser <t.glaser@tarent.de> wrote:
> Besides, what’s compatible? Some things may run with an older/newer
> JRE but others won’t.
If I follow this line of thinking, it means:
* You should not depend on java11-runtime-headless virtual package:
JDK17 could be installed before hand providing java11-runtime-headless
but maybe your application is not compatible with 17
* You should not rely on the java in the $PATH
Because who knows what the java in the $PATH is pointing to.
Yes it can be changed by the user, but then the system is very fragile
as you might need to constantly change between two alternatives when
alternatively invoking an application requiring JDK X and another
requiring JDK Y.
It's a super fragile approach severely affecting user experience
compared to languages not requiring a runtime engine.
I agree this is not an easy problem to solve.
>From the point of view of a Java application developer, I can provide a
list of JDK versions my application can be run with.
In this case, my start script could look like this:
# check if JAVA_HOME is a match
# check if default java is a match
# else try every other supported version
for version in 17 16 15 14 13 12 11; do
if [ JRE with exact java $version exists ]; then
JAVA_HOME=...
fi
done
Debian would need to provide a way to perform the "JRE with exact java $version exists"
check. This could be done by providing stable symlinks, or alternatives like
/etc/alternatives/jre_<VERSION>
Would that be a better direction of a solution for you?
Reply to: