简体   繁体   中英

Sealed classes for classes in different packages

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM