Fix: fields shadowing with sealed classes.

[Mo-Naga]

In issue #605, the JVMClassInfo has a shadowing fields: permittedSubclassNames, isSealed, that are exist in parent class ClassInfo. Removing this redefined field solves the problem.

[Copilot]

Pull request overview

Fixes sealed class enforcement by removing JVMClassInfo field re-declarations that were shadowing ClassInfo’s isSealed and permittedSubclassNames, preventing ClassInfo.isSealed() / isPermittedSubclass() from observing parsed values.

Changes:

• Removed permittedSubclassNames and isSealed field declarations from JVMClassInfo to avoid shadowing inherited ClassInfo state.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This change fixes sealed-class enforcement by removing field shadowing, but there’s still no regression test that would have caught the original bug (i.e., loading a class that illegally extends/implements a sealed type should fail). Please add a test that defines a sealed class/interface plus a non-permitted subclass/implementor and asserts JPF throws the expected IllegalAccessError (e.g., via verifyUnhandledException).

[Mahmoud-Khawaja]

Hi Mo,
Thank you for your pull request. can you please add some tests? maybe something to test isSealed or isPermittedSubclass(). we need to check that parsing a .class file correctly populates isSealed and permittedSubclassNames. this is gonna be a little bit hard i know but i dont think there is a way to do it other than this.

[Mo-Naga]

Hi Mahmoud,

Thank you for your feedback. As far as I know, you don't need to test the pasting or the JPF behavior. I was thinking about adding a test in SealedClassesTest.java, similar to:

@Test
public void testSealedClassIsRecognized() {
    if (verifyNoPropertyViolation()) {
        assertTrue(Notification.class.isSealed());
        assertTrue(Payment.class.isSealed());
    }
}

However, it seems that is not going to work. I will continue working on this.

Thanks