>
> 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

Reply via email to