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

Groups > linux.debian.maint.java > #12513 > unrolled thread

Kotlin and OpenJDK 8 in Bookworm?

Back to article view | Back to linux.debian.maint.java

Contents

  Kotlin and OpenJDK 8 in Bookworm? Emmanuel Bourg <ebourg@apache.org> - 2023-01-26 18:20 +0100
    Re: Kotlin and OpenJDK 8 in Bookworm? Markus Koschany <apo@debian.org> - 2023-01-26 19:10 +0100
    Re: Kotlin and OpenJDK 8 in Bookworm? Thorsten Glaser <t.glaser@tarent.de> - 2023-01-26 19:40 +0100
      Re: Kotlin and OpenJDK 8 in Bookworm? Emmanuel Bourg <ebourg@apache.org> - 2023-01-30 00:40 +0100
        Re: Kotlin and OpenJDK 8 in Bookworm? Thorsten Glaser <t.glaser@tarent.de> - 2023-01-30 00:50 +0100
          Re: Kotlin and OpenJDK 8 in Bookworm? Thorsten Glaser <t.glaser@tarent.de> - 2023-02-10 18:10 +0100
            Re: Kotlin and OpenJDK 8 in Bookworm? Emmanuel Bourg <ebourg@apache.org> - 2023-02-11 10:30 +0100
    Re: Kotlin and OpenJDK 8 in Bookworm? Emmanuel Bourg <ebourg@apache.org> - 2023-02-01 12:30 +0100
      Re: Kotlin and OpenJDK 8 in Bookworm? Markus Koschany <apo@debian.org> - 2023-02-01 15:20 +0100
        Re: Kotlin and OpenJDK 8 in Bookworm? Hans-Christoph Steiner <hans@at.or.at> - 2023-02-13 12:40 +0100
          Re: Kotlin and OpenJDK 8 in Bookworm? Thorsten Glaser <t.glaser@tarent.de> - 2023-02-13 15:10 +0100
            Re: Kotlin and OpenJDK 8 in Bookworm? Hans-Christoph Steiner <hans@at.or.at> - 2023-02-13 16:40 +0100
              Re: Kotlin and OpenJDK 8 in Bookworm? Hans-Christoph Steiner <hans@at.or.at> - 2023-02-13 17:00 +0100
              Re: Kotlin and OpenJDK 8 in Bookworm? Emmanuel Bourg <ebourg@apache.org> - 2023-02-13 17:20 +0100
                Re: Kotlin and OpenJDK 8 in Bookworm? Hans-Christoph Steiner <hans@at.or.at> - 2023-02-13 17:40 +0100

#12513 — Kotlin and OpenJDK 8 in Bookworm?

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. The latest upstream version, Kotlin 1.8.0, released last
month, still expects OpenJDK 6 and 7 to build! It doesn't look like 
Kotlin
is anywhere near being buildable with a modern JDK. For example, the 
Kotlin
compiler imports classes from the com.sun.tools package which is no 
longer
exported since OpenJDK 9, and it doesn't seem possible to set the
--add-exports options to let the Kotlin compiler access them.

Kotlin has become, for the better or worse, a central piece of the Java
ecosystem, mostly due to its adoption by Gradle and Android. We see an
increasing number of project using Gradle with the Kotlin DSL and they 
are
difficult to maintain. We basically have to rewrite the build system,
either translating the Kotlin build files into Groovy (as was done for
bootstrapping Kotlin, and for the Gradle 6 packaging attempts) or 
replacing
them with something different (the junit5 package now uses Maven). This 
is
extremely tedious and error prone.

We can continue struggling like this for a few more years (the Kotlin
packaging effort started 3 years ago already), or we can accept the
ineluctable truth: we need OpenJDK 8 back into the stable distribution.

Looking around, Ubuntu kept shipping the openjdk-8 package in its latest
22.04 LTS [1], Red Hat still includes it and even pushed back the EOL 
date
by 6 months, from May 2026 to November 2026 [2]. Temurin is also aligned 
on
November 2026 [3]. Azul [4] and Oracle [5] will support OpenJDK until 
2030.
So should Debian include OpenJDK 8 back, we can expect it to be 
supported
by the Java community for the lifetime of Bookworm.

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?

Emmanuel Bourg


[1] https://packages.ubuntu.com/source/kinetic/openjdk-8
[2] 
https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions
[3] https://adoptium.net/support/
[4] https://www.azul.com/products/azul-support-roadmap/
[5] 
https://www.oracle.com/java/technologies/java-se-support-roadmap.html

[toc] | [next] | [standalone]

#12514

[Multipart message — attachments visible in raw view] — view raw

Hi Emmanuel,

Am Donnerstag, dem 26.01.2023 um 17:17 +0100 schrieb Emmanuel Bourg:
> 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. 

[...]

I have come to the same conclusion. Your recent commitment to make this all
work with OpenJDK 17 gave me hope but it shouldn't be I guess.

> 
> 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?

I think this is the only possible solution at the moment. We make it clear that
openjdk-8 is not supported in any way and will not receive any security
updates. We probably need to update the package description and should mention
this clearly in the release notes too. In that case I don't see any objections
from neither the release or security team. 

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#12515

On Thu, 26 Jan 2023, Emmanuel Bourg wrote:

> 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.

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

[toc] | [prev] | [next] | [standalone]

#12518

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 issues, 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.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#12519

On Mon, 30 Jan 2023, Emmanuel Bourg wrote:

