@scordio Can I contribute to this one?

Sure and thanks, @pbacz!

@scordio
After conducting an initial investigation, I have identified a concern regarding this idea. From a Java perspective, it is impossible to create a sealed class without any permitted subclasses. This limitation could render the proposed assertion method hasNoPermittedSubclasses() useless.
However, it's noteworthy that both the class file specification and the Javadoc for Class::getPermittedSubclasses suggest that such a scenario is possible.

In light of this, I would like to seek your input on the following questions:

• Should we proceed with adding this assertion despite the aforementioned Java constraint?
• If the decision is affirmative, be advised that crafting a test for this scenario may involve unconventional methods to load a sealed class without any permitted subclasses (potentially by adding a prepared class file to the repository and loading it using a custom class loader). Are you comfortable with employing such strategies in the testing process?

You're referring to hasNoPermittedSubclasses(), right? (I just edited the description to show the expected parameters for the two methods)

From a Java perspective, it is impossible to create a sealed class without any permitted subclasses. This limitation could render the proposed assertion method useless.

That's absolutely correct when the object under test is a sealed class. However, hasNoPermittedSubclasses() should work properly with the cases mentioned in the getPermittedSubclasses Javadoc:

If this Class object represents a primitive type, void, an array type, or a class or interface that is not sealed, that is isSealed() returns false, then this method returns null.

We might have a testing strategy similar to how we tested hasNoSuperclass.

Would that make sense?

You're referring to hasNoPermittedSubclasses(), right?

Yes, I added the clarification in my previous comment.

That's absolutely correct when the object under test is a sealed class. However, hasNoPermittedSubclasses() should work properly with the cases mentioned in the getPermittedSubclasses Javadoc:

Sure, but this would effectively make hasNoPermittedSubclasses a synonym for isNotSealed (except for the rare corner case when there really is a sealed class with no permitted subclasses). Do we need it?

We might have a testing strategy similar to how we tested hasNoSuperclass. Would that make sense?

Of course, but this only tests a case when getPermittedSubclasses() returns null. What about a case when getPermittedSubclasses() returns an ampty array?

For hasPermittedSubclasses(Class<?>...) method. Should it behave like contains or containsExactly?

Ok, I can see from the convention in AbstractClassAssert that it should behave like contains.
Should hasOnlyPermittedSubclasses also be added to cover containsExactly case?

@pbacz I propose we add only hasPermittedSubclasses with contains behavior and we can always add more if there is a concrete demand.

WDYT?

@scordio I think it's fine. I'll do it this way.

@scordio
Hi, a PR is ready.