Re: [4.1.5] Re: SDBC developments and the JDBC driver port

[Peter kovacs]

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 :
>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-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

Re: [4.1.5] Re: SDBC developments and the JDBC driver port

[Andrea Pescetti]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [4.1.5] Re: SDBC developments and the JDBC driver port

[Dave Fisher]

> On Oct 28, 2017, at 9:10 AM, Andrea Pescetti  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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

Re: [4.1.5] Re: SDBC developments and the JDBC driver port

[Andrea Pescetti]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [4.1.5] Re: SDBC developments and the JDBC driver port

[Patricia Shanahan]

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  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  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 
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  
 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 

Re: [4.1.5] Re: SDBC developments and the JDBC driver port

[Matthias Seidel]

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  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  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 
>>> 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  
>>>  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)
>>> |  | |

[4.1.5] Re: SDBC developments and the JDBC driver port

[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?

Regards,
Dave

Sent from my iPhone

> On Oct 27, 2017, at 7:07 PM, Damjan Jovanovic  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  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 
>> 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  
>>  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)

Re: SDBC developments and the JDBC driver port

[Damjan Jovanovic]

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  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 
> 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  
>  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 

Re: SDBC developments and the JDBC driver port

[Dave Fisher]

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  
> 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  
>>>  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 

Re: SDBC developments and the JDBC driver port

[Matthias Seidel]

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  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
>>
>> 

Re: SDBC developments and the JDBC driver port

[Marcus]

Am 27.10.2017 um 20:44 schrieb Matthias Seidel:

Am 27.10.2017 um 11:18 schrieb Damjan Jovanovic:


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).

...


That sounds great! But I understand only a fraction of it... ;-)

Keep up the good work!


this is also my obstacle.

I don't know what this all means. So, I'm mostly silent when it comes to 
such mails. Please forbear with the non-coders. ;-)


But it feels really good when we can see work in the code that is more 
than a little fix.


Therefore thanks a lot for your efforts. :-)
And keep up the great work even when you don't get the feedbak or 
answers that you would expect - or when it takes some time.


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: SDBC developments and the JDBC driver port

[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 …

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  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
> 



signature.asc
Description: Message signed with OpenPGP

Re: SDBC developments and the JDBC driver port

[Peter Kovacs]

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

Re: SDBC developments and the JDBC driver port

[Matthias Seidel]

Hi Damjan,

Am 27.10.2017 um 11:18 schrieb Damjan Jovanovic:
> Hi
>
> 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).
>
> ...

That sounds great! But I understand only a fraction of it... ;-)

Keep up the good work!

Regards, Matthias

>
> Damjan
>




smime.p7s
Description: S/MIME Cryptographic Signature

SDBC developments and the JDBC driver port

[Damjan Jovanovic]

Hi

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.

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

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?

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?

Damjan