Just so everyone is aware, Oracle has now gone with an LTS release system for Java. I'm not entirely sure if the affects openjdk, but I would assume it does. Has anyone already tried packaging this, or should I go ahead and give it a go?

Holy shit. This is going to be a bitch to package....

I have done more research into the issue of multiple JDKs @ikey (we started this convo on Reddit). It is possible to install multiple JDKs in parallel without any sdk conflict because openjdk will install into /usr/lib64/openjdk-{major_version}. JAVA_HOME is unset by openjdk from what I can tell. The only problem Solus will face would be the executables. I am currently using jenv to manage this, but I don't think expecting users to install a third party tool to manage jdks is effective. Ubuntu solves this problem with update-alternatives it seems. A solution could be to patch the executable names using java-lts/javac-lts for JDK 8, but once JDK 11 (also LTS), we might have a problem. Another solution would be to allow the newest installed jdk to overwrite the java executables, and point to a help center page to add a function that would symlink the executables to the desired jdk version. Another way would be to again overwrite, but warn at install time what is happening and to point to installing jenv to manage JDKs. We could also just say you can either have the LTS OR the current version. I honestly don't really see an easy way around this without the user taking responsibility for managing this themselves. Thoughts? From what it seems Java 10 will be much easier to package as everything seems to have been moved to a single repo from what I've read. I wouldn't mind creating the help center page if it came down to it.

List of all executables provided by openjdk-8:

/usr/bin/appletviewer
/usr/bin/extcheck
/usr/bin/idlj
/usr/bin/jar
/usr/bin/jarsigner
/usr/bin/java
/usr/bin/java-rmi.cgi
/usr/bin/javac
/usr/bin/javadoc
/usr/bin/javah
/usr/bin/javap
/usr/bin/jcmd
/usr/bin/jconsole
/usr/bin/jdb
/usr/bin/jdeps
/usr/bin/jhat
/usr/bin/jinfo
/usr/bin/jjs
/usr/bin/jmap
/usr/bin/jps
/usr/bin/jrunscript
/usr/bin/jsadebugd
/usr/bin/jstack
/usr/bin/jstat
/usr/bin/jstatd
/usr/bin/keytool
/usr/bin/native2ascii
/usr/bin/orbd
/usr/bin/pack200
/usr/bin/policytool
/usr/bin/rmic
/usr/bin/rmid
/usr/bin/rmiregistry
/usr/bin/schemagen
/usr/bin/serialver
/usr/bin/servertool
/usr/bin/tnameserv
/usr/bin/unpack200
/usr/bin/wsgen
/usr/bin/wsimport
/usr/bin/xjc

Another solution that I have thought of is patch the executable locations to be /usr/bin/java-lts and /usr/bin/java-current, and have users add to PATH accordingly. This is a very interesting problem that does not seem to have a simple solution.

I think Arch Linux just made a helper script that allowed people to switch easily between different JDK versions, archlinux-java.
Looks like a pain in the butt. Best of luck, though!

$ archlinux-java status
Available Java environments:
  java-7-openjdk (default)
  java-8-openjdk/jre

See: https://wiki.archlinux.org/index.php/Java#Switching_between_JVM

I'm currently working something similar in C++. Fun little project.

Any updates on this? Not great to have a rolling-release distribution that’s 1/2 major versions behind on such a widely used package.

@ikey What should be done for this? Arch Linux and Ubuntu has a script to switch between Java versions. Should Solus do the same? Should all Java versions conflict, which’d stop people from installing multiple versions for compatibility etc.? I feel like some further direction from you is needed with this package, in particular.

Might even be able to use parts of this script from Arch Linux: https://git.archlinux.org/svntogit/packages.git/tree/trunk/bin_archlinux-java?h=packages/java-common

(Sorry for the ping, too.)

@Snuggle rolling doesn't mean bleeding. openjdk-10 only went GA a month ago and I'm not convinced it is ready for general consumption.

As for openjdk-9, I decided to hold off because there hasn't been a need for it for any of the Java applications we ship, nor has there been a noticeable demand from the community. If we were to include openjdk-9 it would be as its own package not as a replacement for openjdk-8. And honestly I am leaning towards skipping 9 altogether given how much backpedalling in 10 was done to make up for design mistakes in 9.

We are still deciding on how to handle naming conflicts for things like Java, but we will not use anything as primitive as a Bash script to manage switching between versions.

I'd suggest getting a solution for switching JDK versions ready, and delay adding an updated JDK package until JDK 11 (the next LTS) is released in six months.

In T4578#112876, @serebit wrote:

I'd suggest getting a solution for switching JDK versions ready, and delay adding an updated JDK package until JDK 11 (the next LTS) is released in six months.

Could do. LTS honestly sounds the sanest moving forward.

To that end (waiting until JDK 11), we may have an issue.

Kotlin now requires both JDK 8 and JDK 9 to build, which means that either Kotlin updates are blocked until the dependency on JDK 9 is removed, or Kotlin will need to swap from building from source to using the prebuilt binaries supplied by JetBrains.

