└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Fedora 43 Java Change Proposal 2 | 3 | ## Glossary 4 | 5 | - **Java** – A programming language and platform. 6 | 7 | - **OpenJDK** – An open-source implementation of Java, typically packaged as `java-$x-openjdk`. 8 | 9 | - **LTS OpenJDK** – Long-Term Support versions of OpenJDK, maintained upstream for extended periods. Packaged as `java-$version-openjdk`. 10 | 11 | - **STS OpenJDK** – Short-Term Support versions of OpenJDK, maintained for around 6 months until the next major release. Packaged as `java-latest-openjdk`. 12 | 13 | - **Java package** – A Fedora RPM package containing Java code compiled from source. 14 | 15 | - **Java application** – A Java package designed for end users. It includes a launcher in `/usr/bin`. 16 | 17 | - **Java library** – A Java package that is not a standalone application. It provides only JAR files and is intended to be used as a dependency in other Java applications. 18 | 19 | - **Java SIG** – An informal group of contributors interested in Java in Fedora. We don't hold formal meetings or use a dedicated Matrix room, but we actively collaborate to deliver a great Java experience in Fedora. 20 | 21 | 22 | ## Compatibility 23 | 24 | Java is renowned for its exceptional backward compatibility. Applications compiled decades ago can still run on modern Java runtimes, with no compromise in performance or security—thanks to Just-In-Time (JIT) compilation. 25 | 26 | The reverse is also possible: Java code can run on older JDKs if compiled with the `--release` flag, which is a very common practice. 27 | 28 | This flexibility allows Fedora to ship packages built with different Java versions, all working seamlessly together. There is no need for version-specific package duplication. 29 | 30 | Additionally, users can run applications using a different Java runtime than the one used to build them. For example, Fedora-packaged applications can run with Adoptium JDKs from third-party repositories. 31 | 32 | 33 | ## Status in Fedora 41 and Earlier 34 | 35 | - Multiple LTS versions of OpenJDK were packaged. 36 | - One version was designated the “system Java.” 37 | - Switching the system Java required a FESCo-approved change and coordinated porting by the Java SIG. 38 | 39 | 40 | ## Status in Fedora 42 41 | 42 | - Only one OpenJDK LTS version (OpenJDK 21) is packaged. 43 | - OpenJDK 21 is the de facto "system JDK" due to lack of alternatives. 44 | - Some may argue there is no "system JDK" because there is no choice. 45 | 46 | 47 | ## Proposed Change for Fedora 43 48 | 49 | - Introduce another LTS version—OpenJDK 25—alongside OpenJDK 21. 50 | - Treat both LTS versions equally; neither is the default. 51 | - Users and maintainers can choose which version to use. 52 | - The most recent version will likely become the conventionally preferred one, but this is not enforced. 53 | 54 | 55 | ## What This Change Means for Fedora Users 56 | 57 | - Greater flexibility in selecting the Java runtime. 58 | - Freedom to mix and match Java versions for development and runtime. 59 | - Ability to use Fedora Java packages with third-party JDKs. 60 | 61 | 62 | ## What This Means for Java Package Maintainers 63 | 64 | - Packages built with OpenJDK 21 will remain on 21 until maintainers opt to migrate to OpenJDK 25. 65 | - Migration can proceed gradually over multiple Fedora releases. 66 | - Java SIG may assist in migrating packages when needed. 67 | - Bugs will be filed for packages that are hard to migrate. 68 | - Provenpackagers may fix some issues if maintainers are unresponsive. 69 | - Unmaintained packages may be retired when their Java version is retired. 70 | 71 | **Key Benefit:** Unported packages will no longer block the adoption of new Java versions. Updates will proceed more smoothly, and the Java SIG will no longer have to carry the burden of mass migration efforts alone. 72 | 73 | 74 | ## Runtime Strategies for Java Applications 75 | 76 | Java applications in Fedora can follow one of these approaches: 77 | 78 | 1. **Generic Java dependency** 79 | Use a generic “java” dependency – This allows compatibility with any implementation, including third-party JDKs. The actual runtime is chosen based on available repositories and system alternatives. 80 | _Examples: Tomcat, LibreOffice_ 81 | 82 | 2. **Specific OpenJDK version dependency** 83 | The application uses only the specified OpenJDK version. Third-party JDKs or alternatives configuration won’t affect it. 84 | _Examples: JFlex, CUP_ 85 | 86 | 3. **Version-specific subpackages** 87 | Offers bindings for multiple Java versions; users choose the one they need. 88 | _Examples: Maven, Ant_ 89 | 90 | Application maintainers know their software best and can choose the strategy that aligns with their users' needs. 91 | 92 | **Note:** Java library packages are not affected by these runtime concerns, as they do not depend on any Java runtime. 93 | --------------------------------------------------------------------------------