Bug 25581 - Update openjdk to LTS version 11
Summary: Update openjdk to LTS version 11
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker normal
Target Milestone: ---
Assignee: Java Stack Maintainers
QA Contact:
Depends on:
Reported: 2019-10-17 14:49 CEST by Marc Krämer
Modified: 2020-10-14 21:26 CEST (History)
4 users (show)

See Also:
Source RPM: java-1.8.0-openjdk-
Status comment:


Description Marc Krämer 2019-10-17 14:49:00 CEST
Java 8 is outdated an some applications are going to require a newer version (11) (e.g. https://mediathekview.de common app to view/download german tv)

We should upate our java stack!
Comment 1 Lewis Smith 2019-10-17 15:29:53 CEST
So assigning to our java stack maintainers.

Assignee: bugsquad => java

Comment 2 David Walser 2019-10-21 23:42:40 CEST
Just to be clear, that will require updating the whole Java stack to be compatible with 11 (i.e. we should not provide both in a stable release), but if it's feasible, it would be nice.  Obviously it would have to be done in Cauldron first.
Comment 3 Marc Krämer 2019-10-22 10:19:37 CEST
If this is the case, we MUST to have the latest release in our distro. jdk11 was released in sept. 2018 and the current release is java 13.
Programmers use and want to use the latest features of programming languages and they do. On windows these updates are triggered automatically, so they assume they can use the new features.

Btw. even cauldron was not updated yet, to at least jdk 11.
Comment 4 Frédéric "LpSolit" Buclin 2019-10-22 15:04:18 CEST
How is this bug different from bug 25026? Marking this one as a duplicate, because it's the exact same request.

*** This bug has been marked as a duplicate of bug 25026 ***

Resolution: (none) => DUPLICATE

Comment 5 Marc Krämer 2019-10-22 15:19:19 CEST
and both bugs are closed...
one marked as old the other as duplicate and nothing changes.

Resolution: DUPLICATE => (none)

Comment 6 Frank Griffin 2019-10-22 16:54:12 CEST
Do expect some things to break.  My company distributes software that relies on WildFly (JBoss), and the version we tested with and recommend was 10.0.0.  When one of our customers updated to Java 11, WildFly 10 stopped working.  Investigation showed that there was a certain reflection coding technique in common use up to Java 8 which Oracle found problematic.  Starting with Java 9 they were issuing warnings saying the technique would be deprecated, and in Java 10 it was.  WildFly 10 was using this technique.  Upgrading to the then-current WildFly 14 fixed this.

I'd expect any Java app out in the wild would have found and fixed problems like this already, but they may have to be upgraded from the versions people have been using with MGA *or* from the versions we actually package.

CC: (none) => ftg

Comment 7 Marc Krämer 2019-10-22 18:24:55 CEST
@Frank: thanks for your comment, I think this is true for every (major) release of any language. And as old languages break newer software, new languages may break old software. You can't get it right for everyone. That's why people pay much money for red hat enterprise.

In most cases you can install and use software from older mga releases, so you have the option to stay at your older release.
Comment 8 Frank Griffin 2019-10-22 18:53:14 CEST
@Marc: Don't get me wrong, I'm all in favor of the upgrade.  Just wanted to point out that it may involve a little more than just building the rpm.
Comment 9 David Walser 2019-10-22 19:36:51 CEST
Yes it would require updating/rebuilding hundreds of packages, and like you said, would break some users' software.  This is probably not going to happen, but there is no optimal solution here.  Unfortunately we just need more packagers, but even then, these packages are very complicated, so very few understand them.
Comment 10 Frank Griffin 2019-10-22 20:53:09 CEST
I don't see how it would require updating/rebuilding hundreds of other packages.  Bytecode is bytecode, and as long as the bytecode is still valid the older packages should be as well.  

The example I gave was one where the new JVM was rejecting a now-invalid reflection coding technique which is unlikely to be used in any application short of a JEE container.

From what I know of building Java, the required work falls into three categories:

1) Getting the J11 makefile to work from within our rpm.  Presumably this involves the same steps (if any) that were taken for J8, and has probably been done already by Fedora if J11 has been out for over a year.

