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
