Formal model for defender method resolution
Brian Goetz
brian.goetz at oracle.com
Mon Jan 24 08:26:48 PST 2011
Dan Smith has pointed out a hole in the Featherweight Defenders
document; there is an unsound disconnect introduced when we allow
covariant overriding but don't require the implementation to be replaced
(rules T-IntNoDef and T-ClassAbs). This would allow the following failure:
k1 : Object
intf A { Object m() default k1 }
intf B extends A { String m() }
Here, the default for A is going to produce a result that does not meet
B's interface contract. I believe what is needed is additional
constraints on T-IntNoDef to include a
\Gamma(mdef(I_i)) <: T
constraint (for the cases where mdef(I_i) is not nil).
I think this is all that is needed to plug this hole.
On 1/19/2011 12:48 PM, Brian Goetz wrote:
> At
> http://cr.openjdk.java.net/~briangoetz/lambda/featherweight-defenders.pdf
>
> I have posted a draft of a formal model for resolution of defender
> methods. This is written in the style of "Featherweight Java"
> (Igarashi, Pierce, et al), in which a number of real-world language
> concerns are abstracted away, in order to simplify the formalism for the
> portion of the language of interest, notably the typing and resolution
> of defender methods.
>
> Hopefully this will serve as a basis for discussion of the proposal.
>
> The T- and S- rules are implemented by the compiler and are used for
> typing; the R- rules are implemented by the VM to do method selection.
> (The primary computed item of interest is mres(C), which is the method
> resolution for a given class -- while this is not used in any further
> production (it would be used if the operational semantics were
> specified), it is in fact the whole point of this exercise.)
>
>
More information about the lambda-dev
mailing list