SDBC developments and the JDBC driver port

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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 (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SDBC developments and the JDBC driver port

Peter Kovacs-3
In reply to this post by Damjan Jovanovic
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SDBC developments and the JDBC driver port

Marcus (OOo)
In reply to this post by Matthias Seidel
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SDBC developments and the JDBC driver port

Matthias Seidel
In reply to this post by Dave Fisher
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 [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]


    


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]


    



signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

[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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]> <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Patricia Shanahan
In reply to this post by Dave Fisher
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]> <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Andrea Pescetti-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Dave Fisher

> On Oct 28, 2017, at 9:10 AM, Andrea Pescetti <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andrea Pescetti-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Peter Kovacs-3
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 <[hidden email]>:

>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: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]