Hi Matthias, It is no longer easy to get EOLed JDKs. You have to pay Oracle for support. You have to pay Apple to get the old SDKs you need for Mac OpenOffice. I don’t mind paying Apple as I have the goal of trying to sign the Application to avoid Gatekeeper. I have the Xcode stuff and I’ve found JDK 6s. If a friend has the the JDK7 in /Libary/Java/JavaVirtualMachines/ and would ship it to me that would be AWESOME.
In my builds with JDK6 I am now having trouble with Help. There is a lot wrong with the Building guides. Too many options - MacPort or Brew, etc. I’ve spent about 16 hours this week on this and … I am about done with it. Regards, Dave > On Oct 27, 2017, at 1:22 PM, Matthias Seidel <matthias.sei...@hamburg.de> > wrote: > > 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> >>> <mailto: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 >>> <mailto:dev-unsubscr...@openoffice.apache.org> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> <mailto:dev-h...@openoffice.apache.org> >>> >
signature.asc
Description: Message signed with OpenPGP
