Hi all,

OpenJDK 11 has been the default JDK in the last two releases, and a more
recent version for Bookworm is highly expected. The current LTS version
is OpenJDK 17, released in September 2021 one month after Bullseye. The
next LTS version will be OpenJDK 21 (the LTS cadence has been shortened
from 3 to 2 years) to be released in September 2023, again shortly after
the Debian release which can be expected in July or August 2023 if the
rhythm of the previous releases is kept. This scenario is likely to
continue in the future since the Debian and Java releases are now
synchronized on the same 2 years cycle.

The first point is to plan when we'll switch the default JDK to OpenJDK
17. The transition has progressed well, with 113 bugs fixed already, but
there are still 36 bugs left to fix [1] (this is a much smoother
transition than the jump from OpenJDK 8 to 11 where we had to deal with
over 500 bugs). There are no critical issues, the build tools and the
main packages all work fine. So I suggest that we switch without waiting
for the remaining bugs to be fixed. I propose to switch on October 31th
for Halloween, such that the switch will unleash compatibility
nightmares and runtime horrors haunting those who have ignored the bug
reports for months ;) That'll leave sufficient time to address the
remaining issues before the release.

Another point is how to deal with the next LTS, OpenJDK 21. For Bullseye
the Security Team agreed to ship OpenJDK 17 as a "technology preview" in addition to OpenJDK 11, with no promise it would be as well supported as OpenJDK 11. In practice, thanks to Matthias and Moritz prompt uploads,
the OpenJDK 17 updates landed in stable-security on average 8 days after
the GA release, which is as good as the OpenJDK 11 updates. Popcon
reports 4524 installs of OpenJDK 17 with a steady growth, and 51690
installs of OpenJDK 11. Assuming OpenJDK 17 users also have OpenJDK 11 installed that's about 8% of the Java users interested in the latest LTS
JDK. This is a significant share of users and it shows the extra effort involved in maintaining an additional JDK is worth it.

If the Security Team agrees I think we should continue with this
strategy in Bookworm and ship OpenJDK 21 in addition to OpenJDK 17. The
first OpenJDK 21 EA release will be available in December well before
the freeze in March, so that fits with the Bookworm release timeline.

Last point, we still have OpenJDK 8 in unstable to help with the
bootstrapping of some packages that can't build directly with the latest
JDK (more specifically, Kotlin and Scala). Similarly I think we should
preserve OpenJDK 11 in unstable after the transition to OpenJDK 17.

