Abstract class with fields implementing ValueObject

[Dan Smith]

Fred suggested that we enumerate the whole space here. So, some cases to consider:

{ ACC_PERMITS_VALUE, not }
{ has an <init> declaration, not }
{ implements IdentityObject, not }
{ implements ValueObject, not }

"implements" here refers to both direct and indirect superinterfaces.

I'll focus on the first two, which affect the inference of superinterfaces.

(1) ACC_PERMITS_VALUE, <init> declaration

This is a class that is able to support both identity and value subclasses. It implements no extra interfaces, but can restrict its subclasses via 'implements IdentityObject' or 'implements ValueObject'.

(2) ACC_PERMITS_VALUE, no <init> declaration

The JVM infers that this class implements ValueObject, if it doesn't already. If it also implements IdentityObject, an error occurs at class load time.

(Design alternative: we could ignore the <init> declarations and treat this like case (1). In that case, the class could implement IdentityObject or be extended by identity classes without error (as long as it doesn't also implement ValueObject). But those identity subclasses couldn't declare verification-compatible <init> methods, just like subclasses of abstract classes that have no <init> methods today.)

(3) no ACC_PERMITS_VALUE, <init> declaration

The JVM infers that this class implements IdentityObject, if it doesn't already. If it also implements ValueObject, an error occurs at class load time.

(4) no ACC_PERMITS_VALUE, no <init> declaration

This is a class that effectively supports *no* subclasses. We don't infer any superinterfaces, but it can choose to implement IdentityObject or ValueObject. A value class that extends this class will fail to load. If the class doesn't implement ValueObject, an identity class that extends this class could load, but couldn't declare verification-compatible <init> methods, just like subclasses of abstract classes that have no <init> methods today.

(Design alternative: we could ignore the <init> declarations and treat this like case (3). In that case, it would be an error for the class to implement ValueObject, because it also implicitly implements IdentityObject.)

---

Spelling this out makes me feel like treating the presence of <init> methods as an inference signal may be overreaching and overcomplicating things. Today, declaring an <init> method, or not, has no direct impact on anything, other than the side-effect that you can't write verification-compatible <init> methods in your subclasses. I like the parallel between "permits identity (via <init>)" and "permits value (via flag)", but flags and <init> methods aren't really parallel constructs; in cases (2) and (4), we still "permit" identity subclasses, even if they're pretty useless.

(And it doesn't help that javac doesn't give you any way to create these <init>-free classes, so in practice they certainly don't have parallel prevalence.)

Pursuing the "design alternative" strategies would essentially collapse this down to two cases: (1) ACC_PERMITS_VALUE, no superinterfaces inferred, but various checks performed (e.g., no instance fields); and (3) no ACC_PERMITS_VALUE, IdentityObject is inferred, error if there's also an explicit 'implements ValueObject'.

How do we feel about that?