Hi all,
I've been working on Kotlin lately, trying to make it build with OpenJDK
17
only, and hopefully have it included in Bookworm.
Long story short, after days banging my head on this issue, I don't
think
it's possible.
How do you feel about allowing openjdk-8 in testing/bookworm with a
clear
mention in the release notes that it's only there for technical reasons
and
we make no commitment about its support?
ineluctable truth: we need OpenJDK 8 back into the stable distribution.
ineluctable truth: we need OpenJDK 8 back into the stable
distribution.
Not going to happen, sorry. This has been vetoed by the security
team and was the condition for keeping it in unstable at all.
Le 2023-01-26 19:39, Thorsten Glaser a écrit :
ineluctable truth: we need OpenJDK 8 back into the stable distribution.
Not going to happen, sorry. This has been vetoed by the security
team and was the condition for keeping it in unstable at all.
Are you opposed to this idea, or just pessimistic it could be accepted?
I think it's important to highlight that the situation has evolved. We thought openjdk-8 was good enough in unstable only to bootstrap Kotlin
and then move to a more recent JDK, but this isn't going to happen.
Also there was an uncertainty on the lifetime of OpenJDK 8, but it's
clear now that it'll be maintained for at least two more Debian
releases.
We have invested an insane amount of time in these Kotlin/Gradle
maintaining openjdk-8 in stable would require only a fraction of that.
The longer we wait, the more likely we are going to paint ourself in a corner, with a completely broken and unmaintainable Gradle for
example, or other elements in our tool chain that will no longer work
with OpenJDK 8 and break even more the kotlin build.
We still have some time to discuss this before the Bookworm release.
I suggest that we let openjdk-8 transition to testing now before the beginning of the soft freeze, just to keep our options open.
We won't expand the usage of kotlin during that time (no Gradle
upgrade for example) such that the situation remains reversible before
the release.
I've been working on Kotlin lately, trying to make it build with
OpenJDK 17
only, and hopefully have it included in Bookworm.
Long story short, after days banging my head on this issue, I don't
think
it's possible.
Le 2023-01-26 17:17, Emmanuel Bourg a écrit :
I've been working on Kotlin lately, trying to make it build with
OpenJDK 17
only, and hopefully have it included in Bookworm.
Long story short, after days banging my head on this issue, I don't
think
it's possible.
I take that back, kotlin now builds with OpenJDK 17 and is on track to migrate to testing.
This comes at a price though, besides my sanity I had the sacrifice the Android support (the Android dependencies still build with OpenJDK 8)
and
the -Xuse-javac option which hasn't been updated for OpenJDK 17 yet [1].
The solution I think is to upgrade Gradle to the first version with the Kotlin DSL source code merged, which is Gradle 5.3. I leave that to
someone
else.
On Mon, 30 Jan 2023, Emmanuel Bourg wrote:[…]
I suggest that we let openjdk-8 transition to testing now before the
beginning of the soft freeze, just to keep our options open.
then, if we indeed can keep the options open.
The MIPS buildds are at it currently and expected to finish soon,
in case you still want to go forward. It’s close to soft freeze.
Am Mittwoch, dem 01.02.2023 um 12:24 +0100 schrieb Emmanuel Bourg:
Le 2023-01-26 17:17, Emmanuel Bourg a écrit :
I've been working on Kotlin lately, trying to make it build with
OpenJDK 17
only, and hopefully have it included in Bookworm.
Long story short, after days banging my head on this issue, I don't
think
it's possible.
I take that back, kotlin now builds with OpenJDK 17 and is on track to
migrate to testing.
This comes at a price though, besides my sanity I had the sacrifice the
Android support (the Android dependencies still build with OpenJDK 8)
and
the -Xuse-javac option which hasn't been updated for OpenJDK 17 yet [1].
That sounds awesome. Well done!
The solution I think is to upgrade Gradle to the first version with the
Kotlin DSL source code merged, which is Gradle 5.3. I leave that to
someone
else.
Gradle 6.x works with the old Kotlin version and also builds gradle-kotlin-dsl
just fine. Let me tie up the loose ends together next week and then let's see how it goes.
Great work there! I would still love to see openjdk-8 in bookworm.
We're
going to loose a bunch of Android things because doclava cannot run newer JDKs.
Upstream still uses JDK8 to build it in the current Android code.
On Mon, 13 Feb 2023, Hans-Christoph Steiner wrote:
Great work there! I would still love to see openjdk-8 in bookworm.
That ship has sailed yesterday. No new entries into testing are now
possible any more.
We're
going to loose a bunch of Android things because doclava cannot run newer JDKs.
Upstream still uses JDK8 to build it in the current Android code.
You mean you lost these after stretch when openjdk-8 was not shipped
with buster any more, of course.
Thorsten Glaser:
On Mon, 13 Feb 2023, Hans-Christoph Steiner wrote:
Great work there! I would still love to see openjdk-8 in bookworm.
That ship has sailed yesterday. No new entries into testing are now
possible any more.
Damn, that might mean a lot of Android packages are not going to be in bookworm.
We're in a very similar boat as Kotlin/Gradle, with upstream still building
things with JDK8. We have piles of time-consuming hacks to keep things going.
We're
going to loose a bunch of Android things because doclava cannot run newer JDKs.
Upstream still uses JDK8 to build it in the current Android code.
You mean you lost these after stretch when openjdk-8 was not shipped
with buster any more, of course.
android-framework-23 is in bullseye. So I doublechecked, it is actually just a
conflict with JDK17, due to the removal of com.sun.javadoc, which was deprecated
in JDK11. JDK8 would cover that though.
I have no idea how much work it'd be to port to the new API https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567
.hc
Le 2023-02-13 16:38, Hans-Christoph Steiner a écrit :
android-framework-23 is in bullseye. So I doublechecked, it is
actually just a conflict with JDK17, due to the removal of
com.sun.javadoc, which was deprecated in JDK11. JDK8 would cover that
though.
I have no idea how much work it'd be to port to the new API
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567
Another solution, maybe simpler: package the com.sun.javadoc API
in a standalone package, independent from openjdk-8
android-framework-23 is in bullseye. So I doublechecked, it is
actually just a conflict with JDK17, due to the removal of
com.sun.javadoc, which was deprecated in JDK11. JDK8 would cover that though.
I have no idea how much work it'd be to port to the new API https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 307 |
Nodes: | 16 (2 / 14) |
Uptime: | 67:18:42 |
Calls: | 6,915 |
Files: | 12,379 |
Messages: | 5,431,811 |