db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RPost" <rp0...@pacbell.net>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 02:28:04 GMT
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
01c516d3$a8382710$1401a8c0@rpws002%3e 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.


Mime
View raw message