You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Dave Fisher <da...@comcast.net> on 2017/10/28 02:17:31 UTC
[4.1.5] Re: SDBC developments and the JDBC driver port
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 <da...@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 <da...@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 <ma...@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [4.1.5] Re: SDBC developments and the JDBC driver port
Posted by Peter kovacs <pe...@apache.org>.
Currently our release performance says that we need 1 year for a release.
So far we have more issues with the release process then with the development new feature process.
The whish to release 4.2.0 at end of this year is for our team super challenging.
So I think we should take this challenge rather then try to boat 2 releases.
If we get stuck for 4.2.0 for technical reasons or security reasons we can swap strategies. That's why we leave the prepared 4.1.5 trunk.
So far my understanding of our current strategy. I think going for 4.1.5 is the conservative way. And another bugfix release has little support, right?
Let's do this people. Go-Go for the 4.2.0 round :-D
Am 28. Oktober 2017 22:18:20 MESZ schrieb Andrea Pescetti <pe...@apache.org>:
>Dave Fisher wrote:
>> BTW - Damjan’s changes are javadoc related and absolutely needed on
>modern Macs where getting JDK7 is not easy. We cannot be so
>conservative that we are afraid of upgrades.
>
>Yes we can. And not only we can, but we should (a personal opinion of
>course).
>
>It must be clear to everybody that trunk is the only place where
>development is active. There it is important to try to support modern
>systems as much as we can. But not on 4.1.x.
>
>4.1.x is frozen (and possibly even stopped). If we ever have to release
>
>something from 4.1.x again, we must strive to build it on the same VMs
>used for 4.1.4 and the same configuration; this is our best guarantee
>against regressions, and the proof is in the many 4.1.4-RCx.
>
>Regards,
> Andrea.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [4.1.5] Re: SDBC developments and the JDBC driver port
Posted by Andrea Pescetti <pe...@apache.org>.
Dave Fisher wrote:
> BTW - Damjan’s changes are javadoc related and absolutely needed on modern Macs where getting JDK7 is not easy. We cannot be so conservative that we are afraid of upgrades.
Yes we can. And not only we can, but we should (a personal opinion of
course).
It must be clear to everybody that trunk is the only place where
development is active. There it is important to try to support modern
systems as much as we can. But not on 4.1.x.
4.1.x is frozen (and possibly even stopped). If we ever have to release
something from 4.1.x again, we must strive to build it on the same VMs
used for 4.1.4 and the same configuration; this is our best guarantee
against regressions, and the proof is in the many 4.1.4-RCx.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [4.1.5] Re: SDBC developments and the JDBC driver port
Posted by Dave Fisher <da...@comcast.net>.
> On Oct 28, 2017, at 9:10 AM, Andrea Pescetti <pe...@apache.org> wrote:
>
> Patricia Shanahan wrote:
>> Unless the changes are also in 4.1.4 or are super-urgent, I do not think
>> they belong in 4.1.5. 4.1.5, which we hope will never be released, is
>> for fixes to 4.1.4 that are too urgent to wait for 4.2.
>
> Confirmed. 4.2 should get all the focus. Nothing gets in AOO415 (which is a branch, not a planned release at the moment) besides what we want to fix. All the rest in AOO415 remains unchanged with respect to AOO414: any improvements can have side effects, as we have seen in the numerous RCs for 4.1.4.
What are we planning regarding a fix for the MacOSX regression? (Or will we wait for the solution and then discuss?)
My thought is that we may want to be ready to release a 4.1.5 for Mac only.
BTW - Damjan’s changes are javadoc related and absolutely needed on modern Macs where getting JDK7 is not easy. We cannot be so conservative that we are afraid of upgrades.
Regards,
Dave
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: [4.1.5] Re: SDBC developments and the JDBC driver port
Posted by Andrea Pescetti <pe...@apache.org>.
Patricia Shanahan wrote:
> Unless the changes are also in 4.1.4 or are super-urgent, I do not think
> they belong in 4.1.5. 4.1.5, which we hope will never be released, is
> for fixes to 4.1.4 that are too urgent to wait for 4.2.
Confirmed. 4.2 should get all the focus. Nothing gets in AOO415 (which
is a branch, not a planned release at the moment) besides what we want
to fix. All the rest in AOO415 remains unchanged with respect to AOO414:
any improvements can have side effects, as we have seen in the numerous
RCs for 4.1.4.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [4.1.5] Re: SDBC developments and the JDBC driver port
Posted by Patricia Shanahan <pa...@acm.org>.
Unless the changes are also in 4.1.4 or are super-urgent, I do not think
they belong in 4.1.5. 4.1.5, which we hope will never be released, is
for fixes to 4.1.4 that are too urgent to wait for 4.2.
On 10/27/2017 7:17 PM, Dave Fisher wrote:
> 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 <da...@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 <da...@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 <ma...@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-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [4.1.5] Re: SDBC developments and the JDBC driver port
Posted by Matthias Seidel <ma...@hamburg.de>.
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 <da...@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 <da...@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 <ma...@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-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>