Hi - As an aside I am working on Mac builds for 4.1.4 and it looks like uno does not like JDK 8+, something to do with javadocs, but not sure as I am looking for JDK7 …
If I can get things working I will be willing to try builds for you on trunk or a branch as you make changes. Regards, Dave > On Oct 27, 2017, at 12:05 PM, Peter Kovacs <pe...@apache.org> wrote: > > 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 >
signature.asc
Description: Message signed with OpenPGP