2) Setting up the directory structure for MGA, i. e. /etc/alternatives, which should be exactly the same as it was for J8, with some name changes.

3) Giving a cauldron advisory that once J11 replaces J8, it's possible that some older Java code might have problems.  If one does, and it is a third-party app, it's the user's job to update the version.  If it's one of ours, then we need to update the version.  In either case, the need to rebuild exists only to upgrade the underlying app to a newer version that doesn't have the error.  As I say, the only apps that would be affected by this particular situation would be container apps like JEE containers or IDEs like Netscape or Eclipse.  In the unlikely event that such a container app had no newer version that could run under J11, it would be the same situation as waiting for upstream to fix any other outstanding bug.
Comment 11 Marc Krämer 2019-10-22 22:30:16 CEST
I fully agree with Frank. I don't think we really have many packages that link directly to java libraries. And I assume most of the packages already have newer versions.
But even if it needs to rebuild hundreds of apps (for cauldron speaking), it should be started as quick as possible, otherwise we are going to release mga8 still having openjdk 9. And this will bring us to the point where lts ends while we have to support mga8.

If you read the (new) release model of openjdk (https://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html) (quoted from https://openjdk.java.net/projects/jdk/) they ship a new release every 6 month. If this is the case we must ask if we can stick to the lts releases and have software that will not run on mageia because the runtime is outdated? Or if we should ship the latest release (candidate) when we publish our release.

From my point of view, runtimes like python, perl (Raku), php, ... should always show the latest stable version at release, since we support them for at least 2 years. And the user expects to run the latest software with our new release.
Comment 12 Adrien Guichard 2019-10-23 07:36:15 CEST
My 2 cents : If we update, we first have to check for Groovy (gradle) to support OpenJDK 13. We should provide OpenJDK 11 ATM, even if the target is OpenJDK 13. 

The support is very close for Grails (see: https://github.com/gradle/gradle/issues/8681). It would break Android build / Groovy...

We use Jdk 11 on java-1.8.0 builds and it runs without problems. It would be cool to have at least OpenJDK 11 (and also OpenJDK 13) along with OpenJDK 1.8.0, with nothing else rebuild in Cauldron, to test from here and have an incremental integration.


CC: (none) => guichard.adrien

Comment 13 David Walser 2019-10-23 18:13:51 CEST
Well of course we will stick to LTS versions.  The other versions are not even a consideration.  David and Nicholas will have to confirm, but I believe to have the full Java stack (lots of apache-* and j* and other packages) functional with an updated to 11 JDK, all of those packages will need to be updated and/or rebuilt.  Users' compiled Java programs wouldn't necessarily need to be rebuilt.

And yes, obviously this work will at least need to be done in Cauldron before Mageia 8 is released.
Comment 14 Marc Krämer 2019-10-23 19:20:57 CEST
I've checked a few of the apache packages: they just contain jar, xml and pom (maven xml) files. So we should not need to rebuild them, only do updates if needed. And the same holds for most of the j-packages. That is the idea of (precompiled) platform independent code. There should be very few packages that really do a tight integration into the java virtual machine (like the java debugger). I'm not sure how tight the integration of jboss is, but most of it is just some more jar files.

For the question of LTS or not, I'm not sure I've ever seen lts releases of openjdk. The only lts releases came from oracle and here we have a big change. They want to generate money from lts releases. See e.g. (https://www.baeldung.com/oracle-jdk-vs-openjdk). And as you can see on the official jdk homepage (http://openjdk.java.net/projects/jdk/) no built is marked as lts release.
Comment 15 Frank Griffin 2019-10-23 21:09:37 CEST
Just to be clear, "rebuilt" is not a consideration here for anybody.  No Java app has to be "rebuilt" for a JDK upgrade.  However, it's possible that older *versions* of certain Java apps won't work with the new JDK whether they are rebuilt or not.  If that's the case, they need to be *upgraded* to versions which don't use whatever coding techniques have been deprecated/disallowed in the new JDK.  If there isn't such an upgraded version, that app is out of luck.

Also, LTS is not a concern for openjdk.  LTS is an Oracle construct that has to do with how long Oracle will support a release.  Oracle doesn't support openjdk, so the point is moot.  We should support openjdk versions as they come.  If a version after Oracle's current LTS deprecates something that causes an app to stop working, the app's owner is going to have to deal with it sooner or later.  If their choice is "later", then the user can manually install the LTS version in /usr/local until they catch up.
Comment 16 Marc Krämer 2019-11-14 11:38:14 CET
A good article showing what is state of jdk:

We didn't discuss the possibility to ship more than 1 version of openjdk. Maybe we can ship sth. like "latest" and "lts"/"previous" together. We do this with e.g. postgresql where we ship at least 2 versions.

Since the byte code and most of the class libraries are very stable, I don't expect to have many libraries that needs to be shipped in different versions.

What do you think? Do we have an active maintainer for java? Is there any progress on java in mga8?
Comment 17 David Walser 2019-11-14 23:41:40 CET
Shipping multiple versions would be highly undesirable.  We don't have the resources of the big Linux companies like Red Hat.  We have one maintainer for the openjdk package and it's a lot of work.  Let's please stop wasting time discussing things that won't happen.  I don't know when our packagers plan to start upgrading things in Cauldron.
Comment 18 Marc Krämer 2019-11-15 10:01:40 CET
@David: why is it so much work to maintain 2 versions in parallel? I do this with postgresql as well.
Comment 19 Marc Krämer 2019-11-15 10:03:55 CET
Our current situation is undesireable as well
a) I have to download packages with bundled runtime
b) I use the oracle rpm's
we should make progress here.
Comment 20 David Walser 2019-11-17 17:17:26 CET
Come on Marc, it's not even comparable.  Updating postgresql packages is as simple as changing the version number and pushing it.  Updating the openjdk packages you have to carefully sync in all of the changes RedHat has made through the spec, patches, and other sources.  Having maintained the package for years, I know how much work goes into it.  The situation is the best we can do.  Enough.
Comment 21 Marc Krämer 2019-11-17 18:05:37 CET
I've had a look at the package, and you're right it looks complicated to update it to the latest version (which we still have to do), but keeping an older version as well should just be keeping it.
Fedora has already released versions for 11 and latest (13); for the sources there is sth. about an update script which was not bundled in the SRPM.
And since I didn't find that script I can not tell why updating java is more complicated than updating other packages.

Still all I want to say is, we need updated packages for openjdk since it is a programming language and programmers use the api which is in the current documentation. And we have supported other stacks, which changed fundamentally (e.g. python2 vs. python3), which is comparable to the way java changed from 8 -> 11++
Comment 22 Marc Krämer 2020-01-07 12:12:36 CET
anything new here? anyone working on it?
Marc Krämer 2020-01-07 12:13:59 CET

Whiteboard: (none) => CAULDRONTOO

David Walser 2020-01-07 12:54:47 CET

Version: 7 => Cauldron

Nicolas Salguero 2020-04-20 09:45:11 CEST

Blocks: (none) => 26475

Nicolas Salguero 2020-04-23 11:58:19 CEST

Blocks: 26475 => (none)

Comment 23 Marc Krämer 2020-10-10 13:53:39 CEST
do we get some progress here?
Would be nice to use some newer applications that do not run with our outdated java package :(
Comment 24 David Walser 2020-10-13 21:53:25 CEST
Yes, David and Nicolas have been working hard on this and have made much progress in Cauldron.  Fedora 33 has also made the switch, which was necessary for us.

Whiteboard: MGA7TOO => (none)

Comment 25 Nicolas Lécureuil 2020-10-14 09:48:56 CEST
we still have some apps like jogl2, etc to update, i didn't pass to make them build yet.

CC: (none) => mageia

David Walser 2020-10-14 21:26:16 CEST

CC: (none) => luigiwalser
Priority: Normal => release_blocker

Note You need to log in before you can comment on or make changes to this bug.