we are aiming to remove libdb-java package from Fedora-rawhide, as we are
currently preparing for jdk update from jdk-1.8 to jdk-11 in Fedora
rawhide. The problem is that we are unable to rebuild this package with
jdk-11. It is still possible to "hack" it and rebuild it with jdk-1.8, but
that can cause unexpected runtime behaviour according to JVM-11, which will
soon be default in Fedora-rawhide.
There seems to be no packages, which depend directly to libdb-java and
upstream does not support version 5.3.28 anymore.
If anyone has any reasons why this should not be made, or someone is
currently active user of this JDBC connector, please leave a comment with
your opinion in the tracker  mentioned below.
There is also an existing tracker for deprecating libdb in Fedora , so
this can be understand as a first step.
Additional info about jdk-11 here .
Associate Software Engineer
javamail ursine is using version 1.5.2 while there are some module
streams at 1.6.x
The upstream project also moved to the eclipse foundation and these
1.6.x releases have different exports for OSGi, making an update to
them potentially breaking for users.
I'd like to update ursine to 1.6.x, but I understand packages
depending on them should be notified or some such. However I realized
I don't know what commands to run to get a list of such and then where
to send it. Could anyone advise?
Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail
so maybe a new package 'mail' can be introduced to use it? Any
Current stats from my testing samples:
That is huge improvement. Thank you all.
I'm now running last rebuild n copr, and in week or two an mass rebuild will be taken in koji.
There was an discussion what the border will be, when to force this change, or when to step away.
50% of passed? 80%? But afaik no metric is valid here, because - sorry to say it - there is no
longer any javastack...
Since f29, about 1000 java packages died or were orphaned. I was removing packages where upstream is
dead and are orphaned (so no chance to make them reliable working with jdk11), and I found that
wildfly, jenkins, jboss, half of maven plugins, elastic search, apach-emina, infinispan, cassandra,
hibernate.... All are dead. What is javastack for now (no blame or evil in that)?
So maybe the system jdk11 can be used as just last death-blow to java stack, rethink it, and stat
rebuilding on pretty fresh field....
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
I've been investigating build failures with java-11-openjdk as
default, and a lot of those failures are attributable to issues with
javadoc generation, in particular with maven-javadoc-plugin.
It looks like maven-javadoc-plugin cannot do dependency resolution
correctly when run on java 11, and hence generating docs fails with
"package foo does not exist" and / or "unresolved symbol bar" errors,
I tried setting `-Xdoclint:none` when generating javadocs, but this
had no effect on the error.
However, I found an easy solution, which was to switch from using
maven-javadoc-plugin to xmvn-javadoc for generating the docs (by
flipping the existing bcond switch in javapackages-tools). From
previous experiments with this option, it only caused minor problems
with 1-2 packages.
With xmvn-javadoc, the number of packages that fails to build on java
11 was reduced drastically - from ~every package that has dependencies
declared in pom.xml to only those that actually have build issues with
java 11 (so, from about ~1000 failing packages to ~250).
Of those remaining ~250 packages, ~125 can be fixed by overriding java
compiler source / target values to 1.8, since they use target java <
1.6 in their build systems, which is no longer supported by javac 11.
I collected those "EasyFix" packages in this ticket:
The other half of build failures are mostly build issues that are
unrelated to the java 11 switch, and only a handful of packages looks
like it actually required code changes (yes, I looked at the build
logs for *all* the failed builds).
I've also set up a COPR for all packages that require java, with
java-1.8.0-openjdk, java-11-openjdk, and javapackages-tools with the
proposed changes + the switch to xmvn-javadoc:
It's set up to automatically run builds in the event commits are
pushed to dist-git or Pull Requests are filed for any of the packages
the COPR contains. So, for any changes to a package, it will
automatically get built against java 11 in the COPR, as well.
TL;DR: I propose we switch to xmvn-javadoc, since it fixes most of the
build issues I see with OpenJDK 11 by default.
Alternatively: If somebody can figure out how to fix generation of
javadocs with maven-javadoc-plugin, that would be great, as that would
be a smaller change than switching the javadoc generator entirely.
What do you think?