Updated list with repos for koji rawhide buildroot on Jul 21, 17:08 UTC

Some commentary/rationale/justifications for requiring java-1.8.0-openjdk where I know it:

• apache-commons-lang -- Justified usage due to use of assert and enum keywords used as identifiers; this package can't be moved on and dependents should instead be ported to apache-commons-lang3
• eclipse -- Intentionally uses both JDKs via maven toolchains to avoid linkage errors/cross-compilation issues
• eclipse-webtools -- Fixed upstream in https://git.eclipse.org/c/webtools-common/webtools.common.git/commit/?id=b61f1b8950dfd22ab6a1f40d1494c5a26d4eddb6
• freemarker -- Requires proper specification of bootclasspath to avoid linkage errors/cross-compilation issues; this packages ant scripts should be ported to use the "release" flag instead
• java-1.8.0-openjdk -- Errr.... Um.
• openjfx8 -- Justified usage due to the tight coupling between JavaFX and the JRE; openjfx11 should be package separately for Java 11 support

apache-commons-lang -- Justified usage due to use of assert and enum keywords used as identifiers; this package can't be moved on and dependents should instead be ported to apache-commons-lang3

Fixing variable name is usually simple patch. Is there some reason to not do so?

java-1.8.0-openjdk -- Errr.... Um.

I consider it is ok to botstrap jdk8 with jdk8, oook?

openjfx8 -- Justified usage due to the tight coupling between JavaFX and the JRE; openjfx11 should be package separately for Java 11 support

openjfx11 is already packed as openjfx,

We should make sure nothing in their dependency tree bumps -target to anything newer than 1.8.

I'm not sure this is going right way. I definitely admire all your hard work, and am just astonished you jumped into it like you did, this is something individual packagers should handle.
In addition, current tooling will require us to do it again , in less then two years. And I mean completely again, and really with each step as we - you - did this time.

Keeping jdk8 alive was intentional, however to keep its bytecode jd8 comaptible wasnot part of the proposal. However it seems to be necessary to allow certain applications to live withjdk8, enforcing bytecode (now touching my %{target}) is a bit backward thinking from scope of existence JDK14 in java-latest-openjdk.

Pleae dont take me bad, you are doing awesome. I'm just really afraid the work will need to be repeated. On contrary, withut your help javastack would probably be a bit doomed

We should make sure nothing in their dependency tree bumps -target to anything newer than 1.8.
javamail-0:1.5.2-13.fc33.src

Looks intentional (hard-coded to use JDK 8):
https://src.fedoraproject.org/rpms/javamail/c/63f97136fecf964e791a9ad65604e28899b29526?branch=master

For the record starting with the release in September Eclipse will enforce Java 11 usage - new APIs usage, target and etc. So trying to keep it 1.8 now is pointless.

Don't get me wrong, keeping bytecode compatible with OpenJDK 8 is only intended to be a limited short-term measure to keep the packages listed in this ticket working until they become compatible with Java 11 (or get removed).

Regarding macro / tooling support for setting javac -target, I'm all for it, but it's too late for fedora 33. For now I'd focus on keeping the next release from exploding before chasing the next shiny new thing ... once that's done, sure, let's introduce macro support for min_supported_javac_source / min_supported_javac_target or something like that.

apache-commons-lang -- Justified usage due to use of assert and enum keywords used as identifiers; this package can't be moved on and dependents should instead be ported to apache-commons-lang3

Fixing variable name is usually simple patch. Is there some reason to not do so?

In this case, maybe not. enum is used as a package name. We'd have to remove / rename the whole package, and at that point, we might as well port packages that use commons-lang to commons-lang3 (because that's the primary API change between the two).

See: https://pagure.io/java-maint-sig/issue/4

@enum I see. Right you are then, thank you.

As for the macro, I'm not super sure if is useful at all. Otherwise it would be already there. It would help right now (and you are right it is to late), and it can (but only maybe) help in java17 time. But generally? I'm really not so sure with it.
As akurtakov is syaing. Apis are changing too, and backward comaptibility is quite a burden.

This ticket is perhaps poorly worded? I see this as a list of work items to free us from JDK 8. Not a list of items to preserve on JDK 8.

Edit:

java-1.8.0-openjdk -- Errr.... Um.

I consider it is ok to botstrap jdk8 with jdk8, oook?

It was a joke, obviously java-1.8.0-openjdk shouldn't be on this list as something we need to make work on JDK 11 ;-)

@mbooth Sure. My intent was to keep track of packages that are stuck with java-1.8.0-openjdk, for whatever reason. Then, determine if the reason is either valid or a packaging bug ... and document this so we can either drop the stuck packages, or keep them working by making sure their dependencies don't bump bytecode versions too high.

I added hamcrest2 to the list. It does not build with Java 9+ and upstream is still only planning support for it at some point :pensive:

Add jctools to the list, it fails to build with JDK11 ( https://github.com/JCTools/JCTools/issues/254 ) and is stuck with JDK8 for now.

@mbooth do you know if netty is pinned to 1.8.0 for a good reason? Because it's a botched job anyway, and fixing it with Java 11 was very easy:

https://src.fedoraproject.org/rpms/netty/pull-request/6

@mbooth do you know if netty is pinned to 1.8.0 for a good reason? Because it's a botched job anyway, and fixing it with Java 11 was very easy:
https://src.fedoraproject.org/rpms/netty/pull-request/6

I was co-incidentally looking at netty for an unrelated reason and incorporated this change into mine: https://src.fedoraproject.org/rpms/netty/c/75c8841591fcdede6a8bdaa05fddf68883b0f290?branch=master

I've added jdeparser to the list (uses com.sun.reflect.Reflection API which is gone in Java 11), and removed xbean, which was fixed up for Java 11 by @mbooth :tada:

In this case, maybe not. enum is used as a package name. We'd have to remove / rename the whole package, and at that point, we might as well port packages that use commons-lang to commons-lang3 (because that's the primary API change between the two).

Commons Lang 2.6 has an org.apache.commons.lang.enums package in addition to the (deprecated) org.apache.commons.lang.enum:

https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/enum/package-summary.html

...so if the Fedora apache-commons-lang package couldn't include org.apache.commons.lang.enum for whatever reason, it might be fairly easy to update dependent packages to use org.apache.commons.lang.enums instead.

@richardfearn There is effort to migrate to commons-lang3, at which point commons-lang can be retired: https://pagure.io/java-maint-sig/issue/4

@mbooth I know... I left the same comment there the other day. Helping upstream projects migrate to Commons Lang 3 obviously benefits everyone - just wanted to flag that dependent packages could still use Commons Lang, say if it could only be built by excluding the enum package (enums could in theory be used instead).

I've removed the code that's incompatible with Java 4+ from apache-commons-lang, since after manually checking all packages still using commons-lang 2.x, it turned out that the code was unused anyway. The package now builds fine with Java 11, targeting Java 8 for now for compat with other packages stuck on Java 8.

Updates:

• bolzplatz2006 and eclipse-webtools were updated for Java 11
• lasso now targets Java 8