Page MenuHomeSolus

OpenJDK & OpenJFX Upgrade Experiment
Open, WishlistPublic

Description

DataDrake Edit: Because JDK11 is GA now, let's keep track of it here as well.

Our Java Stack is relatively not-very-well-maintained, as an experiment let's try to see if we can upgrade the entire stack to JDK 11.

Java Itself

  • OpenJDK 11
    • Note: Since we don't provide JDK 10 the initial build needs to be bootstrapped as it works on a n=n OR n-1 principle to build.
    • JRE's have been deprecated but can still be built with make legacy-jre-image

Note: both of these are licenced under GPL-2.0-with-classpath-exception but this licence has been deprecated by SPDX from 2.0rc2 onwards.

Build Tools

  • Ant (apache-ant)
    • Updated to 1.10.6, no problems noted. Requires documentation to not be built.
  • Maven (apache-maven)
    • No problems noted.
  • gradle
    • Updated to 5.5. No problems noted. Some programs may require an older version (use gradlew instead)
  • sbt
    • No problems noted against bfg-repo-cleaner.
    • not tested against 11

Dependencies

  • chatty
    • No problems noted.
  • pdfsam
    • No problems noted
  • ipscan
    • No problems noted
  • dbeaver
    • Not tested against 11
  • projectlibre
    • Doesn't build against 11
  • fritzing
    • Unsure where java is used in this application
  • kotlin-native
    • No problems noted
  • kontalk
    • No problems noted
    • Not tested against 11
  • bfg-repo-cleaner
    • Update to 1.13.0 required. No problems noted.
    • Not tested against 11
  • java-service-wrapper
    • Doesn't build against 11
  • i2p
    • Updated to 0.9.35, compiles fine against JDK10 but the systemd tmpfiles it provides are borked though, didn't bother to fix it.
    • Not tested against 11
  • xml-commons
    • Compiles with javac -source 8, not yet tested
    • Not tested against 11
  • icedtea-web
    • Updated to 3.8.0, only officially supports JDK 8
    • Not tested against 11
  • freeplane
    • Updated to 1.6.15, no problems noted.
    • Not tested against 11
  • scala
    • Update to 2.12.6 required. No problems noted.
    • Not tested against 11
  • jitsi
    • Doesn't build against JDK 11
  • modelio
    • Doesn't build against JDK 11, network dependencies related.
  • jxrlib
    • Updated to 0.2.1. Encoded and Decoding between formats successfully. No problems noted
  • octave
    • not tested against 11
  • libreoffice
    • not tested against 11
  • darktable
    • not tested against 11
  • kodi
    • not tested against 11
  • minecraft
    • No problems noted

Conclusions
JDK11 is the current long-term release, with development on JDK8 slowing down at this point. Projects which don't show any initiative in regards to supporting JDK11 (compile and runtime) will most likely be dropkicked after a reasonable timeframe. We have no plans currently to package more than one JDK at a time.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

FTR: dbeaver now supports Java 11 and it seems like pdfsam 4 requires Java 11.

OpenJDK 10 is needed to update cryptomator to 1.40, see T7235

DataDrake renamed this task from OpenJDK 10 & OpenJFX 10 Upgrade Experiment to OpenJDK & OpenJFX Upgrade Experiment.Mar 19 2019, 2:49 AM
DataDrake updated the task description. (Show Details)
louhy added a subscriber: louhy.May 13 2019, 12:18 AM

OpenJDK 9+ is now required to build newer Gradle versions. From my local testing, it would seem that OpenJDK 11 fills the requirement.

In fact, I just managed to build Gradle 5.4.1 with OpenJDK 11 only (using the JDK distributed by sdkman).

Unless it can be used to build and run all of our Java software, I'm still not willing to upgrade it.

Why not 12 since it is the GA release?

I'll run some testing with JDK 12. I would like to note that at the moment, Kotlin requires both OpenJDK 8 and OpenJDK 9 at a minimum to build, so that's generally out of the question until either someone writes a patch or the requirement changes.

If it requires both, I'm more inclined to nuke it from the repo tbh. It's proven to be something that we can't keep up-to-date on a monolithic java stack and still no one has presented me with a way to support two or more JDK that isn't awful.

I'm not opposed to removing Kotlin (I was the one who contributed it in the first place). If anything, Gradle is more my focus now, since it's the tool that's most often used for Kotlin development.

As it turns out, you need to have JDK 11 installed to build JDK 12. Not sure how to handle that.

