No edit summary |
|||
(12 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
<!-- | = java-21-openjdk as the system JDK in F40 <!-- The name of your change proposal --> = | ||
== Summary == | == Summary == | ||
Line 45: | Line 26: | ||
== Current status == | == Current status == | ||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
[[Category:ChangeAcceptedF40]] | |||
* Targeted release: [[Releases/40 | Fedora 40 ]] | * Targeted release: [[Releases/40 | Fedora 40 ]] | ||
Line 55: | Line 37: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* | * [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/P2RZLFY4MTDDQGFPEJ7TLKAXZLSYEUDP/ Discussion thread] | ||
* FESCo issue: https://pagure.io/fesco/issue/ | * [https://discussion.fedoraproject.org/t/f40-change-proposal-java-21-system-wide/101312 Announced] | ||
* Tracker bug: [ | * FESCo issue: [https://pagure.io/fesco/issue/3147 #3147] | ||
* Release notes tracker: [ | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2262141 #2262141] | ||
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/1075 #1075] | |||
=== Expected schedule === | === Expected schedule === | ||
Line 362: | Line 345: | ||
==== Wrong source/target version ==== | ==== Wrong source/target version ==== | ||
maven | maven | ||
[ERROR] Source option 1. | [ERROR] Source option 1.7 is no longer supported. Use 8 or later. | ||
[ERROR] Target option | [ERROR] Target option 7 is no longer supported. Use 1.8 or later. | ||
ant | ant | ||
-do-compile: | -do-compile: | ||
[mkdir] Created dir: /builddir/build/BUILD/jpanoramamaker-5/build/empty | [mkdir] Created dir: /builddir/build/BUILD/jpanoramamaker-5/build/empty | ||
[javac] Compiling 45 source files to /builddir/build/BUILD/jpanoramamaker-5/build/classes | [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 | [javac] warning: [options] bootstrap class path not set in conjunction with -source 7 | ||
[javac] error: Source option | [javac] error: Source option 7 is no longer supported. Use 8 or later. | ||
[javac] error: Target option 1. | [javac] error: Target option 1.7 is no longer supported. Use 1.8 or later. | ||
BUILD FAILED | BUILD FAILED | ||
* Solution | * Solution | ||
** Your javac is run with wrong source/tag parameters. [https://duckduckgo.com/?t=ffsb&q=javac+source+target&ia=web net search will give you quick answer] | ** Your javac is run with wrong source/tag parameters. [https://duckduckgo.com/?t=ffsb&q=javac+source+target&ia=web net search will give you quick answer] | ||
** Fixes are: | ** Fixes are eg: | ||
*** | *** https://src.fedoraproject.org/rpms/maven-shared-io/pull-request/3#_1__27 | ||
==== invalid entry in sources ==== | |||
`stdout: Invalid entry in sources file: ae177021dfa32281b3b052a6574e94b9 CardManager_sources3.zip` | |||
Your package was not updated for ages, and thus have still sources in `MD5` sum format. | |||
Obtain/update/generate your sources, and `fedpkg new-sources` them. | |||
If your sources can no longer be obtained., you can check lookaside cache, eg: for this case https://src.fedoraproject.org/repo/pkgs/CardManager/ - https://src.fedoraproject.org/rpms/CardManager/c/35ebf20a6370345947e0722186074487da6d620c?branch=rawhide | |||
==== encapsulated module ==== | |||
` | |||
[ERROR] Errors: | |||
[ERROR] com.fasterxml.jackson.dataformat.csv.deser.BasicParserTest#testMapsWithLinefeeds ClassCastException class com.fasterxml.jackson.core.io.IOContext cannot be cast to class com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext (com.fasterxml.jackson.core.io.IOContext and com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext are in unnamed module of loader 'app') | |||
[ERROR] com.fasterxml.jackson.dataformat.csv.deser.BasicParserTest#testSimpleExplicit ClassCastException class com.fasterxml.jackson.core.io.IOContext cannot be cast to class com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext (com.fasterxml.jackson.core.io.IOContext and com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext are in unnamed module of loader 'app') | |||
... | |||
` | |||
You have to open and export the modules | |||
==== no longer allowed security manager ==== | |||
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/SecurityManager.html#set-security-manager | |||
In jdk 21, is hard deprecation of SecurityManager. if you are using it, it will throw exception. You can allow it again: `-Djava.security.manager=allow` | |||
== Release Notes == | == Release Notes == |
Latest revision as of 13:31, 5 March 2024
java-21-openjdk as the system JDK in F40
Summary
Update the system JDK in Fedora from java-17-openjdk to java-21-openjdk.
Owner
- Name: Petra Alice Mikova
- Email: <pmikova@redhat.com>
- Product: java and java stack
- Responsible WG: java-sig (java and java-maint)(which no longer exists)
- rcm ticket: https://pagure.io/releng/issue/11859
- named side tag ticket: TBD
Current status
- Targeted release: Fedora 40
- Last updated: 2024-03-05
- Discussion thread
- Announced
- FESCo issue: #3147
- Tracker bug: #2262141
- Release notes tracker: #1075
Expected schedule
- During January 2024, we will create a new package, java-21-openjdk, which will be a clone of java-latest-openjdk, which contains STS versions of OpenJDK (currently 21) and will move to JDK 22 in February/March.
- December 2023 I will do mass rebuild in copr
- all maintainers will be informed about the results
- January 2023 I will do second mass rebuild in copr
- all maintainers will be informed about the results
- February 2023 mass rebuild in rawhide - side tag
- FTBFS bugs will be filed
- February 2023 the sidetag will be merged
- Change Checkpoint: 100% Code Complete Deadline TBD
- hard deadline for feature completed
Detailed Description
Fedora currently ships:
- java-1.8.0-openjdk (LTS)
- java-11-openjdk (LTS)
- java-17-openjdk (LTS), system JDK
- java-latest-openjdk (currently JDK21)
- java-21-openjdk will be cloned from java-latest-openjdk
Therefore, every package honoring the packaging rules and requiring java via java-headless or java-devel is built in koji using java-17-openjdk-devel and pulling java-17-openjdk during 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 reason for this approach with 21 (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.
Feedback
Benefit to Fedora
JDK21 was released a while ago, but compatibility with JDK 17 is good enough and it is a stable release. Although we can expect some group of packages to use jdk8 forever, and some other (much smaller) group of packages stay on jdk11 for a while, the java stack should be able to use the JDK 21. Both JDK 8 and JDK 11 will remain part of Fedora as long as they are supported upstream, and there is a target audience in our OS.
Scope
To keep the java-17-openjdk (and lower versions of JDK), but to remove its java/javac versionless provides, make java-21-openjdk the provider of java, javac and other versionless provides, and keep java-latest-openjdk as rolling package for STS JDKs)
- will guarantee fedora to be pure JDK21 distro.
- will allow maintainers of JDK21 (or higher) incompatible packages to keep using JDK 17, JDK 11 and JDK 8
- if any package depends on a package built by JDK 21, JDK 17, JDK 11 and JDK 8 may not be able to pick up that dependency.
- this may lead to quite a lot of bundling or compat packages, but that may be acceptable
- people developing JDK8 and JDK11 applications will very likely stay with fedora
- we are bumping the system JDK every time a new JDK LTS comes up and it proved itself as a good practice
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
- It appeared, that several applications have to be built by jdk8, while they work fine with jdk11
- It lead to manual work on aligned libraries on 1.8 byte code version. see https://pagure.io/java-maint-sig/issue/7
- Other approaches how to avoid this in next update (jdk17, aprox f36, minimal bytecode 7) were mentioned here: https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-50266
Workflow
- announce as by https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_essential_communication
- tune java-latest-openjdk package (for all live Fedoras)
- clone java-21-openjdk package (for all live Fedoras)
- several rounds of mass rebuilds ( see https://fedoraproject.org/w/index.php?title=Changes/Java21#Expected_schedule)
- from copr
- over side tag
- to koji
Change owners
- Feature will be implemented in side tag
- --target f40-java21 is tag of choice
- In its mass rebuild, approximately XYZ packages were built, and ABC failed. FTBFS bugs filled, most of them needs manual fix later
- the JDK 17 and JDK 21 packages will be changed for this side tag
- the mass rebuild of java stack will start
- 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 jdk21
- 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
- based on selected approach to tune the main build tools
- Release engineering: TICKET_TBD (a check of an impact with Release Engineering is needed)
- mass rebuild will be required for this change
- 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 JDK 21 should remain the only system JDK after installing base javastack on clean system
- the JDK 8, JDK 11, JDK 17, JDK 21 and java-latest-openjd can co-exist on one system
- JDK 21 will be selected by default and will run most of the base java stack
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
$ repoquery -q --whatrequires java-headless |wc -l 736 $ repoquery -q --whatrequires java | wc -l 41 $ repoquery -q --whatrequires java-devel | wc -l 13 $ repoquery -q --whatrequires java-1.8.0-openjdk-headless |wc -l 653 $ repoquery -q --whatrequires java-1.8.0-openjdk | wc -l 8 $ repoquery -q --whatrequires java-1.8.0-openjdk-devel | wc -l 4 $ repoquery -q --whatrequires java-11-openjdk-headless |wc -l 663 $ repoquery -q --whatrequires java-11-openjdk | wc -l 8 $ repoquery -q --whatrequires java-11-openjdk-devel | wc -l 5 $ repoquery -q --whatrequires java-17-openjdk-headless |wc -l 757 $ repoquery -q --whatrequires java-17-openjdk |wc -l 55 $ repoquery -q --whatrequires java-17-openjdk-devel |wc -l 20
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-17-openjdk
- java-21-openjdk
- javapackages-tools
- maybe maven base
Contingency Plan
- If the mass rebuild, after the changes are applied, breaks too many packages, or some crucial component will be unfixable, JDK 17 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
- In general, going back will be, in my opinion, impossible. Once the decision is taken, java stack should be fixed, and where it can not be fixed, it has to migrate to compat packages, or bundled-dependencies packages, or be orphaned.
side tag
https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag
- for these changes, Fedora has technology known as side tag
- I do not have experience with it, but it is making the contingency plan much smoother
- it is an approach, which will be used first
Documentation
- oracle 21 release notes: https://www.oracle.com/java/technologies/javase/21-relnote-issues.html
- openjdk21 jeps: https://openjdk.java.net/projects/jdk/21/ https://openjdk.java.net/projects/jdk/20/ https://openjdk.java.net/projects/jdk/19/ https://openjdk.java.net/projects/jdk/18/
- oracle migration guide https://docs.oracle.com/en/java/javase/21/migrate/index.html
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 pmikova@redhat.com Threads of "F40 system wide change, java-21-openjdk as a 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 JDK 21
No program can say, that it does not support JDK 21, because any javac/java application can be remade to work with JDK 21 - 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 jdk21, and not much excuses are around to support to not to do so. If you package is really bound to JDK 17, you can move to the version-full requires:
BuildRequires: java-17-openjdk(-devel)
and
Requires: java-17-openjdk(-headless).
In addition, if you work with maven/ant or similar builders, you must set export JAVA_HOME=/usr/lib/jvm/java-11-openjdk before calling it. javapackage-tools and comp are made to accept it.
However there is a trap - the packages you are depending 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 up in dependency hell.
Please, try to avoid this as much as possible!
Intermediate step build with java-17-openjdk-devel and run with java (that means any sytem java, eg java-21-openjdk)
Some projects support JDK21 for runtime, but not for compile time.
Buildrequires: java-17-openjdk-devel ... Requires: java(-headless) ... %build ... export JAVA_HOME=/usr/lib/jvm/java-17-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 (pmikova@redhat.com) or ping me (pmikova), 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.7 is no longer supported. Use 8 or later. [ERROR] Target option 7 is no longer supported. Use 1.8 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 7 [javac] error: Source option 7 is no longer supported. Use 8 or later. [javac] error: Target option 1.7 is no longer supported. Use 1.8 or later. BUILD FAILED
- Solution
- Your javac is run with wrong source/tag parameters. net search will give you quick answer
- Fixes are eg:
invalid entry in sources
stdout: Invalid entry in sources file: ae177021dfa32281b3b052a6574e94b9 CardManager_sources3.zip
Your package was not updated for ages, and thus have still sources in MD5
sum format.
Obtain/update/generate your sources, and fedpkg new-sources
them.
If your sources can no longer be obtained., you can check lookaside cache, eg: for this case https://src.fedoraproject.org/repo/pkgs/CardManager/ - https://src.fedoraproject.org/rpms/CardManager/c/35ebf20a6370345947e0722186074487da6d620c?branch=rawhide
encapsulated module
[ERROR] Errors:
[ERROR] com.fasterxml.jackson.dataformat.csv.deser.BasicParserTest#testMapsWithLinefeeds ClassCastException class com.fasterxml.jackson.core.io.IOContext cannot be cast to class com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext (com.fasterxml.jackson.core.io.IOContext and com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext are in unnamed module of loader 'app')
[ERROR] com.fasterxml.jackson.dataformat.csv.deser.BasicParserTest#testSimpleExplicit ClassCastException class com.fasterxml.jackson.core.io.IOContext cannot be cast to class com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext (com.fasterxml.jackson.core.io.IOContext and com.fasterxml.jackson.dataformat.csv.impl.CsvIOContext are in unnamed module of loader 'app')
...
You have to open and export the modules
no longer allowed security manager
In jdk 21, is hard deprecation of SecurityManager. if you are using it, it will throw exception. You can allow it again: -Djava.security.manager=allow