Re: OpenJDK for Bookworm and beyond
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!
****************************************************
Reply to: