Final defenders

[Brian Goetz]

Just to head off the obvious follow-on questions:
 - What about private methods in interfaces: entirely feasible, but not targeted at 8
 - What about protected methods: possibly trickier than private methods, not targeted at 8
 - What about package-private methods: feasible, would require additional syntax (e.g., "package" modifier)
 - What about static methods: being considered by the EG

On Aug 7, 2012, at 7:34 AM, Aleksey Shipilev wrote:

> Hi,
> 
> TRAITS! Now, while Brian is gasping with exertion, I'll continue. While
> studying the it2-bootstrap branch code, I have come across using
> defenders in trait-like fashion:
> 
> public interface StatefulOp<T, U, V> {
>    public boolean isStateful() default {
>        return true;
>    }
> }
> 
> In this case, the defender is not particularly the fallback default, but
> really an enforced implementation. However, lacking language support for
> these cases, I can do:
> 
> public class MyRogueOp implements StatefulOp {
>    public boolean isStateful() {
>        return false; // eat that!
>    }
> }
> 
> ...and the defender rules will count my concrete implementation as
> legitimate one. This makes relying on isStateful() quite a bad idea in
> the library.
> 
> That makes me thinking if we need to embrace it, and realize that some
> of the defenders are really final. My suggestion is simple: let's mark
> the final defenders "final"!
> 
> In simplest form:
> 
> public interface StatefulOp<T, U, V> {
>    public final boolean isStateful() default {
>        return true;
>    }
> }
> 
> "final" is not allowed in interfaces by the current rules, so we can use
> this loophole to introduce a new meaning. However, this feels wrong to
> provide the default implementation, and instantly forbid the extension.
> So, maybe this is better:
> 
> public interface StatefulOp<T, U, V> {
>    public boolean isStateful() final {
>        return true;
>    }
> }
> 
> This should be more complicated to implement in compiler, but it clearly
> mandates the method body is the final implementation.
> 
> This is not completely enforceable in the compile time, and so it
> complicates the method dispatch a bit. We need to check if there is any
> superclass final defender in the hierarchy, that can piggyback on the
> defender selection we have now. Also, two colliding defenders, no matter
> if the pairs are default/final, default/default, or final/final should
> render the same error as default/default collision now.
> 
> Additional concern is the evolution. We need to explore two things:
> 1. Can we add "final" to the defender on the existing interface?
> 2. Can we remove "final" from the defender on the existing interface?
> 
> The answer to both seems to be "yes", because the same class of bugs we
> have already with abstract classes and visibility rules, also
> unenforceable with separate compilation. We can still do compile-time
> checks so that code compiled at once would never throw a linkage error.
> 
> Thoughts?
> 
> -Aleksey.
>