Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.java > #12480

Re: OpenJDK for Bookworm and beyond

From Emmanuel Bourg <ebourg@apache.org>
Newsgroups linux.debian.maint.java
Subject Re: OpenJDK for Bookworm and beyond
Date 2022-11-11 01:40 +0100
Message-ID <Fqqfn-2Sin-1@gated-at.bofh.it> (permalink)
References (2 earlier) <FmIaR-ru9-3@gated-at.bofh.it> <Fqmv8-2Q5s-11@gated-at.bofh.it> <Fqn7Q-2QxJ-3@gated-at.bofh.it> <FqnAR-2QH4-3@gated-at.bofh.it> <FqnAR-2QH4-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Le 10/11/2022 à 22:39, Thorsten Glaser a écrit :

> That’s not the point. That much is true, but the point here is
> that the user *CAN* use Java 11, *if* they have installed it
> beforehand, i.e. that they are not _forced_ to upgrade.
> 
> If they don’t have it installed, the default-jre will be installed
> anyway.
> 
> This is about not forcing, possibly multiple, unnecessary JREs.

Sorry but I'm still not sure to understand. Let's take tomcat9 as an 
example. Currently in bullseye/testing/sid it depends on:

     default-jre-headless | java11-runtime-headless

Let's assume this is changed in bookworm to:

     default-jre-headless | java-runtime-headless (>= 11)

Considering a tomcat9 user upgrading from bullseye to bookworm, there 
are two cases:

1. the default JRE was used on bullseye, default-jre-headless and 
openjdk-11-jre were already installed. During the upgrade, 
openjdk-17-jre is pulled (required by default-jre), openjdk-11-jre 
remains (but could be removed manually), and tomcat9 expects 
java-runtime-headless (>= 11) which is satisfied by both 
default-jre-headless and openjdk-17-jre-headless. Tomcat will run with 
OpenJDK 17 and all is fine.

2. an external JRE 11 was used (Oracle JDK, Azul Zulu, Amazon Corretto 
or a java-package generated JRE), default-jre may or may not be 
installed, let's say it isn't. When upgrading to Bookworm, if the 
external JRE doesn't provide java-runtime-headless (>= 11), then 
default-jre and openjdk-17-jre will be pulled. If JAVA_HOME was defined 
in /etc/default/tomcat9, the old JRE 11 is still used to run Tomcat, 
otherwise openjdk-17-jre is picked. Is this the problem you are underlining?


A side note on the external JREs:
- Oracle JDK doesn't provide any of the java<n>-runtime and 
java<n>-runtime-headless dependencies, it only provides jdk-<n> which is 
used nowhere AFAIK
- Azul Zulu provides a JRE package which satisfies java<5..n>-runtime 
but no the -headless variant. It also provides a JDK package with 
java<5..n>-runtime and java<5..n>-sdk
- Amazon Corretto provides only a JDK package for Debian. It satisfies 
java<5..n>-runtime, java<5..n>-runtime-headless and java<5..n>-sdk, but 
only for the LTS versions (so no java12-* for example, only 5-8, 11 and 17).
- java-package generated JDKs provide java<5..n>-runtime, 
java<5..n>-runtime-headless and java<5..n>-sdk. java-package was last 
updated 6 years ago and doesn't support Java >= 9 (#876426). Since most 
JDK vendors now provide .deb packages (the notable exception being 
Eclipse Temurin) we can probably declare it obsolete and drop it from 
bookworm.

We can reasonably expect Azul and Amazon to adopt the new java-runtime 
(= n) by the time Bookworm is released. This will prevent the 
installation of the default JDK when the system is upgraded (but this 
isn't that problematic anyway).


Regarding the backports, the java-runtime (>= n) dependency will have to 
be changed back to java<n>-runtime, that's not a huge constraint. And I 
expect the openjdk security updates to introduce the java-runtime (= n) 
provides in stable/oldstable, so that may no be even necessary.

Emmanuel Bourg

Back to linux.debian.maint.java | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-09-29 12:10 +0200
  Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-09-29 14:10 +0200
    Re: OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-09-29 20:10 +0200
      Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-09-29 20:40 +0200
      Re: OpenJDK for Bookworm and beyond Phil Morrell <debian@emorrp1.name> - 2022-10-12 02:00 +0200
    Re: OpenJDK for Bookworm and beyond Moritz Mühlenhoff <jmm@inutil.org> - 2022-11-08 21:00 +0100
      Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-11-08 21:00 +0100
      Re: OpenJDK for Bookworm and beyond David Goodenough <david.goodenough@linkchoose.co.uk> - 2022-11-09 12:50 +0100
  Re: OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-10-31 19:50 +0100
    Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-10-31 20:00 +0100
      Re: OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-11-10 21:40 +0100
        Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-11-10 22:20 +0100
          Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-11-10 22:50 +0100
            Re: OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-11-11 01:40 +0100
              Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-11-11 01:50 +0100
                Re: OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-11-11 12:00 +0100
                Re: OpenJDK for Bookworm and beyond Thorsten Glaser <t.glaser@tarent.de> - 2022-11-11 16:30 +0100
          Re: OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-11-10 22:50 +0100
  Re: OpenJDK for Bookworm and beyond Moritz Mühlenhoff <jmm@inutil.org> - 2022-11-08 20:50 +0100
    Re: OpenJDK for Bookworm and beyond Emmanuel Bourg <ebourg@apache.org> - 2022-11-10 20:40 +0100

csiph-web