db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: jsr169 build
Date Fri, 11 Apr 2008 21:48:17 GMT
Hi Rick,

JSR 169, removes  some interfaces and methods on interfaces (example 
Array and ResultSet.getArray(), Connection.getTypeMap())

Rick Hillegas wrote:
> I am trying to figure out what is the difference between jsr169 and 
> jdbc3 which requires that we use the small platform jars in order to 
> build Derby's J2ME support. I have tried the following experiment on 
> the four source files which comprise our jsr169 support (the 
> classnames which end in "169"):
>
> 1) I made the 3 JDBC classes (the jsr169 versions of ResultSet, 
> CallableStatement, and PreparedStatement) extend our JDBC3 versions of 
> these classes.
>
> 2) Then I compiled Derby with my jsr169compile.classpath pointing at 
> my small device jars.
>
> This compilation succeeded. This says to me that the optional small 
> device compilation is not going to catch situations where JDBC3 
> methods leak into our jsr169 implementation.
true but the TCK should for 169 via the signature tests
>
> I then ran a further experiment on top of these changes:
>
> 3) I changed jsr169compile.classpath to point at the jdk1.4 jars instead.
>
> This compilation also succeeded. I am wondering what would break if we 
> simply compiled our J2ME support using the jdk1.4 compiler as 
> described above. I'm attaching the diff for (1) and (2). I'd be 
> curious to learn what happens when this patch is applied and the tests 
> are run on the small device platform.

>
> Thanks,
> -Rick

Mime
View raw message