Daniel John Debrunner wrote: > Now Y is compiled, but *not* X. > > The VM correectly handles this at runtime, loading X correctly, even > though it does not implement all the methods of Y. It has to, in order > to support upwards compatibility of java code. > > My marking the class as not abstract is just mimicing this situation. >
Maybe so, but don't we always rebuild everything anyway? In which case X won't compile because it doesn't implement all of Y's methods. I think Jeremy's concern, at least my concern if it wasn't his, is whether it is really necessary to use such a trick. I have to side with Jeremy on this one. An expert such as yourself might be able to understand the implications of such implementations and when, or more importantly when not, to use them but the traditional developer won't be able to. So I would ask if there isn't a more traditional solution that could be used instead. I ask about another 'trick' in http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200502.mbox/%3c0006 [EMAIL PROTECTED] where a low level interface, DataValueDescriptor, has methods that return data types of BooleanDataValue which is an interface that extends DataValueDescriptor. This may also be necessary, although no one has responded to say so, but I don't think a circular reference such as this is recommended.
