Am 27.10.2017 um 21:19 schrieb Dave Fisher: > 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 …
Do you need the SDK?
From our release notes (Known Issues):
For developers:
* The OpenOffice SDK won't build with Java 8. Either build with
--disable-odk or see the dev list archives for possible solutions.
Either go with Java 7 or use --disable-odk as configure switch.
Regards, Matthias
>
> 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
>>
smime.p7s
Description: S/MIME Cryptographic Signature
