Fedora's Java Packages Have Fallen Into Rough Shape
Fabio Valentini who is apparently the only one left in the Java Maintainership SIG (Special Interest Group), started a mailing list thread on Sunday about the poor state of affairs.
Fabio summed up the rather dire situation, "Community maintenance of Java packages in Fedora is, for all intents and purposes, dead. Mikolaj keeps a bare minimum of packages working for the maven toolchain, but that's it. Fedora 35 will ship without packages for the Eclipse IDE, and none of the Java applications I know of are still in working order. While I had hoped that setting up a "new" SIG and gathering members to shore up community maintenance of the "extended core" Java stack, this effort fizzled out after mere weeks. "He's dead, Jim.""
The developer went on to question whether the Java Maintainership SIG for Fedora should just shutdown given the lack of activity from addressing security issues to an increasing number of Java packages no longer building/installing.
The discussion so far are mixed with some arguing that distribution packages of Java software is less important these days but most agreeing there is fundamentally a problem and improvements could be made albeit no one stepping up to the plate to commit to bettering the Java support in Fedora.
Update (8 October): Mario Torre as the OpenJDK Team maintainer at Red Hat had the following response regarding the Fedora "Java" state:
The situation of some of the Java packages in Fedora is indeed in a rather bad shape, however one important aspect that seems to be confusing is that Java != Java (didn't I just say I want to offer some clarification? .
-As you know, upstream Java, intended as the core framework, a collection of class libraries, compiler, the Java Virtual Machine and some additional tooling, has been driven as an open source project by the OpenJDK project for more than 15 years.
-Red Hat participates in the upstream development by not only helping the community with the latest upstream versions, but also by actively maintaining popular versions like OpenJDK 8 and OpenJDK 11 - this is done, let me emphasize, completely upstream and it is a community effort, Red Hat participates in this with other companies and individual developers, including SAP, Amazon and of course Oracle, as well as others.
-OpenJDK does not, strictly speaking, release builds, however Oracle shares upstream open source (under the GPL+Classpath Exception) builds of the latest OpenJDK release for about six months while Red Hat helps with upstream builds for the versions we lead upstream, 8 and 11:
-Red Hat, as a major participant in OpenJDK development, also participates in the vulnerability group:
-This means that all those builds are thoroughly tested and certified and follow the highest standards of quality assurance.
-I wanted to mention this because it shows the dedication of my team to be an upstream first citizen and the fact that OpenJDK is very well maintained, including versions of OpenJDK which are older like 8 and 11, but considered long term versions.
-Downstream, this translates to builds of OpenJDK for RHEL and CentOS streams, as well as Fedora, which is one of our most important targets: every build that goes into Fedora is patched and tested the same way as the builds we do for RHEL, they are done by the same team and tested and maintained by the same engineers.
-I mentioned before that Java is not Java. Another popular package that is so critical for most Java developers is Maven. Maven in Fedora (and RHEL) is not maintained by the OpenJDK team in Red Hat, it is instead maintained by Mikolaj Izdebski, who works on core RHEL.
-Although Maven itself is a larger ecosystem of its own, with lots of moving parts and additional plugins, some of which may not be packaged, the core maven that is so essential to virtually every Java developer is well maintained and tested and updated regularly.
-So what is "not Java"? Most of the complaints from the Fedora Java community are due to libraries and additional applications that are not readily packaged in Fedora, for example that may be some version of some Apache libraries, and likewise some client applications like Eclipse and JDK Mission Control.
-Those libraries are all available via Maven Central, however, and most of the time developers using Maven on Fedora are using the Maven Central versions anyway: they need to explicitly direct Maven to use the "local" version if available - Maven will still "download the Internet" otherwise, as it's the common Maven joke (not very far from the truth!).
-The most significant loss due to the packaging state of all those libraries is that of Eclipse from the core distribution, which implied also to lose some Eclipse based applications, like JDK Mission Control that now have to be installed using either the upstream builds or via an external copr repository that just wraps the upstream binaries.
-The latter part is less than ideal, however in our experience even the Eclipse maintainers relied on the upstream Eclipse.org nightly builds for their day to day work, and considering the fast release cadence that everyone seems to adopt those days, the work for maintainers isn't matched with real benefits.
-In other words, saying that the state of Java is in bad shape is literally just about packaging of selected libraries that not many people use, and this is the main reason why there is no activity around the packaging effort, but "Java support in Fedora" is extremely strong and solid, resources are dedicated to maintain the base of the stack which is what everyone relies upon.
-Some of the comments mention that OpenJDK itself is a problem, and that one should use a different distributor, but those are misleading because they don't seem to clearly understand the distinction I tried to clarify here, it would be like saying that the state of C++ in Fedora is bad because for example suddenly it's decided that, say, KDE, is not anymore a supported desktop.
-While I think that the general way of looking at this should be that if you don't trust the packages of your distribution, then you should not trust the distribution in the first place, and that everyone must be free and it's totally within their right to decide to use a different vendor, the reality is that OpenJDK in Fedora is in great shape and should be trusted.