Not entirely true, it requires either a pre-built JDK 12 or a JDK 11.

If we need to rebootstrap from binary, that's fine.

louhy added a comment.May 20 2019, 1:48 AM

Not sure if this helps at all, probably not as this is a pretty different use-case, but I use sdkman to manage multiple versions of the JDK (and Gradle). Easy as a single command to switch to and setup whatever JDK you need.

Unfortunately sdkman isn't designed to support the JDK builds that we ship. It expects to use theirs.

We don’t necessarily need to use sdkman directly, but we could take inspiration from it for handling multiple JDKs, if that’s still on the table.

So far, the best way I've come up with for handling multiple JDKs has been to hard code both JAVA_HOME and the path of the java executable in the .desktop files or scripts for user applications. However, that solution breaks down for command-line tools like gradle. Those would require us to tie them directly to a single JDK, something that may prove confusing to end-users.

I still think the best step for us, especially considering the relatively small number of Java applications in the repository, is to step through upgrading to the latest JDK. Once there we will hold back updating as needed to allow applications to catch up, but will try to avoid stepping forward more than one major release at a time.

So let's try getting to the GA release (JDK 12) in as few steps as possible, and take it from there. People are of course welcome to use sdkman themselves to manage the JDKs they need for development.

I’ll see about testing Gradle with JDK 12. I did give building the JDK from scratch a try, but writing a package.yml for the whole JDK is way above my skill level. If anyone else manages to make a working buildscript, I’ll gladly test with a fresh eopkg built from it, but I’ll have to use an existing binary until then.

We should just be able to step through: 8-9, 9-10, 10-11, 11-12. If we can skip any steps, even better. No rebootstrap necessary.

Well, if anyone manages it, let me know. I'll be testing with a prebuilt JDK until then.

serebit added a comment.EditedMay 20 2019, 5:54 AM

Gradle version 5.4.1 (latest version) supports running builds with JDK 12. However, it appears to be impossible to build Gradle 5.4.1 itself using JDK 12, as the source and target compatibility is set to JDK 6, while JDK 12 appears to have dropped JDK 6 target support and only supports JDK 7 and up. In addition, Gradle 5.4.1 can no longer build using JDK 8, as it requires JDK 9 or newer. It seems to me that a move to JDK 11 may be our best option, considering these circumstances (at least temporarily).

I couldn't build Gradle with JDK 12.0.1-zulu, but I managed to do so with OpenJDK 11.0.1. I also managed to build one of my projects successfully using Gradle on the same OpenJDK 11.0.1 build.

Currently doing testing with building the above packages with JDK 11, I believe JDK 11 is our best bet considering almost nothing supports being built with JDK 12 yet. Besides, rolling, not bleeding.

Test results with building packages with OpenJDK 11 instead of OpenJDK 8:

Gradle 5.4.1

Built successfully

Maven 3.6.1

Built successfully after bootstrap

ipscan 3.5.5

Built successfully (now supports JDK 11 officially)

joebonrichie updated the task description. (Show Details)Jul 7 2019, 12:30 AM

Starting testing against OpenJDK 11, will test all the reverse deps in the coming days. Volunteers are welcome! YAML files are provided to build your own Java. Note that a lot of the applications will need some fixing up to build and run properly.

Just my 2 cents contribution to this huge thing.

Note: both of these are licenced under GPL-2.0-with-classpath-exception but this licence has been deprecated by SPDX from 2.0rc2 onwards.

On SPDX 3.X the identifier for this should be GPL-2.0-or-later WITH Classpath-exception-2.0

Note that licenses being lists in YPKG, it's currently not possible to make distinction between AND and OR. I guess we must specify the AND's and chose the one we prefer for the OR's. I don't know if @DataDrake want to change this in YPKG3 or he just wants to check if the identifiers are SPDX 3.x formatted.
(sorry of this off topic)

Staudey added a subscriber: Staudey.Jul 7 2019, 5:23 PM

Just built openjdk-11 and vanilla Minecraft runs fine with this new version.

EbonJaeger added a comment.EditedJul 7 2019, 5:28 PM

Echoing @Staudey, Minecraft seems to work fine so far:

  • Joined a server and everything worked
  • Created a new Single Player world and everything worked as expected

In addition to that, using IntelliJ IDEA seems to work so far, and building projects targetting Java 8 with maven (rebuilt to use openjdk-11 as the dependency) still works as expected. I think I still have a Gradle project around here somewhere that I can test the rebuilt Gradle 5.5 with later.

