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:46:42 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-1146) Verify that JDBC4 signatures
 satisfied
In-reply-to: <442922F2.4080001@sun.com>
To: derby-dev@db.apache.org
Cc: Andreas.Korneliussen@Sun.COM
Message-id: <wjo81wwm91ot.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/22.0.50 (usg-unix-v)
References: <1315148802.1143544280659.JavaMail.jira@ajax>
 <442922F2.4080001@sun.com>

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:

  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.

  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.

  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.

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

+1

-- 
Knut Anders