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