*EDIT: Building a Gradle project also worked as expected.

joebonrichie updated the task description. (Show Details)Jul 7 2019, 5:38 PM
joebonrichie updated the task description. (Show Details)Jul 7 2019, 5:47 PM
joebonrichie updated the task description. (Show Details)
joebonrichie updated the task description. (Show Details)Jul 7 2019, 6:14 PM
joebonrichie updated the task description. (Show Details)Jul 7 2019, 6:19 PM
joebonrichie updated the task description. (Show Details)Jul 7 2019, 6:23 PM
Beer added a subscriber: Beer.Sep 4 2019, 3:22 AM

I don't know how important this is to the conversation, but Phoenicis (the successor to PlayOnLinux) requires Java 11. Figured I'd mention it since I suspect this is something a lot of people will want once it's released. https://github.com/PhoenicisOrg/phoenicis

Yeah I don't see any other solution than to support multiple java versions moving forward. The java application world just moves too slowly. We might just about be able to drop openjdk8 but we'll need to support jdk9 and jdk11.

oly added a subscriber: oly.Nov 5 2019, 5:00 PM

Maybe we should create a new package called openjdk and start with JDK 9 for now, since most (if not all) things that we package support it. As more packages add support for higher JDK versions, we can update the openjdk package to newer major versions.

Why not just update directly to JDK13 have that be the only available JDK package for Solus? If users need an alternative they are free to download it. Updating to an already old(ish) version doesn't make much sense to me. That way Solus will be on a suitable Java version for years to come.

