Fedora's Java Packages Have Fallen Into Rough Shape

[nadirx]

The real problem here isn't Fedora. It's Java. Java as a language is falling behind fast. It just launched v17 without support for coroutines (which Kotlin supports for at least 3 years now) and with an "enhanced" switch that doesn't even match what Scala has offered for over 5 years now. That's why communities start to look elsewhere. Sure, nice things have happened for the JVM. But that's simply not enough.

Keep in mind, whatever feature missed the v17 train will have to wait an additional 3 years, until the next LTS release.

I think Java is actually pretty healthy, and moving in the right directions. Kotlin and Scale may have moved faster to adopt certain modern language features, but there is so much more happening under the hood (Shenandoah and ZGC, Project Loom, Valhalla and Panama, etc). GraalVM is also exciting.
The next LTS will be JDK 21, in September 2023, so 2 years.

[mdedetrich]

I am not aware of any mainstream distros that heavily patch OpenJDK. You do have to pass a TCK test suite to be compliant before using the name. This is not really a relevant factor.

In context I was talking about Debian, which did do a backport of an upstream JDK patch and actually caused their version of JDK to behave differently https://twitter.com/jroper/status/10...573888?lang=en

I do use arch for different thing and its kicked me in the teeth at times with different java programs. Remember Eclipse core version is only on JRE 11 if you use rolling arch it puts you on JRE 17 or new guess what different Eclipse plugins are going to screw up. that work perfectly with JRE 11

There is no zero problems on Arch is false. The problem here is java is not properly forwards compatible. So you need the right version of JRE with the application or bad things can happen. Yes you can also have the case where you have two application one needs JRE 17 and the other needs JRE 11 to work now you have a problem even with arch packaging the dependency hell problem.

Arch has a switcher to switch between Java versions (see https://wiki.archlinux.org/title/jav...ng_between_JVM) and you can use AUR to install older versions of JDK if you need to

I know this because I have done this before

[timrichardson]

. Please don't blame other fully functional cross-platform software when this single project is using piece of shit technology.

Meanwhile, Intellij users wait and wait for native wayland support.

[caligula]

Meanwhile, Intellij users wait and wait for native wayland support.

Could be. I'm not saying other projects are doing any better. I suppose Oracle would be willing to add Wayland support to Swing and even if they weren't maintaining JavaFX themselves, they might be in favor of improving JavaFX more than SWT. Meanwhile, doesn't XWayland work for Java apps? Why I'm not in favor of SWT is it's a much lower level toolkit and involves a lot more manual resource handling. The programming API seems outdated. This can affect the programmer productivity. Also since it's not an official JDK project, there will always be a slight delay when introducing new features like modules or updates to official GUI toolkits. Just like Apache they've also accumulated lots of old conventions over the years. It's hard to clean up the code if you want to maintain compatibility with old Java versions. Eclipse related software also feels somewhat bloated in general, and contains unnecessarily architectural complexity. The platform isn't built with the requirements of a single IDE in mind. They have their own osgi module system, custom update servers, marketplace etc. If you ever developed a plugin for Eclipse, maintaining the app will be a full time job. There will be just so many architectural changes over the coming months/years. Typical life span of unmaintained software might be 3 months, e.g. Eclipse 2021-06, with breaking changes in 2021-09.

[oiaohm]

Arch has a switcher to switch between Java versions (see https://wiki.archlinux.org/title/jav...ng_between_JVM) and you can use AUR to install older versions of JDK if you need to

I know this because I have done this before

I have cases where I have to be running 3 or more different vendor enterprise applications in java. Yes they can be wanting different JRE versions. Horrible due to their code they fire up applications after started and by pass

#!/bin/sh
export PATH="/usr/lib/jvm/java-8-openjdk/jre/bin/:$PATH"
exec /path/to/application "$@"

Yes the best solution with theses is containerisation of some form. As in when I run this application its in X container there is only the jre that application works with the others have being taken out of existence.

Yes that switch JVM version globally has been a nice kick in teeth for me as well due to making X application I do what I need in X start up Y now its broken. Lot problems I run into with java would be solved with a per application JVM option like set in .desktop file enforced by a cgroup that basically makes all the non support by application JRE hidden from the application. So it cannot do the wrong thing with its own internal java JRE detect engine that nicely ingores path.

The switcher being global is the problem. We are needing a per application switcher that is better than the PATH one and is basically backed by cgroups so applications cannot decide to-do different than the end user wants..

[Developer12]

Java in Fedora has really been dead for years so this is nothing new + Java needs to Die like Flash did

Tell that to anyone taking computer science. Java is the archetypal OOP language.

[onlyLinuxLuvUBack]

I have cases where I have to be running 3 or more different vendor enterprise applications in java. Yes they can be wanting different JRE versions. Horrible due to their code they fire up applications after started and by pass

#!/bin/sh
export PATH="/usr/lib/jvm/java-8-openjdk/jre/bin/:$PATH"
exec /path/to/application "$@"

Yes the best solution with theses is containerisation of some form. As in when I run this application its in X container there is only the jre that application works with the others have being taken out of existence.

Yes that switch JVM version globally has been a nice kick in teeth for me as well due to making X application I do what I need in X start up Y now its broken. Lot problems I run into with java would be solved with a per application JVM option like set in .desktop file enforced by a cgroup that basically makes all the non support by application JRE hidden from the application. So it cannot do the wrong thing with its own internal java JRE detect engine that nicely ingores path.

The switcher being global is the problem. We are needing a per application switcher that is better than the PATH one and is basically backed by cgroups so applications cannot decide to-do different than the end user wants..

java code once... hell to run anywhere

[mdedetrich]

Meanwhile, Intellij users wait and wait for native wayland support.

To be frank the majority of Intellij users probably don't care about Wayland as they have far bigger problems.

[krzyzowiec]

Rust/Wasm might become an alternative some day, but the maturity isn't quite the same. Heck most server distros won't even ship with any decent wasm runtime.

Rust is never replacing Java on the server side. It’s a good language, but the mental overhead involved in having to manage memory yourself is not worth it in web programming, not unless you are Google or Amazon anyway.

[bug77]

I think Java is actually pretty healthy, and moving in the right directions. Kotlin and Scale may have moved faster to adopt certain modern language features, but there is so much more happening under the hood (Shenandoah and ZGC, Project Loom, Valhalla and Panama, etc). GraalVM is also exciting.

Zgc is a no-issue, I wouldn't even list that in the release notes. Loom is coroutines , which is yesterday's news in any language worth a damn. The others can be interesting, should they come to fruition, I'm not familiar with their progress. Even so, Kotlin or Scala remain far better languages, if you're tied to the JVM.

The next LTS will be JDK 21, in September 2023, so 2 years.

Thanks, I missed that. Just like I missed when Oracle moved LTS releases from the promised "every 3 releases" to "every 3 years"