Emmanuel Bourg

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;[email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 29 Sep 2022, Emmanuel Bourg wrote:

previous releases is kept. This scenario is likely to continue in the future since the Debian and Java releases are now synchronized on the same 2 years cycle.

We could always delay Debian’s… (SCNR) or petition upstream to change theirs.

Assuming OpenJDK 17 users also have OpenJDK 11 installed that's about

That is probably not a safe assumption. I have run into issues with more
than one JRE installed, so I only ever install one. (But I doubt it matters much, for the larger picture, anyway.)

This is a significant share of users and it shows the extra effort
involved in maintaining an additional JDK is worth it.

I think we have to distinguish between using the JDK/JRE as B-D/Depends
of Debian packages, and using the JDK to develop and/or the JRE to run “other” software.

For the former, we’re never going to get all software switched over to
work with the newer one in time, especially considering we’ve apparently
not switched the default to 17 over a year past the bullseye release.

For the latter, I agree-ish. For bullseye and 17, we have https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#openjdk-17
which boils down to “11 is supported, 17 is not but we provide it as best-effort”. I think this suffices for the “other software” case.

Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping
of some packages that can't build directly with the latest JDK (more specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK 11 in unstable after the transition to OpenJDK 17.

Who’s going to maintain that?

For OpenJDK 8 I took over because, for quite some time (but not for a
while) we had customers for whom I built this for older and newer Debian
and *buntu releases. I’m now basically doing it because I started it,
not because I have use myself any more. Doko dropped it, incidentally
because of a bug he, with toolchain maintainer hat on, reported himself,
and Tiago isn’t in a position to maintain things any more either AIUI.

I am not going to take over 11 as well. (But if someone else wants to,
I’d gladly share knowledge and experience. Or see my last paragraph.)

History has shown that the (E)LTS contributors can and will do this on
their own anyway so having 11 in sid to stage security support is not
strictly necessary. If maintained, it is beneficial because then we’ll
have a consistent state across releases. If unmaintained, however, not
having it is better.

So I think we should keep 11 around *only* if someone (could be Doko,
could be someone else) commits to maintaining it. If nobody does, Scala
and Kotlin are SOL.

(There’s always the option of approaching my employer to make them make
me maintain 11 as well as 8, for a fee, of course. I can barely justify continuing 8 right now. I’d do it but I’m not in a position to be able
to do it through Freexian or freelancing.)

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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 29/09/2022 à 14:06, Thorsten Glaser a écrit :

Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping
of some packages that can't build directly with the latest JDK (more
specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK
11 in unstable after the transition to OpenJDK 17.

Who’s going to maintain that?

I don't think the maintenance is a concern, we only have to ensure it
keeps building in sid. It's just to compile stuff in sid, not to run
critical production systems.

So I think we should keep 11 around *only* if someone (could be Doko,
could be someone else) commits to maintaining it. If nobody does, Scala
and Kotlin are SOL.

I don't mind for Scala, but Kotlin can't be ignored unfortunately. Its integration into Gradle makes it an essential part of the Java ecosystem.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 29 Sep 2022, Emmanuel Bourg wrote:

Who’s going to maintain that?

I don't think the maintenance is a concern, we only have to ensure it
keeps building in sid.

Yeah well, that’s maintenance, and that was missing for 8 as shown in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981811#5

It's just to compile stuff in sid, not to run critical
production systems.

If it’s used to base security updates for bullseye on, then no,
it’ll be used to run critical production systems (indirectly:
not the sid binaries, but the others).

So I think we should keep 11 around *only* if someone (could be Doko,
could be someone else) commits to maintaining it. If nobody does, Scala
and Kotlin are SOL.

I don't mind for Scala, but Kotlin can't be ignored unfortunately. Its integration into Gradle makes it an essential part of the Java ecosystem.

Then we should find something who takes on the maintenance burden.

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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Sep 29, 2022 at 08:07:30PM +0200, Emmanuel Bourg wrote:

Le 29/09/2022 à 14:06, Thorsten Glaser a écrit :

Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping
of some packages that can't build directly with the latest JDK (more specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK
11 in unstable after the transition to OpenJDK 17.

Who’s going to maintain that?

I don't think the maintenance is a concern, we only have to ensure it keeps building in sid. It's just to compile stuff in sid, not to run critical production systems.

So I think we should keep 11 around *only* if someone (could be Doko,
could be someone else) commits to maintaining it. If nobody does, Scala
and Kotlin are SOL.

I don't mind for Scala, but Kotlin can't be ignored unfortunately. Its integration into Gradle makes it an essential part of the Java ecosystem.

I've not yet completely given up on the kotlin/gradle bootstrapping
problem, but I'm still learning the skills needed to bang my head
against the wall. Please don't remove 8 or 11 from unstable for the
medium term if at all possible in any way as that would just be so much blocking work to somehow boostrap the openjdk itself locally as well.

Gradle version "being worked on" is 6.4.1 which declares compatibility
with 8 and 11. Only the absolute latest gradle version 7.3 finally adds
support for 17, so that won't be possible any time soon. Kotlin in
unstable currently builds with 8 but 11 should be possible, see #10.

https://salsa.debian.org/java-team/gradle/-/tree/gradle-6.4.1-initial https://docs.gradle.org/6.4.1/userguide/compatibility.html https://docs.gradle.org/7.3/userguide/compatibility.html https://salsa.debian.org/java-team/kotlin/-/issues/10

In general both gradle and kotlin seem to actually be good with long
backwards compatibility here so there is reason to hope for a somewhat
rapid version ratcheting once the initial cross compatible uploads are
done. kotlin 1.7 is the first release to require gradle 6.7, so 1.6.21
should be the next target if it turns out to be possible to skip that
far. Alternatively 1.3.72 is the earliest leap for latest gradle.

https://salsa.debian.org/java-team/kotlin/-/issues/16

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCY0YC3AAKCRDbymUJHySO bM+jAP0WT2/PLl1xG33XLN3FX2ABtRuT2FOyhdwcWVDAwvPLDwD6Aomftq/an5bn pDPgF7sEo3pqPJ0P4opDDiyUXJ2opA4=
=uCwl
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 31 Oct 2022, Emmanuel Bourg wrote:

Also worth noting, default-jre now provides a versioned java-runtime dependency. This means we can now replace the java<n>-runtime dependencies with java-runtime (>= n).

No, we really should not: the various JDKs also only provide
java<n>-runtime and this dependency is specifically meant to
also make it possible for software to use a JRE *other* than
the default (the dependency reads like
default-jre (>= x) | javaX-runtime
by design/for a reason).

Given how they stretch across versions and how many releases
are supportable (ELTS from jessie on, *buntu from trusty on)
I will argue that if and only if the openjdk-X source packages
also start providing these _now_, that we can start switching
to the versioned java-runtime provide in 2030, maybe later.

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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 29/09/2022 à 12:00, Emmanuel Bourg a écrit :

I propose to switch on October 31th
for Halloween, such that the switch will unleash compatibility
nightmares and runtime horrors haunting those who have ignored the bug reports for months ;)

