Abstract class with fields implementing ValueObject

[Dan Heidinga]

>
> My initial reaction was that, no, we really do want IdentityObject here, because it's useful to be able to assign an abstract class type to IdentityObject.
>
> But: for new classes, the compiler will have an opportunity to be explicit. It's mostly a question of how we handle legacy classes. And there, it would actually be bad to infer IdentityObject, when in most cases the class will get permits_value when it is recompiled. Probably best to avoid a scenario like:
>
> - Compile against legacy API, assign library.AbstractBanana to IdentityObject in your code
> - Upgrade to newer version of the API, assignment from library.AbstractBanana to IdentityObject is an error
>
> So, okay, let's say we limit JVM inference to concrete classes. And javac will infer/generate 'implements IdentityObject' if it decides an abstract class can't be permits_value.
>
> What about separate compilation? javac's behavior might be something like: 1) look for fields, 'synchronized', etc. in the class declaration, and if any are present, add 'implements IdentityObject' (if it's not already there); 2) if the superclass is permits_value and this class doesn't extend IdentityObject (directly or indirectly), set permits_value. (1) is a local decision, while (2) depends on multiple classes, so can be disrupted by separate compilation. But, thinking through the scenarios here... I'm pretty comfortable saying that an abstract class that is neither permits_value nor a subclass of IdentityObject is in an unstable state, and, like the legacy case, it's probably better if programmers *don't* write code assuming they can assign to IdentityObject.
>

I agree that "it's probably better if programmers *don't* write code
assuming they can assign to IdentityObject."  We've historically
assumed that separate compilation should endeavour to be consistent
and if not, should live with the consequences.  The best analogy I can
think of is the StackOverflowError due to bridge method loops - there
we tell users to fix their separate compilation issues and don't try
to paper over it in the VM - and I think it's best to do the same
here.

Using both (1) and (2) is the right call here - no need to limit to
the local information when we can make the better decision using other
necessarily available classes (ie: the superclass)

--Dan