db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 01:10:24 GMT
Jeremy Boynes wrote:

> Daniel John Debrunner wrote:
> 
>>
>> The trick I then use is to modify the class file sometime after
>> compilation to mark it concrete by modifying the byte code in the .class
>> file (using Derby's class file utilities). This does not cause any
>> problems with the JVM (though there are some issues with the current
>> version of jikes that Derby uses).
>>
> 
> This really really worries me and I am very uncomfortable with it.

My justification is that it is exactly the same as if the class file
implementing the interface has been compiled against one version of the
interface, and then run with a newer version. JVM's handle this correctly.

Take a simple example.

public interface Y
{
   public void a();
}

public class X implements Y
{
   public void a() {}
}

Now I compile X and Y, everything is correct.

Now Y is modified to add a method.

public interface Y
{
   public void a();
   public void b();
}

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.

Dan.


Mime
View raw message