From Fedora Project Wiki

< Changes

Revision as of 11:42, 8 December 2021 by Jvanek (talk | contribs) (mentioned yeld)


java-17-openjdk as system JDK in F36

Summary

Update the system JDK in Fedora from java-11-openjdk to java-17-openjdk.

Owner

  • Name: Jiri Vanek
  • Email: <jvanek@redhat.com>
  • Product: java and java stack
  • Responsible WG: java-sig (java and java-maint)(which no longer exists)
  • rcm ticket: 10364

Current status

Expected schedule

  • During November, create new package, java-17-openjdk literally cloned from java-latest-openjdk (which currently packages JDK 17, and will move to package JDK 18 in February)
  • December 2021 mass rebuild in copr
    • all maintainers will be informed of results
  • January 2022 second mass rebuild in copr
    • all maintainers will be informed of results
  • February 2022 mass rebuilds in rawhide - side tag
    • FTBFS bugs will be filed
  • 22.2, the sidetag will be merged
  • Change Checkpoint: 100% Code Complete Deadline Tue 2022-02-22 - https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
    • hard deadline for feature completed

Detailed Description

Fedora currently ships:

  • java-1.8.0-openjdk (LTS)
  • java-11-openjdk (LTS)
  • java-latest-openjdk (on jdk16,jdk18, STS, jdk17, although LTS, only untill jdk18 is released).

where the version-less java and javac (and friends) are provided by java-11-openjdk.

  • java-17-openjdk will be cloned from java-latest-openjdk to harbor next LTS JDK

So every package honoring the packaging rules and requiring java , java-headless or java-devel is built in koji by java-11-openjdk-devel and pulls java-11-openjdk(-headless) in runtime (See java ). Also javapackaging-tools are using java-11-openjdk as hardcoded runtime (see changes)

We were intentionally delaying jdk11 on-boarding for stability reasons. But there is no such reason with 17 (for recall, see https://fedoraproject.org/wiki/Changes/Java11)

Major incompatibility is again (as we were bumping 8->11) encapsulation. What was hidden is now even more hidden and few more parts were hidden. Luckily, most of the projects, when shifted to 11, did it properly. Still few projects may hit usage of some newly restricted APIs.

"Political disclaimer"

In old bumps, 6->7, 7-8 we, Red Hat's openjdk team, were a driving force to bump the system JDK. In case, of jdk11 were a bit reluctant for stability reasons, so we updated as late as possible. In case of jdk17, there are no known stability issues, and we hear fedora people to to ask for jdk17 as system jdk as soon as possible. So targeting f36, nearly year after jdk17 release. If it is not a wish of Fedora community, we can postpond to F37 or even later

Benefit to Fedora

JDK17 is out just shortly, but its compatibility with 11 is quite good and its stability is promissing. Although we can expect some family of packages to remain on jdk8 for ever, and some other (much smaller) family of packages will remain on jdk11 for a while, the javastack should be ok to go. Both jdk8 and jdk11 will remain part of Fedora while they are supported usptream, and there is a target audience in our OS.

Scope

keep java-11-openjdk (+JDK8 of course) but remove its java/javac versionless provides, make java-17-openjdk providing java, javac and other versionless provides (+ keep java-latest-opendjk as rolling bleeding edge of STS JDKs)

  • will guarantee fedora to be pure JDK17 distro.
  • will allow maintainers of JDK17 or up incompatible packages to keep using JDK11 (and JDK8), however this is just false hope.
    • if such an package depends on package build by JDK17, JDK11 and JDK8 may not be able to pick up that dependency.
    • this may lead to quite a lot of bundling or compat packages, but may be acceptable
    • people developing JDK8 and JDK11 applications will very likely stay with fedora:)
    • those was not so bad when JDK11 was moved to system JDK.

While quite a lot of users will rejoice, there may be cases where application is very hard to migrate to JDK11, so the contingency plan should be taken very serious.

Bytecode version

Workflow

