On Thu, May 2, 2024 at 9:24 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Christopher wrote: > > 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. > > The problem is, without ALSO installing the JDK for the targeted version AND > explicitly pointing -bootclasspath to that JDK, this does NOT catch code > trying to use class library features (as opposed to language or bytecode For context, the use of the bootclasspath is only applicable to building for Java 8. (A related question that I don't know the answer to: how much longer is Fedora going to include Java 8?) However, I believe you are incorrect. JEP 247, which added the `--release` flag, specifically made it replace the need for using `-bootclasspath`. See https://openjdk.org/jeps/247 ; The problem I described in the email you're replying to is specifically that the `-bootclasspath` with JDK 8 will pick up class APIs *outside* of the "<documented-APIs-from-8>", whereas the use of `--release 8` strictly enforces that only the "<documented-APIs-from-8>" are available. This is what I meant when I said that using the `--release` flag more strictly enforces Java 8 language compliance than building with JDK 8. I stand by that statement. It is the `-bootclasspath` that leads people astray, and thus it has been removed for Java 9 and later. > features) from the newer JDK, and worse, in rare occasions, even if the > source code is in principle compatible with the targeted older Java, when > compiled with a newer compiler and older target release, it will fail to > actually run (!) with the latter (because the compiler picks up a subclass > override of a method added in the newer Java instead of the baseclass method > that was always available and, for performance reasons, tries calling the > override explicitly rather than going through the virtual method lookup). > One example of that latter issue is NetBeans, where versions 12.5 and 12.6 > were supposed to be compatible with Java 8, but some upstream-published > binaries of 12.5 and all of 12.6 do not actually work properly on it because > they were built with Java 11 in "-release 8" mode: some editor features fail > with runtime exceptions. See > https://issues.apache.org/jira/browse/NETBEANS-6349 for details. (They > "fixed" it by just requiring Java 11 in NetBeans 13 and newer. No fixed 12.x > release was ever issued.) The CharBuffer/ByteBuffer issues mentioned in that are specifically issues that the use of `--release` resolves. I have fixed this in several projects already who encountered this same issue. Digging into the tickets you linked, it looks like the problem with that issue was that the binaries were built with JDK 11 *without* the use of the `--release` flag... or rather, it looks like somebody tried to use the `--release` flag, but they also used `-Xbootclasspath`, which ended up *disabling* the `--release` behavior. The problem isn't the use of `--release`, it's the *non*-use of it... or the broken use of it, because boot class path options are still being used when they shouldn't. So again, I assert that it's the `-bootclasspath` option that is leading people astray. > > So I am AGAINST systematically using "-release" without "-bootclasspath", > even though that works in most cases and is often successfully used in > production (me and my employer use it, too, but on projects we control where > we will fix the source code or add a workaround to it if any issues come up > from that, not systematically on repackaging third-party projects). The > compiler even warns about the missing "-bootclasspath". And the potential to > cause subtle misbehavior that is a pain to debug is just too high, > especially if we have the actual older JDK available and could just > BuildRequire the correct version. This doesn't make sense. The purpose of the `--release` flag was to replace the need for `-bootclasspath`. The `-bootclasspath` doesn't exist anymore for JDK 9 compliance and later, and using it *breaks* the compliance checks done by `--release` by allowing the built-in checks to be overridden. As for the warning you've mentioned... I'm not sure what warning you're referring to. I've never seen such a warning and have been using `--release` for a long time now. Respectfully, I think you're wrong on some of the points you're raising. Please look into the points I've made, and correct me if it turns out that I'm the one in error. Getting this correct is important to me, and I think it matters for Fedora's Java packaging guidelines, even if it doesn't end up affecting the decision about Requires. So, I'd like to know if I'm wrong. > > Kevin Kofler > -- > _______________________________________________ > 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 -- _______________________________________________ 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
