Am Freitag, den 27.10.2017, 11:18 +0200 schrieb Damjan Jovanovic: > Hi *wave* > > 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. WTF?! > > 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 > +1 Looks like a clean architecture, LIKE ! S2 > 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? I think javaunohelper makes more sense to me then comphelper. However I do not like "helper" modules at all, since they express patchwork like "I do magic" kind of concept.
My personal favourite would be to have modules that are called what they do: - logging, ressourcemanagement, structure managment (or something that line) And that we end up with maybe more self describing architecture. > > 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? I would say go for it as long as they compile for you. ut thats only me. Would not rate my opinion high. All the Best Peter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