Change owners

  • Feature will be implemented in side tag
    • --target f36-java17 is tag of choice
    • In its mass rebuild, aprox XYZ packages were built, and ABC failed. FTBFS bugs filled, most of them needs manual fix later
  • the jdk 11 and 17 will be changed for this side tag
  • the mass rebuild of javastack will be then launched
    • if necessary, several rounds of them
  • Failures will be gathered by me and few other volunteers
    • Most common issues and theirs fixes will be published
    • Package maintainers will be notified in case of failure via bugzilla
  • Depending on the fail rate, importance of failed packages and effort to fix them
    • the side tag will be merged to Fedora
    • or the contingency plan will be activated

Other developers

  • should fix their packages
    • this usually means to update to newer version, which supports jdk17
  • or to retire them if they appear non-fixable
  • or to base them on JDK11 without much warranty (as they will need to compat most of dependency chain)


Other

  • Proposal owners:
    • based on above, adapt jdk11 and jdk17 package provides
    • If necessary tune the build environment
  • Other developers:
    • based on selected approach to tune the main build tools
      • jpackage-tools and maven will affected
    • based on selected approach to tune the rpmbuild/macros
    • many java package maintainers will maybe need to adapt theirs packages
      • FTBFS bugs connected with this proposal, maybe with pagure ticket to allow discussion.
      • Solutions to most common errors should be gathered and published
  • Policies and guidelines: how to deal with build failures, eventually how to use some jdk17 specific build features will be provided
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Once the change is implemented properly, the update should be flawless and seamless

How To Test

  • only JRE17 should remain the only system JDK after installing base javastack on clean system
  • Both jdk8 and jdk11 and jdk17 and java-latest-openjd can live together on system
  • jdk17 will be selected by default and will run most of the base java stack
  • todo, add few java-package to install examples, hopefully for jdk17 only


User Experience

  • Standard user should be still be able to use java stack without even noticing the change.
  • Standard developer should still be able develop any java application comfortably
  • Standard packager will not suffer to much, and should be able to pack any java application for fedora

Dependencies

Around 2000 packages will need attendance (that is aprox 1/3 of time of jdk11 bump, but It seems, that 1100 packages remained on jdk8). Runtime depndecies: 

$ repoquery -q --whatrequires java-headless |wc -l
1007
$ repoquery -q --whatrequires java | wc -l
53
$ repoquery -q --whatrequires java-devel | wc -l
28
$ repoquery -q --whatrequires java-1.8.0-openjdk-headless |wc -l
1003
$ repoquery -q --whatrequires java-1.8.0-openjdk  | wc -l
80
$ repoquery -q --whatrequires java-1.8.0-openjdk-devel  | wc -l
42
$ repoquery -q --whatrequires java-11-openjdk-headless |wc -l
1030
$ repoquery -q --whatrequires java-11-openjdk  | wc -l
78
$ repoquery -q --whatrequires java-11-openjdk-devel  | wc -l
36

with src repos on, build time depndnecies: 

set +x ;echo "dont forget to enable all (correct fedora, fedotra-testing, fedora modules) SOURCE repos (sections in .repo files)!" ; for x in ant maven-local maven mvn xmvn java-headless java java-devel java-1.8.0-openjdk-headless java-1.8.0-openjdk java-1.8.0-openjdk-devel java-11-openjdk-headless   java-11-openjdk   java-11-openjdk-devel ; do for y in ""  "--arch src"  ;do set -x ; repoquery $y -q --whatrequires $x  |wc -l ; set +x ; done; done 
dont forget to enable all (correct fedora, fedotra-testing, fedora modules) SOURCE repos (sections in .repo files)
+ repoquery --arch src -q --whatrequires ant
152
+ repoquery --arch src -q --whatrequires maven-local
401
+ repoquery --arch src -q --whatrequires maven
4
+ repoquery --arch src -q --whatrequires mvn
0
+ repoquery --arch src -q --whatrequires xmvn
0
+ repoquery --arch src -q --whatrequires java-headless
5
+ repoquery --arch src -q --whatrequires java
0
+ repoquery --arch src -q --whatrequires java-devel
207
+ repoquery --arch src -q --whatrequires java-1.8.0-openjdk-headless
6
+ repoquery --arch src -q --whatrequires java-1.8.0-openjdk
0
+ repoquery --arch src -q --whatrequires java-1.8.0-openjdk-devel
19
+ repoquery --arch src -q --whatrequires java-11-openjdk-headless
0
+ repoquery --arch src -q --whatrequires java-11-openjdk
0
+ repoquery --arch src -q --whatrequires java-11-openjdk-devel
15