Because (and I'm estimating here) *none* of the packages on this list build with, or fully support, JDK 13. That's the problem here.

Ah I assumed most maintainers would have already upgraded to add support for it since it came out 2 months ago. If not then 11 is probably a good middle ground

Not everything here builds with 11 either. Read the original post, it shows which packages have been tested and either fail/succeed building with 11.

@ZVNexus, nope. Most things still only support OpenJDK 8 (LTS). This happens a lot with Java and the faster cadence with these new major releases has scared developers off from keeping up. Consider for a moment that Java 5 to 6 was 2 years, 6 to 7 was 5 years, 7 to 8 was 3 years, and 8 to 9 was 3 years. Starting with 9, they moved to a March/September release cycle which makes this even worse. Couple that with the bad taste than JDK 9 left in everyone's mouth, and JDK 8 continues to stay.

If you are developing for Java, you will need to manage your own JDKs. We can't just deprecate actively developed software every time it falls behind the stable releases and until someone actually takes the time to sort out multiple LTS releases, we will be sticking to a single JDK at a time.

The unfortunate truth, though, is that some software (like Gradle) now *requires* building with JDK 9+, so if we're not bundling multiple JDKs at a time, we need to make a decision. Do we shed software like Kotlin and upgrade to a newer JDK, or do we stay on JDK 8 and allow commonly used Java packages like Gradle to rot?

Again, someone needs to step up and sort out having multiple Javas. That's been the case for ages now and I simply don't have time to do it myself. It's not rocket science and mainly means setting JAVA_HOME in a bunch of places.

livingsilver94 added a comment.EditedNov 21 2019, 7:44 PM

Again, someone needs to step up and sort out having multiple Javas. That's been the case for ages now and I simply don't have time to do it myself. It's not rocket science and mainly means setting JAVA_HOME in a bunch of places.

I'm interested in doing this (hopefully not alone). Can we open a dedicated issue to have a table to track all the packages? And maybe also a little HOW-TO pointed list.

EDIT: oops, that's the very issue. Still can we have the tutorial? :P

Pretty simple really. Each JDK should have its own directory in /usr/lib64. None of the JDKs should have symlinks in /usr/bin. Everything that uses Java will need to be patched so that they don't call /usr/bin/java, but instead call JAVA_HOME/java. This might be as simple as changing a shell script from /usr/bin/java to /usr/lib64/openjdk-<num>/bin/java or setting JAVA_HOME in a .desktop file.

[...] or setting JAVA_HOME in a .desktop file.

I'm not sure I like this solution. One may want to launch an application from terminal for debugging purposes. All the rest is crystal clear.
So what are going to ship? OpenJDK 8 and 11?

What does changing a .desktop file have to do with running something from the terminal?

If you set JAVA_HOME in a .desktop file, you have the variable set only if you launch the application from that file, but not if you run it in terminal. Or not?

Pretty simple really. Each JDK should have its own directory in /usr/lib64. None of the JDKs should have symlinks in /usr/bin. Everything that uses Java will need to be patched so that they don't call /usr/bin/java, but instead call JAVA_HOME/java. This might be as simple as changing a shell script from /usr/bin/java to /usr/lib64/openjdk-<num>/bin/java or setting JAVA_HOME in a .desktop file.

Alternatively, /usr/bin/java could be a symlink to whichever JDK is currently selected, and created by the jdk switcher.

Alternatively, /usr/bin/java could be a symlink to whichever JDK is currently selected, and created by the jdk switcher.

No. I will not accept these kinds of solutions. They are not stateless and frankly, brittle.

If you set JAVA_HOME in a .desktop file, you have the variable set only if you launch the application from that file, but not if you run it in terminal. Or not?

If you are debugging wouldn't you be looking at the .desktop file to see what to run? I don't see this as something you would need to do unless you are maintaining a package like that. In which case, most of the time we are shipping the .desktop file anyways, so it becomes pretty apparent.

OK I get your point.

Any proposals for how we handle JAVA_HOME for terminal based applications such as jxrlib?

livingsilver94 added a comment.EditedNov 22 2019, 10:42 AM

An ugly hack would be moving the real binary inside /usr/share and have in /usr/bin a shell script that does JAVA_HOME=stuff jxrlib $@. Yeah, very ugly.

That's not a hack though. That's how we handle most Java stuff already.

Ah. Well okay then, I've always considered this approach naive. Glad I'm wrong.

louhy removed a subscriber: louhy.Nov 24 2019, 4:14 AM
livingsilver94 added a comment.EditedNov 25 2019, 12:24 AM

OK I updated both apache-maven and apache-ant, plus two packages I regularly use and maintain. The two Apache build tools should lead the way to the other maintainers to adapt their Java packages.

I've just realized there's also gradle to patch.

Hey, sorry to just jump in here but figured I could contribute some useful information on the whole Minecraft/Java front.

  1. Minecraft generally runs fine on OpenJDK 10, 11, 12, and 13 with the exception of a few specific builds. (Unfortunately I did not keep a list of these while testing)
  2. Optifine now packages their own custom modded "launcher" which fixes previous launch problems with java 9+
  3. Forge is guaranteed to be a problem as it relies entirely on reflection which was locked down as of Java 9 3.1 The forge developers don't seem too keen on updating to be compatible with newer java versions 3.2 While using sdkman is an option, it is not the most user-friendly solution to providing openjdk-8 for those who need it
  4. Fabric also currently does not function on Java 9 or higher
  5. Spigot also relies on reflection and therefore does not work with java 9 or higher. (less important because it's a server thing but worth mentioning)
serebit added a comment.EditedMar 10 2020, 5:04 PM

Alternatively, /usr/bin/java could be a symlink to whichever JDK is currently selected, and created by the jdk switcher.

No. I will not accept these kinds of solutions. They are not stateless and frankly, brittle.

They are definitely brittle, I won't deny that. The issue with not taking this approach, though, is that the java command won't be runnable from the command line, meaning JARs won't be easily runnable either without a global alias. Maybe include a symlink from /usr/bin/java8 to the actual java8 binary, etc?

serebit updated the task description. (Show Details)Mar 10 2020, 5:22 PM
TheUnnamedEngineer added a comment.EditedMar 11 2020, 5:54 AM

Maybe include a symlink from /usr/bin/java8 to the actual java8 binary, etc?

I was thinking the same thing, That's how many systems currently handle dual installations for Python2 and Python3.
Though, I would recommend adding some warning when running the java command to inform people that they're running Java 12 just in case they wanted Java 8.

akrenz added a subscriber: akrenz.Apr 6 2020, 11:27 PM

Pretty simple really. Each JDK should have its own directory in /usr/lib64.

I think this is the "best" solution. Afterwards one could select his Java version via an extra cmdline tool which creates symlinks for java/javac/jshell/jar. That's how Debian is doing it for update-alternatives (https://linux.die.net/man/8/update-alternatives) or Arch for archlinux-java (https://wiki.archlinux.org/index.php/Java#Package_pre-requisites_to_support_archlinux-java).

Proposal:
Install the specific Java installations as a subfolder under /usr/lib64/java/ (or /usr/lib64/jvm), e.g. /usr/lib64/java/openjdk-8 or /usr/lib64/java/openjdk-11
Additionally a directory named /usr/lib64/java/default is created which points to the currently selected openjdk. Each Desktop Application could either use the default installed openjdk symlinked /usr/lib64/java/default or select the one it needs under /usr/lib64/java via the Environment Variable JAVA_HOME. For CLI applications Solus could have symlinks under '/usr/bin/' pointing to /usr/lib64/java/default/bin/
To switch between different openjdk versions create a small cli application which recreates the symlinks under /usr/lib64/java/default and /usr/bin.
Maybe reuse the code from archlinux-java and rename it to solus-java?

tuxayo added a comment.Apr 7 2020, 2:26 AM

Pretty simple really. Each JDK should have its own directory in /usr/lib64.

I think this is the "best" solution. Afterwards one could select his Java version via an extra cmdline tool which creates symlinks for java/javac/jshell/jar. That's how Debian is doing it for update-alternatives (https://linux.die.net/man/8/update-alternatives) or Arch for archlinux-java (https://wiki.archlinux.org/index.php/Java#Package_pre-requisites_to_support_archlinux-java).

About the «one could select his Java version via an extra cmdline tool which creates symlinks» I don't think it's a right solution for Solus. See this comment:

T6658#161255

I think a good option would be to have a binary at /usr/bin/java that prints the currently installed JDKs and their associated binaries, like java8, java11, etc. Helps people who are used to running java -jar xxxx.jar.

You shouldn't be running java -jar directly in Solus. We support the JDK solely for the applications we ship and for developers. The applications we ship can be tied to a specific OpenJDK package and won't need a /usr/bin/java. Java developers will be using an IDE or intelligent editor which can be configured for a specific JDK as well. This also doesn't need a /usr/bin/java. We will be replacing generic packages like gradle and apache-ant with JDK specific packages (i.e. gradle-8) in order to lessen the issues we have had supporting multiple JDKs simultaneously.

Please be patient. I am swamped at work right now and have higher priority issues in Solus to deal with in the little free time I do have, else this would have already been implemented. And please, this isn't debate club. I have laid out the solution that I believe is the best path forward for Java on Solus after almost two years of arguments here and in other communications channels about all of this and more.

You shouldn't be running java -jar directly in Solus. We support the JDK solely for the applications we ship and for developers. The applications we ship can be tied to a specific OpenJDK package and won't need a /usr/bin/java. Java developers will be using an IDE or intelligent editor which can be configured for a specific JDK as well. This also doesn't need a /usr/bin/java. We will be replacing generic packages like gradle and apache-ant with JDK specific packages (i.e. gradle-8) in order to lessen the issues we have had supporting multiple JDKs simultaneously.
Please be patient. I am swamped at work right now and have higher priority issues in Solus to deal with in the little free time I do have, else this would have already been implemented. And please, this isn't debate club. I have laid out the solution that I believe is the best path forward for Java on Solus after almost two years of arguments here and in other communications channels about all of this and more.

Don't misunderstand, we're (if I may speak for the rest of us) not trying to push you into doing this any sooner than makes sense considering the rest of your workload. We're just discussing ideas, is all. If you've made up your mind, you've made up your mind, and we won't try to change it.

Also, so long as Minecraft works, I don't think most people will care how this is handled :)

tuxayo added a comment.EditedApr 7 2020, 3:57 AM

Please be patient. I am swamped at work right now and have higher priority issues in Solus to deal with in the little free time I do have, else this would have already been implemented. And please, this isn't debate club. I have laid out the solution that I believe is the best path forward for Java on Solus after almost two years of arguments here and in other communications channels about all of this and more.

Don't worry, no pressure for you. Actually you aren't assigned. So for me the state was: awaiting to have someone who can implement the planed solution.

A bit off topic but related to finding someone to implement this: I searched if Phabricator was supported in Bountysource. And it isn't:
https://github.com/bountysource/core/issues/435
https://www.bountysource.com/issues/1384856-add-support-for-phabricator

So for me the plan is to throw few bucks on the related bounty to be able to start bounties for Solus and then throw a few bucks here. I don't think of a better way for someone not having the skills or time to implement this (T6658) task.

akrenz added a comment.Apr 7 2020, 6:51 AM

Please be patient. I am swamped at work right now and have higher priority issues in Solus to deal with in the little free time I do have, else this would have already been implemented. And please, this isn't debate club. I have laid out the solution that I believe is the best path forward for Java on Solus after almost two years of arguments here and in other communications channels about all of this and more.

Would it help to supply packages for openjdk 8 and openjdk 11 which install under different locations in /usr/lib64? I could also do the needed changes for the existing packages to use their specific required java version.

I would be happy to help in that.