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
