db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-1146) Verify that JDBC4 signatures satisfied
Date Tue, 28 Mar 2006 13:54:26 GMT
Knut Anders Hatlen wrote:
> Andreas Korneliussen <Andreas.Korneliussen@Sun.COM> writes:
>> This is very interesting.
>> However, isn't it the job of the compiler to figure out that the
>> signatures of an interface has been implemented ?
>> I did the following change to EmbedResultSet40:
>> I added "implements java.sql.ResultSet" in the class definition. The
>> compilation then failed with:
>>      [javac]
>>      /home/ak136785/devel/derbydev/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedResultSet40.java:33:
>>      org.apache.derby.impl.jdbc.EmbedResultSet40 is not abstract and
>>      does not override abstract method
>>      updateNCharacterStream(java.lang.String,java.io.Reader,int) in
>>      java.sql.ResultSet
>> .. + warnings
>> The base class of EmbedResultSet40 also claims that it implements
>> java.sql.ResultSet, however it is compiled against a previous jre
>> version which does not have the new methods.  By declaring that the
>> EmbedResultSet40 class implements java.sql.ResultSet, I make the
>> compiler check that the class implements the interface when compiling
>> it with the 1.6 jre.
> Yes, I have observed this too, and I agree that it is the job of the
> compiler to check this. However, I think there are some good reasons
> for having a test as well:

I agree that you should keep the test as well - at least as long as the 
current model for reuse is kept.

>   1) Relying on the developers to include "implements java.sql.(...)"
>      in the subclasses is error-prone since the compiler doesn't
>      complain if it's missing.

It is less error-prone than not including it, however it does not solve 
all problems.

>   2) There might be cases where we don't have a separate 4.0 class,
>      either because it's forgotten or because the new JDBC 4.0 methods
>      could be compiled with older JDKs.

In such cases, one could make a separate class, which uses delegation to 
reuse the JDBC 3 methods, and implements the JDBC 4 methods. The new 
class should then be compiled against jdk1.6 rt.

>   3) Writing the test was a lot more fun than going through all
>      classes and adding "implements foo"! :)
>> I think it would be good for all EmbedXXX40 to declare which interface
>> they are supposed to implement, and then the compiler will make sure
>> that all signatures are satisfied.
> +0.5
> It might be a good idea, but it might also just give us a false sense
> of security. For EmbedResultSet40 this would expose the errors, but it
> wouldn't help us to find that something is missing in EmbedClob.

Yes, it would only solve parts of the problem, therefore I also suggest 
  changing the model to delegation, and to always make a new class if a 
JDBC interface has been extended with new methods, and finally compile 
the JDBC classes against the correct runtime libraries.


>> Also, I think this also indicates that we should consider using
>> delegation instead of inheritance for code reuse.
> +1

View raw message