Packages needing major work will be

  • java-11-openjdk
  • java-17-openjdk
  • javapackages-tools
  • maybe maven base


Contingency Plan

  • If the mass rebuild, after the change application, breaks to much packages, or some important will be unfixable, jdk11 must be restored back to the position of system jdk.
  • Contingency mechanism: Return jdk8 as system jdk and mass rebuild again. Note, that this may be very hard, because during build of packages by jdk8, by jdk11 built dependencies will be picekd up, so build will fail. Maybe several iterations of mass rebuild will be needed.
  • Contingency deadline: Announce release blocking deliverables Tue 2022-02-01 Tue 2022-02-01 0 (8days before branching, 22 before beta freeze)
  • Blocks release? Yes
  • Blocks product? N/A
  • Generally going back will be imho impossible. Once the decision is taken, javastack should be fixed, and where it can not be fixed, it had to migrate to compat packages, or bundled-dependencies pacages or be orphaned.

side tag

https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag

  • for this fedora have technology known as side tag
  • I do not have experience with it, but is making the contingency plan much smoother
  • it is a way, which will be done first

copr preliminary rebuild

We run an preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. The first result will be: todo

  • If there is "failed" but contains "- -" then it is probably orphan. If you wish to resurrect it, please ensure it runs against JDK17 (see lower)
  • If there is "failed" but failed in "seconds", then those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target lower then 1.8 JDK17 supports 1.7 and up. We recommend to bump the source/target to 1.8, to allow existence of compat 1.8 packages alongside main javastack
  • If there is "failed", and its none of above, then your package simply failed. Very often the scary error may be fixed by bump to latest upstream version. JDK 17 is shortly. Please, try to fix the package. Don't hesitate to ask,. If you fix the fail, feel free to share your fix, it may help others.

Debugging failures wiht help of this copr

The copr repo we maintain, contains builds of java-17-openjdk as system JDK, javapackages-tools honoring that, and java-11-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this copr repo in several ways. 

# as root, globally
sudo wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scritps/spammer/exemplarResults/jvanek-java17-fedora-rawhide-x86_64.cfg -O /etc/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# or as user, locally (after creating  ~/.config/mock/)
wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scritps/spammer/exemplarResults/jvanek-java17-fedora-rawhide-x86_64.cfg  -O ~/.config/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# change spec, bump sources, apply patches
fedpkg srpm
mock -r jvanek-java17-fedora-rawhide-x86_64  *.src.rpm

Or any other packaging workflow you use, and you can use against the copr repo.

Documentation

common issues packagers can face and gathered solutions

Contacts: ask on devel@lists.fedoraproject.org or java-devel@lists.fedoraproject.org or directly to me jvanek@redhat.com Threads of "F36 system wide change, java-17-openjdk as system jdk"

Major database can be browsing of closed bugs of blockers of https://bugzilla.redhat.com/show_bug.cgi?id=TODO ; unluckily, when it was analysed, it was not summarised up (that would actually double the work)

My package can not work with jdk17

Generally it is not true. Generally, no program can say, that it do not support jdk17, because any javac/java application can be *hacked* to work with java17 - see https://jvanek.fedorapeople.org/devconf/2017/portingjavaInternalToJdk9/portingOfItwToJdk9-II.pdf (really all except package split over modules, which is impossible)

