Hi

As of revision 1814552, I've rewritten our formerly C++ based SDBC-JDBC
bridge driver in Java. The SDBC-JDBC bridge is there to allows AOO to
access databases through Java's JDBC drivers.

This port originally aimed at fixing serious issues I discovered in the old
C++ implementation, where there is apparently memory corruption on method
IDs that causes methods to be called on wrong Java objects. In the process
of porting I've also discovered and fixed many other problems. For example:
* The C++ code was calling Java code through the Java Invocation API, so it
was using strings to look up method names. This defeats type checking, and
in some cases was looking for methods with typos in their names or that
don't even exist. My current bridge only uses Java to Java calls that are
always strongly type checked and correct.
* Conversions between bytes and chars were broken: n bytes were being
copied verbatim into memory for char arrays n chars long in Java (Java's
char is 16 bits) so the second half of the array was untouched and the
first half had wrong chars, and non-existent classes like
java.io.CharArrayInputStream were being created. Real classes that do
exist, and proper character set conversions, are now used.
* Chained Java exceptions are now converted to chained UNO exceptions via
the commonly used and clearer getCause() chaining dimension, not the
java.sql.SQLException's getNextException() chaining dimension.

The new driver is, as seen externally, completely interchangeable with the
old one. Service names are identical, implementation names are identical,
supported interfaces are identical, the configuration schema is identical,
initialization arguments are identical, even logging channels and messages
logged are identical - client code using the old driver should be able to
use the new one transparently, and not only should everything that worked
before still work now, but some things that didn't work before might also
begin to work now.

Having said that, the driver does push UNO to its limits, and might reveal
other bugs in UNO bridging, Base, other AOO components, and the C++ runtime
environment. I already discovered AOO sometimes crashes on FreeBSD due to
issues in converting exceptions from Java to C++ (missing exception RTTI
causes a segfault), but such bugs should be fixed in main/bridges and/or
the Clang project.

There are still some cleanups I want to do, like making sure nulls strings
are never passed or returned to UNO, cleaning up exception handling, doing
a comparison of every C++ method with every Java method to see if I missed
anything, and so on, which is why the old C++ code has been left in the
tree for now even though it's no longer built. In the meanwhile, please
feel free to start testing :).

Oh and my original memory-corruption-induced IllegalClassChangeError is
gone - my PostgreSQL SDBC driver already works better with the new
SDBC-JDBC bridge :).

Damjan

Reply via email to