db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: jsr169 build
Date Mon, 14 Apr 2008 16:24:45 GMT
Rick Hillegas wrote:
> 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.

That can be done today, by setting compile.classpath to be the same as 
the jsr169 compile classpath. See the comments in the 
compilepath.properties file.

> 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.

This will only be true if one has the J2ME class libraries, building the 
jsr169 JDBC classes will fail if the classpath is jdk1.4 since they do 
not fully implement the JDBC 3.0 interfaces.

> 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.

Already can be done today, though at one point was failing since I guess 
no one runs regular builds this way. See:
https://issues.apache.org/jira/browse/DERBY-3484

Probably some improvements could be made, so that if the jsr169 compile 
classpath variable is set, then compile.classpath is set to the same value.

Dan.

Mime
View raw message