Hi Damjan, On my release machine (Win 10) it stops with:
--- make: *** [C:/Source/aoo/main/solenv/gbuild/UnoApiTarget.mk:165: /cygdrive/c/Source/aoo/main/solver/420/wntmsci12.pro/workdir/UnoApiPartTarget/offapi/com/sun/star/sdb/ParameterSubstitution.urd] Error 1 make: *** Waiting for unfinished jobs.... dmake: Error code 2, while making 'all' 1 module(s): offapi need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /cygdrive/c/Source/aoo/main/offapi/prj When you have fixed the errors in that module you can resume the build by running: build --from offapi --- I will try to force a build on our buildbot to cross check. Regards, Matthias Am 08.11.2017 um 05:34 schrieb Damjan Jovanovic: > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
