openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: SDBC developments and the JDBC driver port
Date Sat, 28 Oct 2017 02:07:18 GMT
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 <dave2wave@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.seidel@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 <petko@apache.org> <petko@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message