Now above mentioned approaches are indeed *hacked*, and I discourage everybody to do so. The upstream should be moved to jdk17, and not much excuses are around to support to not to do so. If you package is really bound to jdk11, you can move to the version-full requires: 

 BuildRequires: java-11-openjdk(-devel)

and 

 Requires: java-11-openjdk(-headless).

In addition, if you work with maven/ant or simialr, you must set export JAVA_HOME=/usr/lib/jvm/java-11-openjdk before calling it. japckage tools and comp are made to accept it.

However there is an trap - packages you depends on. Once some of your dependencies will be compiled with --target > 8, you are doomed, and you have to bundle it or create its compat version. By doing so you can easily end in dependency hell.

Please, try to avoid this as much as possible!

Intermediate step build with java-11-openjdk-devel and run with java (that means any sytem java, eg java-17-openjdk)

Some projects support JDK17 for runtime, but not for compile time. 

Buildrequires: java-11-openjdk-devel
...
Requires: java(-headless)
...
%build
...
 export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
...

Should work for a while. See the "My package can not work with jdk11" section

My package is not in your copr!

If your package is not listed in the copr rebuild repo, I can see two causes

  • You have very indirect BR on java.
    • Solution
    • Email me (jvanek@redhat.com) or ping me (jvanek), I will gladly add you package(s)
  • You have exact requires on java-11-openjdk(-devel)
    • Solution
    • Unless you have good reason, you are actually breaking packaging guidelines. Switch to java-devel. Once done, again let me know and I will gladly add your package
    • If you can't, then you most likely can not bump to jdk17, and you will live with jdk11 until it dies,

Wrong source/target version

maven 

[ERROR] Source option 1.3 is no longer supported. Use 7 or later.
[ERROR] Target option 1.3 is no longer supported. Use 1.7 or later.

ant 

-do-compile:
    [mkdir] Created dir: /builddir/build/BUILD/jpanoramamaker-5/build/empty
    [javac] Compiling 45 source files to /builddir/build/BUILD/jpanoramamaker-5/build/classes
    [javac] warning: [options] bootstrap class path not set in conjunction with -source 5
    [javac] error: Source option 5 is no longer supported. Use 7 or later.
    [javac] error: Target option 1.5 is no longer supported. Use 1.7 or later.
BUILD FAILED

usage of sun.misc.Unsafe.defineClass

direct usage

library usage

 java.lang.NoSuchMethodException: sun.misc.Unsafe.defineClass(java.lang.String [B,int,int,java.lang.ClassLoader,java.security.ProtectionDomain)

at java.base/java.lang.Class.getMethod(Class.java:2227) at com.sun.xml.bind.v2.runtime.reflect.opt.Injector$3.run(Injector.java:201) at com.sun.xml.bind.v2.runtime.reflect.opt.Injector$3.run(Injector.java:197)

In this case, jaxb was old. Get new version of library

package XYZ does not exists ... in javadoc generation!

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:aggregate (default-cli) on project  classloader-leak-test-framework: An error has occurred in Javadoc report generation: 
[ERROR] Exit code: 1 - /builddir/build/BUILD/classloader-leak-prevention-classloader-leak-test-framework-1.1.1/src/main/java/se/jiderhamn/classloader/leak/JUnitClassloaderRunner.java:9: error: package org.junit does not exist
[ERROR] import org.junit.Assert;

javah: No such file or directory

The javah command was retired and is no longer available in jdk11; you should switch the package to use javac -h instead. The new javac -h syntax works just fine with jdk8, so you can switch to this now without worrying about backwards compatibility.

For example: https://src.fedoraproject.org/rpms/snappy-java/blob/2981aaa5b8a597129ad2f12cdf1f4617303a8425/f/javah-adaptation.patch

replacing new Integer(string)/Double(string)/... by Integer/Double../.valueOf(string)

The string based constructor is no longer public (spot bugs wuld tell you years ago)

= Yeld keyword

exemplar commits

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Java17&oldid=632703"