So assigning to our java stack maintainers.

Assignee: bugsquad => java

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.

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.

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

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE

and both bugs are closed...
one marked as old the other as duplicate and nothing changes.

Resolution: DUPLICATE => (none)
Status: RESOLVED => REOPENED

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

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

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

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.

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.

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.

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.

Thanks

CC: (none) => guichard.adrien

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.

@David: 
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.

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.

A good article showing what is state of jdk:
https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support/

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?

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.

@David: why is it so much work to maintain 2 versions in parallel? I do this with postgresql as well.

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.

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.

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

anything new here? anyone working on it?

do we get some progress here?
Would be nice to use some newer applications that do not run with our outdated java package :(

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)

we still have some apps like jogl2, etc to update, i didn't pass to make them build yet.

CC: (none) => mageia

openjdk-8 LTS (java-1.8.0-openjdk-1.8.0.275.b01-2.1.mga8.src.rpm) is in M8.

openjdk-11 LTS (java-11-openjdk-11.0.9.6-0.0.ea.1.mga8.src.rpm) is in M8 too and default provided on new installs.

openjdk-latest (java-latest-openjdk-15.0.1.9-4.rolling.1.mga8.src.rpm) is also ready for primetime and landed in Cauldron/updates_testing.


Closing this.

Resolution: (none) => FIXED
CC: (none) => ouaurelien
Status: REOPENED => RESOLVED