I'm testing the build for Kotlin 1.2.40 to see if the inclusion of JDK 9 as a dependency is really necessary, but this may complicate things regardless if more software starts to depend on an updated JDK.

Edit: The build failed. Looks like JDK 9 really is required.

Yeah. Java 9, despite how bad it seems, does seem necessary for development work. I believe it deserves a package, mostly for developers’s ease of use.

I do agree with your point about 10 being too unstable for use at the moment, though. Last time I checked, it wasn’t available on Arch yet.

I also don’t know what you mean by a primitive bash script, @DataDrake. Do you plan to have a GUI application to manage switching between versions instead or...?

Does Kotlin actually require Java 9 to build? Why would Kotlin depend on an out of date version of Java. I am in favor of packaging Java versions upon release. If you only packaged LTS versions you would still see the same issues because LTS versions of Java have overlap.

As described here, Kotlin (since 1.2.31) depends on Java 1.6, 1.7, 1.8, and 9 to build. However, if not working on bytecode or the standard library, 1.6 and 1.7 aren't needed. The Kotlin compiler currently in the stable repo was the last version to omit requiring JDK 9.

The reasoning for this is likely because of Java 9 specific attributes like Jigsaw, which could require building against both 1.8 and 9.

That is extremely weird but thanks for the lesson

I am going to plug this here: https://gitlab.com/tristan957/java-env-manager. It's a way to manage different versions of Java for those who have jdk10 + jdk8 + jdkx installed on their systems. If you end up using it please provide feedback :)

In T4578#113168, @Snuggle wrote:

I also don’t know what you mean by a primitive bash script, @DataDrake. Do you plan to have a GUI application to manage switching between versions instead or...?

I'm not DD, but I'm guessing this implies that something properly architected in Go would be the core team's solution of choice.

I'm going to go ahead and bump this @DataDrake, since now we have a package that requires openjdk-9 to continue updating--Kotlin. Only as a builddep though, not as a rundep. I'd package openjdk-9 myself, but I have nowhere near the expertise required to do so.

Well part of the problem still lies in how to handle multiple java installations. Unfortunately that has not been discussed much so I would like to get that discussion going again

Do we necessarily need a jdk switcher at the moment? Why not just keep the java and javac symlinks in /usr/bin to openjdk-8 only for now? That'd let us add multiple JDKs without running into conflicts.

I agree to just leave the symlinks to java 8. We could create for now a simple help center page to explain how to change the symlinks for those that would need it.

I would rather see us get OpenJDK 10 to be perfectly honest. From what I can tell, OpenJDK 9 is EOL and not receiving security updates.

As far as symlinks and things go, I would expect that for most things, setting JAVA_HOME is enough. Though I doubt in practice it will be that easy. I expect anyone shipping JDK 10 binaries to patch any shell scripts or .desktop entries to set JAVA_HOME correctly until OpenJDK 8 can be deprecated.

In T4578#129319, @DataDrake wrote:

I would rather see us get OpenJDK 10 to be perfectly honest. From what I can tell, OpenJDK 9 is EOL and not receiving security updates.

I'm inclined to agree, except for the fact that the Kotlin compiler requires OpenJDK 9 in order to be compiled. We could switch to using the precompiled binaries provided by JetBrains if need be, but if that's not in the cards, including JDK9 is our only option if we're going to continue updating Kotlin.

Then we are going to have to either patch kotlin to allow a build against 10 or just stay on the current release until it is officially supported. Really all there is to it.

I doubt that's going to happen. One of Kotlin's features is that it's able to target multiple JVM versions, and the build instructions actually recommend having JDK 1.6, 1.7, 1.8 and 9 installed; however, only 1.8 and 9 are actually required. More likely than not, once JDK 10 is added to the requirements, it won't be replacing JDK 9. We'll just have to leave it as-is until something changes, I suppose. That, or patch it, like you said.

I don't understand Kotlin in regard to them needing older EOL versions of Java.

Backwards compatibility for Android, mostly.

@DataDrake Newer versions of Gradle also require Java 9 to build Gradle from source, apparently. Might want to reconsider blocking JDK9 from the repos with that in mind-- without it, you may be leaving the entire JVM build system behind.

@DataDrake I had an idea. Could we use usysconf to override the java executables much like Ubuntu has update-alternatives when a user installs or reinstalls a java package?

Not really. You can't really decide which one to pick that way. Even expecting it to always be the last one installed is confusing. Especially because then we have to test every java package against all JDKs which is absurd.

The only true way to fix this is to:

• Require users to set their own JAVA_HOME to specify the JDK, if they are using java directly
• Hard-code all java packages to set JAVA_HOME for executables

Even then, you will inevitably get into the python situation where we end up with different packages for the same sources, targetting different versions of the toolchain. I absolutely do not want to see this happen.

Now, if someone wanted to submit a patch for OpenJDK 9 that requires anything that uses it to explicitly set JAVA_HOME rather than using PATH to do lookups (e.g. nothing in /usr/bin), that is something I am willing to entertain.