Details
-
Bug
-
Resolution: Fixed
-
P4
-
repo-valhalla
-
generic
-
generic
Description
In this concrete example:
class A {
abstract class D {}
}
abstract class B {
int f;
}
abstract class C extends B {}
javac at the moment marks every class with ACC_IDENTITY and also the inner class attribute flag of class B as inner of A mentions ACC_IDENTITY.
As seen in the context ofJDK-8286692:
The identity and value restrictions are inherited: it is an error for a value class to implement an identity interface, or vice versa, or for an abstract class or interface to extend both kinds of superinterfaces.
The restrictions are "inherited" (in an informal sense that we haven't explicitly defined anywhere—this is just an intuition). The modifiers themselves are not. All the checks in JLS/JVMS do a full search of the supertypes, don't depend on anything being propagated from a super type to a subtype and appearing in the subtype.
Dan further clarified that :
Java language has a concept of "implicitly declared" modifiers. So just like an implicitly final class has ACC_FINAL set, an implicitly identity class has ACC_IDENTITY set.
This is different from the case in which an abstract class extends an identity class, but has no particular constraints itself. In that case, ACC_IDENTITY would not be set on the subclass that extends the identity class.
In the concrete example above, A, B, and D would be ACC_IDENTITY, while C would not.
(A because it's concrete, B because it has an instance field, D because it's an inner class.)
In particular, if B were modified to no longer be an identity class, C should be able to function as a supertype of a value class without recompilation.
class A {
abstract class D {}
}
abstract class B {
int f;
}
abstract class C extends B {}
javac at the moment marks every class with ACC_IDENTITY and also the inner class attribute flag of class B as inner of A mentions ACC_IDENTITY.
As seen in the context of
The identity and value restrictions are inherited: it is an error for a value class to implement an identity interface, or vice versa, or for an abstract class or interface to extend both kinds of superinterfaces.
The restrictions are "inherited" (in an informal sense that we haven't explicitly defined anywhere—this is just an intuition). The modifiers themselves are not. All the checks in JLS/JVMS do a full search of the supertypes, don't depend on anything being propagated from a super type to a subtype and appearing in the subtype.
Dan further clarified that :
Java language has a concept of "implicitly declared" modifiers. So just like an implicitly final class has ACC_FINAL set, an implicitly identity class has ACC_IDENTITY set.
This is different from the case in which an abstract class extends an identity class, but has no particular constraints itself. In that case, ACC_IDENTITY would not be set on the subclass that extends the identity class.
In the concrete example above, A, B, and D would be ACC_IDENTITY, while C would not.
(A because it's concrete, B because it has an instance field, D because it's an inner class.)
In particular, if B were modified to no longer be an identity class, C should be able to function as a supertype of a value class without recompilation.