jsr169 build

[Rick Hillegas <Ri...@Sun.COM>]

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.

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

Re: jsr169 build

["Lance J. Andersen" <La...@Sun.COM>]

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

Re: jsr169 build

[Rick Hillegas <Ri...@Sun.COM>]

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.

Re: jsr169 build

[Daniel John Debrunner <dj...@apache.org>]

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.

Re: jsr169 build

[Rick Hillegas <Ri...@Sun.COM>]

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?

Thanks,
-Rick

Re: jsr169 build

[Daniel John Debrunner <dj...@apache.org>]

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.