> 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?

Pessimistic. It is currently manageable to upgrade in sid and
the jessie and stretch updates in ELTS are trivial. I personally
also build it for wheezy and (on user request) buster, bullseye,
and on a PPA for trusty/xenial/bionic/focal/jammy, so it works.
I can only mildly test it, though.

> 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.

Any proposal to keep openjdk-8 will want to know for how long this
isn’t going to happen, i.e. at what point Kotlin &c. are expected
to work with default-jdk.

> 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.

Oh, indeed? I haven’t seen the plan, but if that is so, this may
be a good data point. On the other hand, the security team will
not be liking having more than one implementation of something
to support. Yes, documenting its unsupportedness is one thing,
but if it exists…

> We have invested an insane amount of time in these Kotlin/Gradle

OK, I understand the frustration.

> maintaining openjdk-8 in stable would require only a fraction of that.

(Not to mention that it is currently I who’s maintaining that,
and the ELTS people do the actual work of writing the DSA/DLAs
and uploading to -security. But I’m okay with this as long as
I’m not expected to upload a new version on basically the same
day as its release; I took a bit longer for the 2023Q1 update
due to other work-relared things having priority, but I normally
do it within the week or so. On the other hand, I’m currently in
the position of being able to do most of that on company time,
and I’m not sure how much I want to continue this when that will
no longer be true.)

> The longer we wait, the more likely we are going to paint ourself in a
> corner, with a completely broken and unmaintainable Gradle for

What’s the status of Gradle then? I thought it required Kotlin,
and we have Kotlin now, so isn’t it already using that?

> example, or other elements in our tool chain that will no longer work
> with OpenJDK 8 and break even more the kotlin build.

To be honest, I expected that point to happen within the preceding
two years already. I know I could not build Maven projects with < 11
(but targetting 8 from 11 works well now, and some of the bugs were
building accidents on the Maven plugin developers’ side).

> We still have some time to discuss this before the Bookworm release.

Do we? We’re in the first part of the freeze already.

> I suggest that we let openjdk-8 transition to testing now before the
> beginning of the soft freeze, just to keep our options open.

I’d like to have at least one person from the stable release managers
“sign off” on that beforehand, also because it is the package maintainer
who is going to be blamed. Not necessarily as a for-the-team decision,
just so that at least someone is informed; the team can decide later
then, if we indeed can keep the 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.

Sounds like a plan.

I’d appreciate if you could distill from this thread what has been
said and contact the SRM. Once we have at least one nōn-veto response
you can close #989736 so it will migrate so we have options open. It
was freshly uploaded today anyway, so it’ll take some time.

As a caveat, one of the MIPS platforms FTBFS’d with the previous
release (they all are currently still in Needs-Build for this one).
https://mail.openjdk.org/pipermail/jdk8u-dev/2022-October/015730.html
is where I informed upstream about this, but I don’t know if someone
has even looked at that. We’ll want to have this running on at least
all release architectures if we go forward with this.

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

[toc] | [prev] | [next] | [standalone]

#12552

Dixi quod…

>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.

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

[toc] | [prev] | [next] | [standalone]

#12553

Le 2023-02-10 18:07, Thorsten Glaser a écrit :

> 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.

It's still building but that's fine, we won't need openjdk-8
for kotlin, the beast has been tamed.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#12520

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].

It isn't extensively tested yet but the resulting package is good enough 
to
rebuild itself.

The next hurdle is to enable the Kotlin DSL in Gradle. I've packaged the
version of gradle-kotlin-dsl that came with Gradle 4.4 but it doesn't 
work.
When Gradle encounters a .kts file an obscure error is thrown
(NoDescriptorForDeclarationException: Descriptor wasn't found for
declaration SCRIPT). I have no idea how to fix this, and I now think 
this
is a dead end anyway. gradle-kotlin-dsl uses internal Gradle APIs that
changed in Gradle 5, so if we use the Kotlin syntax to upgrade Gradle,
it'll break immediately and we'll be unable to rebuild Gradle.

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.

Emmanuel Bourg

[1] https://youtrack.jetbrains.com/issue/KT-56235

[toc] | [prev] | [next] | [standalone]

#12521

[Multipart message — attachments visible in raw view] — view raw

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.

Markus

[toc] | [prev] | [next] | [standalone]

#12557

Markus Koschany:
> 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!

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.

I think we have a clear case for the security team, since not only has upstream 
pledged support for the entire time window we need, but multiple distros as well.

>> 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.

Thanks for keeping this moving, it is the best news I've heard in a while.  I'm 
not sure how I can best support this effort, but please ping me if you need me 
to jump in anywhere.

.hc

[toc] | [prev] | [next] | [standalone]

#12559

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.

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

[toc] | [prev] | [next] | [standalone]

#12560

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

[toc] | [prev] | [next] | [standalone]

#12562

Hans-Christoph Steiner:
> 
> 
> 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
> 

I dug a bit more: yes, some Android packages will not be in bookworm, but looks 
like the most important ones will not be affected by android-framework-23 being 
removed.  I think some of the other team members reduced the reliance on that 
package recently, which I wasn't aware of.

.hc

[toc] | [prev] | [next] | [standalone]

#12563

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

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#12564

Emmanuel Bourg:
> 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

Sounds totally reasonable.  But I have no idea how to start on that.  Would it 
be something like just copying some .java files into the doclava source package?

.hc

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web