RFR: 8345911: Enhance error message when IncompatibleClassChangeError is thrown for sealed class loading failures [v4]

[Alan Bateman]

On Fri, 13 Dec 2024 21:01:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 246:
>> 
>>> 244:              this->external_name(), this->package() != nullptr ? this->package()->name()->as_C_string() : "unnamed",
>>> 245:              this->module()->loader_data()->loader_name_and_id());
>>> 246:     log_trace(class, sealed)(" - %s", ss.as_string());
>> 
>> I'm a bit puzzled by the check so I'm not commenting on the log/exception message just yet.
>> 
>> If the super class (this) is in an unnamed module then the permitted subclass (k) must be in the same package.
>> 
>> If the super class is in a named module then permitted subclass can be in a different package but both need to be public in order.
>> 
>> I'm just trying to see how this maps to the check because it doesn't appear to take named vs. unnamed module into account, e.g. the subclass k might be public but in a different package of the same unnamed module. It's possible that I've mis-read this but it to goes to what the exception message is for these cases.
>
> Those are not the rules in JVMS (at least not obviously so). We get ICCE if any of the following are violated:
> 
> - The superclass is in a different run-time module than C (§5.3.6).
> - C does not have its ACC_PUBLIC flag set (§4.1) and the superclass is in a different run-time package than C (§5.3).
> - No entry in the classes array of the superclass's PermittedSubclasses attribute refers to a class or interface with the name N. 
> 
> We already determined both classes are in the same module, so now we just do the public/same-package check. Whether the module is un-named or not doesn't come into it.

Okay, I initially missed the difference between compile-time and run-time behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1886870750