Hi Damjan, A friend is sending me a JDK7.
But I agree. I think that these changes should be backported to 4.1.5. The redland and raptor updates should be backported too. RMs Jim / Matthias - what do you think? Regards, Dave Sent from my iPhone > On Oct 27, 2017, at 7:07 PM, Damjan Jovanovic <dam...@apache.org> wrote: > > 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 >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
