Apply these commits to 4.1.x and you'll be able to build AOO with Java 8: 1697228 1697237 1697247 1697306 1697312
I don't know why they haven't been backported yet. Damjan On Fri, Oct 27, 2017 at 10:31 PM, Dave Fisher <dave2w...@comcast.net> wrote: > 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> > <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 > > > >
