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 17:00:24 GMT
Daniel John Debrunner wrote:
> 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
Great! It's being tracked. Thanks.
> 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.

View raw message