As announced last month, I've just uploaded java-common/0.73 which
switches the default JRE to OpenJDK 17. The severity of the remaining
bugs has been increased to serious.

Also worth noting, default-jre now provides a versioned java-runtime dependency. This means we can now replace the java<n>-runtime
dependencies with java-runtime (>= n).

Happy Halloween!

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, Sep 29, 2022 at 12:00:42PM +0200 schrieb Emmanuel Bourg:

Hi all,

Sorry for the late reply, this got backlogged in my inbox.

The first point is to plan when we'll switch the default JDK to OpenJDK 17. The transition has progressed well, with 113 bugs fixed already, but there are still 36 bugs left to fix [1] (this is a much smoother transition than the jump from OpenJDK 8 to 11 where we had to deal with over 500 bugs).
There are no critical issues, the build tools and the main packages all work fine. So I suggest that we switch without waiting for the remaining bugs to be fixed. I propose to switch on October 31th for Halloween, such that the switch will unleash compatibility nightmares and runtime horrors haunting those who have ignored the bug reports for months ;) That'll leave
sufficient time to address the remaining issues before the release.

Sounds good to me!

If the Security Team agrees I think we should continue with this strategy in Bookworm and ship OpenJDK 21 in addition to OpenJDK 17. The first OpenJDK 21 EA release will be available in December well before the freeze in March, so that fits with the Bookworm release timeline.

That's fine with me (if doko continues to update it in unstable) (and if we again only have 17 as the default + 21 preview/secondary JRE). And 11 not in testing.

Cheers,
Moritz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, Sep 29, 2022 at 02:06:06PM +0200 schrieb Thorsten Glaser:

Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping
of some packages that can't build directly with the latest JDK (more specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK
11 in unstable after the transition to OpenJDK 17.

Who’s going to maintain that?

For OpenJDK 8 I took over because,

Do we even have to keep 8 around in unstable at this point? If people want to bootstrap kotlin or scala for a new arch, why can't this happen on a buster system?

Cheers,
Moritz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 8 Nov 2022, Moritz Mühlenhoff wrote:

Do we even have to keep 8 around in unstable at this point? If people
want to bootstrap kotlin or scala for a new arch, why can't this
happen on a buster system?

AIUI this is not a :any issue, but an issue of bootstrapping one
new enough to run with a newer JRE, from one that runs with an older
one, i.e. 8.

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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.

On Tuesday, 8 November 2022 19:51:12 GMT Moritz Mühlenhoff wrote:

