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.
