If I declare following sealed hierarchy
package a;
import b.B;
public sealed interface A permits B {
}
package b;
import a.A;
public record B() implements A {
}
without using modules (no module-info.java) and try to compile it with Maven I get
[ERROR] .../src/main/java/a/A.java:[5,35] class a.A in unnamed module cannot extend a sealed class in a different package
I'm aware of https://openjdk.java.net/jeps/409 and this section:
The classes specified by permits must be located near the superclass: either in the same module (if the superclass is in a named module) or in the same package (if the superclass is in the unnamed module).
However, shouldn't Maven by default use classpath while compiling? Can this limitation be avoided at all?
If not, doesn't this set a precedent where a feature on module path is more flexible than on class path and that in turn - while classpath is still supported, it's not as first class citizen as it used to be when compared to module path?
The classpath is the unnamed module.
The motivation is that a sealed class and its (direct) subclasses are tightly coupled, since they must be compiled and maintained together. In a modular world, this means "same module"; in a non-modular world, the best approximation for this is "same package".
So yes, if you use modules, you get some additional flexibility, because of the safety boundaries modules give you.