db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: JSR169 support
Date Mon, 04 Oct 2004 20:12:48 GMT
Hash: SHA1

Daniel John Debrunner wrote:

> I'm going to look into completing JSR169 support for Derby.

At this time I'm just looking at getting the embedded engine running on
CDC/Foundation 1.0 & JSR 169. More investigation is needed to make the
network server, ij and dblook run in that configuration. Support for
OSGi ee.minimum is additional work on top of this.

Setting compile.classpath to use CDC/Foundation 1.0 & JSR 169.

[ Any ant build.xml files that use compile.classpath for the engine are
code areas that need to compile & run under JSR169. Classes that only
need to run in JDBC 2.0 or JDBC 3.0 use java13compile.classpath or
java14compile.classpath. ]

Classes missing causing compile errors


Methods missing causing compile errors


These missing classes have an impact of supported SQL functionality when
running under JSR169.

DECIMAL datatype
  I think this datatype needs to be supported under JSR169 though how,
is less clear.

Java functions and procedures that use SQL through server side JDBC
  Can not support, the standard mechanism to get the JDBC connection in
a procedure or function, uses the
DriverManager.getConnection("jdbc:default:connection"). JSR 169 does not
support the DriverManager class. Note that this standard default
connection URL is specified by the SQL standard Part 13 and not by JDBC.

Derby system procedures that use server side SQL
  Probably need to support, since they are internal they could use a
private, non-standard mechanism to get the server side JDBC connection.

Diagnostic virtual tables (lock table etc.)
  Probably need to support, probably can just compile them against
JSR169 libraries.

- ---------

My first steps are going to be reducing the number of compile errors I
see when compiling in this environment by removing unused imports of the
missing classes and moving code from the Embed* JDBC classes to the
Embed*20 classes, when that code is in JDBC 2 but not JSR169. Then the
Embed* will be the base and JSR169 classes, Embed*20 are JDBC 2 specific
and Embed*30 JDBC 3 specific. These specific changes will not require
downloads of J2ME or JSR169 jars. I'll also try and set it up so that
the build uses jsr169 ibraries if they are available (by setting ant
properties), so others can see the issues.

Further progress probably requires easy downloads of the
CDC/Foundation1.0 and JSR169 jars for everyone. Thanks for Geir for
looking into that.


Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message