Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 28 Mar 2006 14:24:49 +0200
From: Andreas Korneliussen <Andreas.Korneliussen@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-1146) Verify that JDBC4 signatures
 satisfied
In-reply-to: <44292893.2060005@Sun.COM>
To: derby-dev@db.apache.org
Reply-to: Andreas.Korneliussen@Sun.COM
Message-id: <44292B11.9090907@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5 (X11/20060113)
References: <1315148802.1143544280659.JavaMail.jira@ajax>
 <442922F2.4080001@sun.com> <44292893.2060005@Sun.COM>

Anurag Shekhar wrote:
> 
> 
>> Also, I think this also indicates that we should consider using 
>> delegation instead of inheritance for code reuse.
>>
>> Andreas
>>
> I didn't get it, how does it indicates that ?
> anurag

Because now we are fooling the compiler to think that EmbedXXX40 classes 
implement java.sql.XXX interface since it inherits from a class which 
has declared that it implements it. The problem is that the base class 
is compiled against an old runtime library, and we lose the compile time 
checks for the new methods.

This way of doing things was not introduced as part of JDBC4, it also 
applies to JDBC3 vs JDBC2.  So basically a developer may accidentally 
change the signature of a JDBC3 method, and the compiler will not 
complain. You will only detect the error in runtime, i.e through tests.

Andreas