db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: jsr169 build
Date Mon, 14 Apr 2008 16:12:19 GMT
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> 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.
> It's intended to catch situations where classes not in 
> J2ME/CDC/Foundation 1.1 & JSR 169 leak into Derby's jsr169 
> implementation. Methods we don't care about, it's fine for a JDBC 3 
> method to be present in a JSR 169 implementation, some probably are 
> because they tend to be pushed as high up the hierarchy as possible.
> The build was not set up to do what you were trying to do, probably 
> the base JDBC 3.0 class was compiled with JDK 1.4 libraries and 
> therefore succeeded and then the jsr169 class succeeded simply because 
> it used an already compiled base class.
> If the base JDBC 3.0 class was not compiled with jdk 1.4 but was 
> automatically compiled by the jsr 169 compile phased then that has to 
> fail because the base JDBC 3.0 class refers to classes not in the 
> jsr169 classpath.
> Dan.
Hm, the situation looks like this to me:

1) The special jsr169 compilation phase is supposed to catch places 
where Derby makes references and calls that won't work on J2ME.

2) But we only run these compile-time checks on 4 classes. Almost all of 
the other classes in Derby are supposed to run on J2ME but we don't 
check whether they make illegal references and calls.

3) We rely on regression tests to find the problems in these other classes.

The following approach makes more sense to me:

A) The Derby build should be reworked so that it builds almost 
everything against the J2ME libraries.

B) If you have not set the jsr169 classpath variable, then the build 
should default to using the jdk1.4 classpath.

I think this would provide the following advantages:

i) The jsr169 support would always be built, by default.

ii) If you do have the J2ME libraries in your build environment, then 
you will find the discrepancies at compile-time. This will give us more 
coverage than we get from regression tests.

What do people think?


View raw message