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.
