On Thu, 30 Jul 2026 18:05:22 GMT, Alan Bateman <[email protected]> wrote:
>> Well, I don't think we should be changing the behavior without understand >> what spec changes are necessary here. Since desiredAssertionStatus() can be >> called on any `Class` object, it will exhibit some behavior; it seems >> unreasonable for the JVM to fail an assert in any mode, so it should >> probably returning a boolean. On its face it seems reasonable to return >> false for these cases, but there is the additional case mentioned previously >> of non-bootloader array classes that ought to be discussed. >> >> I don't particularly care how this is implemented. But it would seem a bit >> odd to add checking at the Java layer only to have the same checking done in >> the JVM both in an assert and in regular code. Maybe the right thing to do >> is simply to remove the asserts. (If that results in the correct, specified >> behavior.) > >> Well, I don't think we should be changing the behavior without understand >> what spec changes are necessary here. > > I don't think there is a behavior change, at least not for release builds. > It's just the debug build that changes, it no longer hits the assert in > JVM_DesiredAssertionStatus. I restored the old behavior, having the java/lang/Class code not call the VM with primitives and arrays, the case that asserted. Thanks Chen for filing the spec issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32086#discussion_r3686095034
