Fedora's Java Packages Have Fallen Into Rough Shape

[caligula]

I don't think there's much point packaging up something like Maven as an RPM. Java developers typically download their own Maven version. And the need to have it in the Fedora repo diminishes even further with the increased adoption of the Maven Wrapper, which is inspired by the Gradle Wrapper, and planned to be mainlined into Maven soon. With the Maven Wrapper, a project will download the required Maven version on-demand (and install it somewhere in the `$HOME/.m2` folder) and as-needed during build.

Many apps don't use Maven or Gradle. For example VisualVM is built using Ant. Some apps like pdftk provide both Maven and Ant/Ivy builds, but distros might favor Ant & Ivy for legacy reasons.

[_ReD_]

OpenJDK 11 is bloody ancient. For a bleeding edge distribution this is an embarassment.

In fedora you can choose one of three java stacks for the desktop:
java-1.8.0-openjdk — java-11-openjdk — java-latest-openjdk, none of which is installed by default.
So you'll have to install it:

[me]$ dnf install java-latest-openjdk"

[me]$ java --version
openjdk 17 2021-09-14
OpenJDK Runtime Environment 21.9 (build 17+35)
OpenJDK 64-Bit Server VM 21.9 (build 17+35, mixed mode, sharing)

[caligula]

Supporting Java at times turns into a pure nightmare. Please note debian does not provide a Eclipse package any more. If you want to use Eclipse on debian its either the flatpak or the upstream cross distribution package(that only sometimes works).

The main reason this is a problem is that Eclipse is the only Java IDE and one of the only GUI apps that depends on a platform dependent native code GUI library that provides no additional value for any user (the other IDEs use cross-platform pure Java GUIs). SWT has also caused some issues with M1 Apple Macs for the same reason (aarch64 vs x86). The Eclipse project also had some other issues in their build pipeline as well so they could not provide links to M1 compatible distributions at all. Please don't blame other fully functional cross-platform software when this single project is using piece of shit technology.

[oiaohm]

Actually.. 17 is the latest LTS version.

That doesn't make any sense. OpenJDK 17 is LTS only since 14th of September, it is perfectly reasonable to have 11 as the default. If you want the latest version, you can install the package called conveniently enough openjdk-latest-openjdk. Also Fedora doesn't claim to be a bleeding edge distribution.

The reality 17 is the latest LTS but items like Eclipse and IntelliJ IDEA are not tested with that.

Android Studio, Eclipse and IntelliJ IDEA and more of your java IDE in fact ship on all platforms with their own versions of OpenJDK some with the own patches so not even LTS release. Yes that version of OpenJDK is what their upstream testing works with. This leaves downstream maintainers basically on their own.

Fedora has attempt to keep on maintaining the packages longer than everyone else. Yes centos and main redhat quit attempting this on this quite a few years back.

Java is fairly much mess of individual application JDK installs these days.

[royce]

I have never understood the way Linux distros handle java. Just package the openjdk and select apps or tools (e.g. maven, or minecraft, or whatever) and that's it. Why do you need to package individual libraries like guava and commons? That is utterly insane. In Java world every app bundles it's own dependencies. Nowadays there's even a trend of bundling a stripped-down minimalistic JRE together with the app. Packaging hundreds of java libs is a nonsensical waste of time. This is not a C/C++ world, where you must have just one version of stdlib (or whatever) installed in your system.

Crying about the maintenance burden while at the same time packaging loads of unnecessary crap is ridiculous.

I agree, and the same thing happens in Debian/Ubuntu with Node and PHP libraries for stuff that's just better installed via yarn/npm and composer respectively. It's hundreds of packages easily.

I can't think of a reason why I would for instance install symfony from Debian or Ubuntu's repos, and also do so globally instead of local to whichever app needs it.

Python is the same, although the case is different in that a lot of system tooling and apps are actually written in python. I can see the case there.

[Jabberwocky]

Java and other language packages in distros was useful back in the day before langauge specific package managers was popular before ~2006. It has not been that useful for a very long time though.

That was the plan in theory but in practice it doesn't quite work. For example a large amount of dependencies are not pure Java and provide some native JNI "glue" code to link it to the C libraries.

Java programs would need to bundle Windows (x86, amd64), macOS (amd64, aarch64), Linux (x86, amd64, aarch74, armv7), FreeBSD (x86, amd64, aarch74, armv7) glue libs and that would still only be a tiny fraction of platforms. It doesn't even consider versions, different libc, etc.

If you're not going to maintain your C code it will stop working on various platforms. Similarly if you don't maintain your JNI glue then it will also stop working. I used many projects that worked flawlessly with JNI. From an enduser's perspective they did not even know it was being used. You can package the native code inside your Java packages. You decide if you want everything in one single release or smaller platform specific releases. Almost like Apple's "Univarsal Binaries" or https://icculus.org/fatelf/

You then have weird things like generating the native glue code on the fly but then you need an entire C toolchain and development libs (I think the OpenGL bindings, JOGL gluegen does this).

Honestly, all this crap with bindings is not unique to Java either and is why C is still one of the most popular languages, warts and all.

I agree bindings can be a massive PITA, also true it's not limited to JNI. Python, Go, NodeJS, and others suffer from the same pitfalls. Many times have I just wanted to install a package and notice my CPU maxing out or getting some compilation error. I don't think bindings is a major contributing factor of why C is so popular though. Perhaps a better example would be languages or projects that have gone to great lengths to avoid bindings as much as possible. For example D or Kotlin, what do you think?

You have big list of pros and cons whether it's bindings for an interpreted or compiled language. There's a big overhead in maintenance and often a noticeable performance overhead too. If you don't maintain your bindings then you might as well not have them. On the other side bindings can make a project much more useful and increase productivity a lot!

Going deeper down the rabbit hole... Sometimes people argue but JOGL should be built into the standard runtime and that would improve the bindings problem. I don't agree with that type of arguement. It's a similar problem (depending on the language). Most of the time it's just a different place that the same glue is maintained. It simplifies packaging though that's for sure.

One public project that has pulled off code-gen/glue well is HAXE. That said, I really don't like it. It's just not my cup of tea. Another much more high level is OpenAPI Specification (AKA Swagger) IMO it's really good for web at least.

[bug77]

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.

[Vistaus]

Eh. Flash was replaced with modern JS

Mostly with HTML5, actually.

[Vistaus]

OpenJDK is actually very well maintained in Fedora and has a dedicated Red Hat team with upstream contributors. The problems are with packages outside of those core ones. Also, I don't think OpenJDK is installed by default in Fedora.

OpenJDK *is* installed by default on Fedora. Please don't spread misinformation.

[MadeUpName]

This is my "java --version" output on Fedora 34 workstation:

openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment 18.9 (build 11.0.12+7)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7, mixed mode, sharing)

If it gives this output, that means it's preinstalled on the distribution. I can also see it enabled in Libreoffice.

Libreoffice is the problem for Fedora. If they just dropped Java entirely they would need to replace Libreoffice.