Am Thu, Sep 29, 2022 at 02:06:06PM +0200 schrieb Thorsten Glaser:

Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping of some packages that can't build directly with the
latest JDK (more specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK 11 in unstable after the transition to OpenJDK 17.

Who’s going to maintain that?

For OpenJDK 8 I took over because,

Do we even have to keep 8 around in unstable at this point? If people want
to bootstrap kotlin or scala for a new arch, why can't this happen on a buster system?

Cheers,
Moritz

Every current version of Scala runs on OpenJDK 11 or above. See:-


https://docs.scala.org/overviews/jdk-compatibility/overview.html


The only code that really needs to be in Debian for building anything scala related is sbt
(which needs a current 2.12 to build), and that is the only bit of the scala infrastructure
that is up to date (at 1.7.3 which is the latest version).


The scala compiler and other libraries currently on Debian are so out of date as to be of no
use. Sbt downloads everything it and the project you are building including the compiler
from Maven so having them in Debian is redundant.


The only sensible alternatives to sbt are mill (not currently in Debian) and gradle (which
currently says it needs openjdk 8) which used for projects which are mixed java and scala.



<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">On Tuesday, 8 November 2022 19:51:12 GMT Moritz Mühlenhoff wrote:</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; Am Thu, Sep 29, 2022 at 02:06:06PM +0200 schrieb Thorsten Glaser:</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; &gt; Last point, we still have OpenJDK 8 in unstable to help with the</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; &gt; bootstrapping of some packages that can't build directly with the</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; &gt; latest JDK (more specifically, Kotlin and Scala). Similarly I think we</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; &gt; should preserve OpenJDK 11 in unstable after the transition to OpenJDK</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; &gt; 17.</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; </p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; Who’s going to maintain that?</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; </p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; &gt; For OpenJDK 8 I took over because,</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; </p> <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; Do we even have to keep 8 around in unstable at this point? If people want</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; to bootstrap kotlin or scala for a new arch, why can't this happen on a</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; buster system?</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; </p> <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; Cheers,</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt;         Moritz</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Every current version of Scala runs on OpenJDK 11 or above.  See:-</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br /></p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">https://docs.scala.org/overviews/jdk-compatibility/overview.html</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br /></p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">The only code that really needs to be in Debian for building anything scala related is sbt (which needs a current 2.12 to build), and that is the only bit of the scala infrastructure
that is up to date (at 1.7.3 which is the latest version).</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br /></p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">The scala compiler and other libraries currently on Debian are so out of date as to be of no use.  Sbt downloads everything it and the project you are building including the compiler
from Maven so having them in Debian is redundant.</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br /></p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">The only sensible alternatives to sbt are mill (not currently in Debian) and gradle (which currently says it needs openjdk 8) which used for projects which are mixed java and scala.</p>
<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br /></p>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 08/11/2022 à 20:49, Moritz Mühlenhoff a écrit :

If the Security Team agrees I think we should continue with this strategy in >> Bookworm and ship OpenJDK 21 in addition to OpenJDK 17. The first OpenJDK 21 >> EA release will be available in December well before the freeze in March, so >> that fits with the Bookworm release timeline.

That's fine with me (if doko continues to update it in unstable) (and if we again only have 17 as the default + 21 preview/secondary JRE). And 11 not in testing.

Thank you Moritz. I've filed #1023237 to get openjdk-11 removed from
testing.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 31/10/2022 à 19:54, Thorsten Glaser a écrit :

No, we really should not: the various JDKs also only provide
java<n>-runtime and this dependency is specifically meant to
also make it possible for software to use a JRE *other* than
the default (the dependency reads like
default-jre (>= x) | javaX-runtime
by design/for a reason).

That should also be possible with the versioned virtual package:

default-jre (>= 2:1.n) | java-runtime (>= n)

Given how they stretch across versions and how many releases
are supportable (ELTS from jessie on, *buntu from trusty on)
I will argue that if and only if the openjdk-X source packages
also start providing these _now_, that we can start switching
to the versioned java-runtime provide in 2030, maybe later.

I agree the sooner the openjdk-<n> packages provide java-runtime (= n)
the better. But I don't see the need to wait a decade before using the versioned java-runtime dependency in the packaged applications, what
issue do you foresee?

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 10 Nov 2022, Emmanuel Bourg wrote:

But openjdk-17-jre also provides java11-runtime. So even with:

default-jre (>= 2:1.11) | java11-runtime

there is no guarantee Java 11 will be used.

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.

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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

The application defines

default-jre (>= 2:1.11) | java-runtime (>= 11)

but openjdk-11-jre does not yet Provides java-runtime,
only java11-runtime. This will force the user to 17.

But openjdk-17-jre also provides java11-runtime. So even with:

default-jre (>= 2:1.11) | java11-runtime

there is no guarantee Java 11 will be used.

If you want Java 11 only, you'll be able to depend on:

openjdk-11-jre | java-runtime (= 11)

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 10 Nov 2022, Emmanuel Bourg wrote:

better. But I don't see the need to wait a decade before using the versioned java-runtime dependency in the packaged applications, what issue do you foresee?

The application defines

default-jre (>= 2:1.11) | java-runtime (>= 11)

but openjdk-11-jre does not yet Provides java-runtime,
only java11-runtime. This will force the user to 17.

(Same for any other version pairs, really. Also consider
backports and partial upgrades.)

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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 11 Nov 2022, Emmanuel Bourg wrote:

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.

3. openjdk-11-jre-headless was used in bullseye (most people I know
do this to avoid the needless metapackage), the user will end up with
both because the Provides on java-runtime-headless in bullseye was
unversioned but maybe they don’t (worse if the package is backported).

It’s worse for sid users, especially for rare cases.

gn8,
//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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 11/11/2022 à 01:46, Thorsten Glaser a écrit :

3. openjdk-11-jre-headless was used in bullseye (most people I know
do this to avoid the needless metapackage), the user will end up with
both because the Provides on java-runtime-headless in bullseye was unversioned but maybe they don’t (worse if the package is backported).

Not installing default-jre isn't really a good idea, because once the
system is upgraded to bookworm, openjdk-11-jre will not be updated
anymore and a manual update to openjdk-17-jre will be necessary at some
point.

That said, by the time bookworm is released openjdk-11 is likely to be
updated in bullseye, and the update will provide the java-runtime (= 11) dependency. This is somewhat similar to the case 2.

It’s worse for sid users, especially for rare cases.

Why worse? sid users will be the first to receive the updated openjdk
package with the versioned java-runtime dependency.


Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 11 Nov 2022, Emmanuel Bourg wrote:

once the system
is upgraded to bookworm, openjdk-11-jre will not be updated anymore and a manual update to openjdk-17-jre will be necessary at some point.

Yes, but if this is precisely the desired outcome…

Why worse? sid users will be the first to receive the updated openjdk package with the versioned java-runtime dependency.

That can be the problem.

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!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)