See you at JVMLS

[Palo Marton]

> If you recreate methods from Bar in Foo$any interface, then any change of
> such method in Bar (addition, signature change, ...) will be binary
> incompatible with separate compilation of Foo even though such method is
> not referenced anywhere in Foo (neither overridden nor called).
>

That's one option - create such "shadow" interfaces for superclasses.
(created by JVM on demand, so no problem with changes in super class after
compilation).

But I see also one more option: *Enhance JVM so that interface can extend
(exactly one) class* (and any number of interfaces). It may sound as an
"extreme" solution ... but somehow it makes sense to me. In current JVM
interfaces already extend one class, namely java.lang.Object. This is
"hardcoded" in JVM - you can e.g. call Object methods on interfaces, stack
slots with interface are treated as containing Object, etc... May be this
can be enhanced in a way that interface can have also different class as
its "superclass". Wild idea, but may be in the long term it is the best
solution...