Hi
To update you on my development efforts, the PostgreSQL driver continues to
advance. I recently added views and fixed a major problem where "Refresh
Tables" causes everything done to tables from then on to fail (as Base
keeps holding references to the old table/view/user/group containers, so
container contents may change, but containers themselves must persist for
the lifetime of the driver).
I did however run into a disturbing bug. When my SDBC driver in Java calls
XStatement.close() on our underlying SDBC to JDBC converter driver written
in C++, and it calls java.sql.Statement.close() in the PostgreSQL JDBC
driver, I get a reproducible unchecked java.lang.IllegalClassChangeError
exception. After hours of debugging I did manage to work around it, by
getting a new methodID before every JNI call to close() instead of caching
it in a static global variable, which shouldn't be required as methodIDs
are meant to persist for the lifetime of the JVM. Either it's a bug in the
JVM itself, or an obscure bug in our SDBC-JDBC driver, such as memory
corruption or the like :(.
Instead of committing that senseless methodID hack, I've decided to port
the SDBC-JDBC driver to Java, which should make memory corruption
impossible and any debugging and future maintenance much easier (the JNI
code to call into Java is exceptionally complex and ugly, and compiles into
a 15 MB pig of a library in a debug build!). Nothing is lost by using Java,
as the C++ driver can't load JDBC drivers without Java either, and
performance should be identical as the slow boundary between native and
Java is crossed an equal number of times, the crossing just happens in the
JNI bridge under main/bridges instead of the SDBC-JDBC driver.
So far the reusable parts of the PostgreSQL driver have been split off into
a dbtools.jar that will be used in a new sdbc-jdbc.jar, which is itself
currently in the painful phase of dealing with JDBC classloading and class
caching. The final architecture should be something along these lines:
The rest of AOO (mostly C++)
| |
|UNO | UNO
| v
| PostgreSQL SDBC driver (Java)
| | |
| | UNO | UNO
v v v
SDBC-JDBC driver (Java) SDBC-ODBC driver (C++)
| | |
| Java | Java | C
v v v
other PostgreSQL JDBC PostgreSQL ODBC
JDBC driver (Java) driver (C)
drivers | |
| network I/O |
v v
PostgreSQL server
I've also already developed considerable support code for Java (logging,
resource bundles, data structure manipulation), all ported from the support
code for C++ under main/comphelper. Since it is generally useful to other
Java UNO modules, should I move it elsewhere, such as main/javaunohelper
which already contains similar support code, or is there somewhere better?
There are also some API-changing improvements I would like to make to
main/javaunohelper and/or main/ridljar. Is it ok to do those in trunk? Are
Java APIs (as opposed to UNO APIs) allowed to change between AOO 4.1 and
4.2?
Damjan
