Am 28.10.2017 um 04:17 schrieb Dave Fisher: > 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?
Don't ask me, I only provided the Windows builds... ;-) I am now concentrating on 4.2.0 (trunk). Regards, Matthias > > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
