Nevertheless, even in that case, if I bring in that library from the distro repo, I wouldn't want that lib to also bring JRE 11, because I'll be running my app in JRE 17, however, ... I'd learn quickly that it fails.
The other way around can happen too, a library runs well in 17, but crashes in JRE 11 because of that InetSocketAddress change, for example.
How could that be expressed so that those are caught quickly at build time? Someone wants to depend on a java lib that has been tested only in JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa, for example. Perhaps, the only feasible way to detect that case is with CI.
On 5/2/24 11:58, Christopher wrote:
On Thu, May 2, 2024 at 6:59 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:Carlos Rodriguez-Fernandez wrote:Regarding the proposal as a whole, I think the proposal idea makes a lot of sense, but for apps depending on system jar libraries, there should be a way to specify that the app depends on a specific java bytecode version range. System libraries packages could provide compatibility packages, so couldn't those apps just depend on those compatibility packages instead? That can become a maintenance burden for those libs, though.The safest approach for library JARs would be to always build them against the lowest possible Java version (the oldest JDK branch that we still ship if the library supports that, otherwise the oldest the library supports). And IMHO, if the library is built against a higher version than the lowest we ship, it needs a versioned Requires on the JRE. Kevin KoflerI have noticed that the `--release` flag on javac (JDK>=9) actually enforces JLS compliance more strictly than even compiling with the specific version it targets. For example, it is possible to write a project that is non-compliant with the Java 8 JLS that the Java 8 compiler will incorrectly permit without error. Such a project will not work properly on Java 9 and newer JREs. However, if JDK 9 were used to compile the project with `javac --release 8`, the compiler will catch the non-compliance with the Java 8 JLS that the JDK 8 compiler failed to catch, forcing compliance with Java 8, and allowing the resulting byte code to work on JRE 9 and later. So, I actually think that building with the *latest* JDK that we ship, and using the `--release` flag during compilation is actually safer than building against the lowest that we support, because it is most likely to strictly enforce correct byte code generation for the target JRE. But, this requires project maintainers to explicitly add the use of the `--release` flag if the upstream build does not already set it in some way. Doing this, it should not matter which of our JDKs it builds with, but building with the latest available (rather than the oldest available, as Kevin suggests) will have the best chance for compliance-related bugs to be fixed (but only if the `--release` flag is used). Of course, there are many ways to break Java libraries across JRE versions, but the one I'm focusing on here is one that is preventable, due to JDK enforcement of JLS compliance during compilation, which is more strict in newer JDKs than in earlier ones. If upstream's oldest supported JRE is still supported by the `--release` flag by the JDK used in Fedora's build, then it should be fine to just specify that version, even if it is older than the oldest JRE that Fedora ships. In such cases, it might not technically be necessary to specify a Requires for the JRE. However, if the oldest supported JRE in the upstream project is newer than Fedora's oldest shipped JRE, then having the Requires >= would still be needed. For example, if Fedora ships JRE 11, 17, and 21, and the upstream project targets Java 8, then it should be fine to build that project using JDK 21 with `--release 8` and have no Requires. However, if upstream targets Java 11, then building using JDK 21 with `--release 11` would be okay, but you'd need Requires >= 11 (or maybe Recommends >= 11 ?). I don't object to the original proposal, though. There have been times I've wanted to install a Java library not to run it, but to inspect the jar with a third-party tool (or even just vim). But, I think it's important for Java package maintainers to be aware of what versions their packages' upstream projects are targeting, and make sure they are built correctly for Fedora using Fedora's JDKs. I also think it's important that Fedora packagers communicate the JRE requirements for each package *if* it were to be run. Maybe that can be done with Recommends instead of Requires? I'm not sure about that part, but I acknowledge that installing a library is not the same as intending for it to be run. Christopher -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
