Originally posted by kpedersen
View Post
Announcement
Collapse
No announcement yet.
Fedora's Java Packages Have Fallen Into Rough Shape
Collapse
X
-
Originally posted by RahulSundaram View Post
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 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.
- Likes 3
Comment
-
Originally posted by user1 View Post
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.
- Likes 9
Comment
-
Originally posted by Sonadow View Post
OpenJDK 11 is bloody ancient. For a bleeding edge distribution this is an embarassment.Last edited by user1; 28 September 2021, 08:27 AM.
- Likes 11
Comment
-
Originally posted by user1 View Post
Well, it is currently the latest LTS version. Other distributions also ship version 11, including bleeding edge ones like Opensuse Tumbleweed. Even on Ubuntu, where OpenJDK is not preinstalled, version 11 is considered the only one officially supported by Canonical.
- Likes 1
Comment
-
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.
And honestly, Java developers typically download the JDK versions that they need for their projects themselves from sites such as https://adoptopenjdk.net.
Also, IntelliJ IDEA, the most popular Java IDE as far as I know, includes a JDK of its own.
So there's no real need to have any of the Java stuff managed in the Fedora repo, especially since the stuff in the repo tends to get outdated quickly. Also, the opposite is sometimes true: for certain legacy projects, an older JDK such as JDK7 might be needed, which might not be in the repo of newer Fedora versions anymore.
My advice to the Fedora maintainers: leave all the Java stuff out and save yourselves the maintenance burden. Java developers know how to download and install the parts of their development toolchains themselves.
And the exact same goes for Ubuntu and every other Linux distro, to be honest.
- Likes 6
Comment
-
Originally posted by kpedersen View Post
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.
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.
Plus, the problem they are discussing goes much further than the native bindings. Distros package things like guava, apache commons.... libraries like these do not depend on any native code whatsoever. No JNI, no JNA, no libffa, nothing. Again this whole thing is ridiculous.
As an anecdotal evidence - I've built apps previously that relied on various libraries, and native bindings, like for example OpenCV, and I've always included everything including the native-built artifacts in the final distributed binaries. That's just how Java works. Yes, Java invented flatpak before it was cool.
- Likes 4
Comment
-
Originally posted by Sonadow View Post
OpenJDK 11 is bloody ancient. For a bleeding edge distribution this is an embarassment.
- Likes 11
Comment
-
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).
A Java 11 or newer JRE/JDK is required, LTS release are preferred to run all Eclipse 2021-09 packages based on Eclipse 4.21, with certain packages choosing to provide one by default. The Installer now also includes a JRE--consider using the Installer. Please see 5 Steps to Install Eclipse
The Eclipse Foundation - home to a global community, the Eclipse IDE, Jakarta EE and over 415 open source projects, including runtimes, tools and frameworks.
The Eclipse Installer 2021‑09 R now includes a JRE for macOS, Windows and Linux.
That right eclipse project maintains its own version of java runtime. that all it code it tested with. Eclipse is not tested up stream that it works with general openjdks any more. Yes the automated testing of Eclipse has reduced to 3 platforms one version of java.
ep421I-unit-mac64-java11 macosx.cocoa.x86_64
ep421I-unit-win32-java11 win32.win32.x86_64
ep421I-unit-cen64-gtk3-java11 linux.gtk.x86_64
Yes where these are all the same Java11 they are the bundled JRE not the system provide one. Yes the bundle JRE can have some of Eclipse projects own patches.
Yes you look at the automated testing you see a few extras like the following
ep421I-unit-cen64-gtk3-java16 linux.gtk.x86_64
ep422I-unit-macM1-java17 macosx.cocoa.aarch64
ep422I-unit-cen64-gtk3-java17 linux.gtk.x86_64
But failures with these don't prevent eclipse package release. Of course those failures are going to drive you nuts as you attempt to use eclipse.
There are a lot of packages fedora includes that debain has dropped for this reason that the upstream now only support 1 particular version of Java and the application has a flatpak or other installer that makes sure application installed with its matching JRE.
You know something is wrong when in a particular area fedora has more packages than Debian and arch combind this is the true case with Java libraries and applications include in Fedora. Both debian and arch have pruned a lot of the trouble java packages to maintain. Yes Eclipse is one of those troubled packages another trouble package is android studio both have been pruned from the debian and arch distributions so they are no longer distribution maintainer problem.
There quite a lot of java applications/libraries that due to upstream that only testing against a limited JRE come a pure time consuming nightmare causing burn out for maintainers if they are asked to maintain them. Debian and Arch and even Ubuntu on a lot of these applications to users are like flatpak/snap/own installer it we are not providing those any more and will not be dealing with the failures because we don't provide it.
So fedora is a little behind the times here.
The idea of one binary that runs everywhere using independently provided runtime the hard reality this has mostly not worked out be it .net or java or many other options.
- Likes 1
Comment
Comment