Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42290700.3020306@debrunners.com>
Date: Fri, 04 Mar 2005 17:10:24 -0800
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Single JDK14 compile model?
References: <4228E051.5010601@debrunners.com> <4228FC74.2020408@apache.org>
In-Reply-To: <4228FC74.2020408@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.