Thread: RFC: Make new versions of pgjdbc Java8+
Hi.
Following-up on my previous own comments on this thread:
https://www.postgresql.org/message-id/47f0171d-6d34-fc12-2849-fd157d69925b%408kdata.com,
I want to raise this question independently.
Let me bring these facts to the table:
- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
- By July 2016, Java 6 usage was less than 10% and declining
significantly, while 8 raising, according to
https://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016-trends/
- Companies are version conservative, but don't want to run on EOLed
products (that's even worse).
- Java 8 may attract more development power to the driver (nobody likes
working without lambdas, streams, etc, when they are available!).
- There are fully featured versions of pgjdbc (up to and including 42)
that are JDK6-compatible, and will remain there.
What would be the reasons *not to* make *future* versions of pgjdbc
Java8+? If fixes/security patches would be backported to some Java6+
releases (like v42), I don't actually see any.
Thoughts?
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote: > - Java 6 EOLed 2/2013. > - Java 7 EOLed 4/2015. > - Java 8 was released 3 years ago, and brought significant improvements. > - Java 9 will be (may be) released this year. isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land. -- john r pierce, recycling bits in santa cruz
On 03/04/17 00:56, John R Pierce wrote:
> On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:
>> - Java 6 EOLed 2/2013.
>> - Java 7 EOLed 4/2015.
>> - Java 8 was released 3 years ago, and brought significant improvements.
>> - Java 9 will be (may be) released this year.
>
> isn't there a significant lag in version support by things like web
> services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee
> 8 isn't even out yet. Pretty sure a whole lot of that space is still
> stuck back in Java 6 land.
>
>
Those are not related things. You can perfectly run J2EE 6 servers
with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
On 04/02/2017 06:03 PM, Álvaro Hernández Tortosa wrote: > Those are not related things. You can perfectly run J2EE 6 servers > with Java 8 (and indeed, it is beneficial). Since 2006, there is no such thing as "J2EE", it's "Java EE". http://www.oracle.com/technetwork/java/javase/overview/javanaming-2227065.html -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe."
On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>dataAlvaro,So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data
On 03/04/17 13:05, Dave Cramer wrote:On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>dataAlvaro,So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>data
On 3 April 2017 at 07:36, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:In the interest of expediency using J8+ is acceptable for the first cut. However. I just checked maven stats for oss.sonatype.org and while j6 is not getting a lot of downloads, j7 is certainly significant.On 03/04/17 13:05, Dave Cramer wrote:On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>dataAlvaro,So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>data
I guess you mean statistics for pgjdbc, right?
I'm sure there may be out there still some number of Java7s. However, my point is: those can still use any pgjdbc driver at least up to v42. And they are mature, performant, fully featured drivers, not a half-backed piece of software that you will be striving to upgrade. So even if Java7s are still there, they could be well served. But newer versions could be developed for Java8+ and encourage users to upgrade to a non-EOLed Java platform, and probably as a side-effect get better performance.
We're not talking about past, but just future developments ;)
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data
I guess you mean statistics for pgjdbc, right?]On 03/04/17 15:57, Dave Cramer wrote:On 3 April 2017 at 07:36, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:In the interest of expediency using J8+ is acceptable for the first cut. However. I just checked maven stats for oss.sonatype.org and while j6 is not getting a lot of downloads, j7 is certainly significant.On 03/04/17 13:05, Dave Cramer wrote:On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>dataAlvaro,So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>data
I'm sure there may be out there still some number of Java7s. However, my point is: those can still use any pgjdbc driver at least up to v42. And they are mature, performant, fully featured drivers, not a half-backed piece of software that you will be striving to upgrade. So even if Java7s are still there, they could be well served. But newer versions could be developed for Java8+ and encourage users to upgrade to a non-EOLed Java platform, and probably as a side-effect get better performance.
On 3 April 2017 at 10:05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:I guess you mean statistics for pgjdbc, right?]On 03/04/17 15:57, Dave Cramer wrote:On 3 April 2017 at 07:36, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:In the interest of expediency using J8+ is acceptable for the first cut. However. I just checked maven stats for oss.sonatype.org and while j6 is not getting a lot of downloads, j7 is certainly significant.On 03/04/17 13:05, Dave Cramer wrote:On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>dataAlvaro,So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>dataYes, sorry for the lack of clarity
I'm sure there may be out there still some number of Java7s. However, my point is: those can still use any pgjdbc driver at least up to v42. And they are mature, performant, fully featured drivers, not a half-backed piece of software that you will be striving to upgrade. So even if Java7s are still there, they could be well served. But newer versions could be developed for Java8+ and encourage users to upgrade to a non-EOLed Java platform, and probably as a side-effect get better performance.OK, but the scenario where people are using the latest version of Postgres with SCRAM and still using older versions of java is what I am thinking about. I wonder if SCRAM will get backpatched ?
If developed for Java8+, it won't (at least, I won't do it).
However, I wonder if it would be such a big deal for people that are upgrading to Postgres 10 and require SCRAM not to ask them to upgrade their JVM to a non EOLed version. I think the intersection of people who go for very modern PG and non supported Java if almost 0.
Regards,
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data
On 2017-04-03 13:36, Álvaro Hernández Tortosa wrote: > On 03/04/17 13:05, Dave Cramer wrote: > Alvaro, > >> So why do you want to write in java 8 ? > > Not a comprehensive or ordered list, but a few reasons: > > - JDK comes with Base64 and cryptographic functions like PBKDF2 that > are needed for SCRAM. In Java6 you either implement yourself or pull > external dependencies. Base64 can also be done using javax.xml.bind.DatatypeConverter (although that might be a dependency you don't want given it is not in the default modules of Java 9 and is slated for removal in Java 10(?)), and otherwise implementing base 64 encoding or decoding is not rocket science. PBKDF2 has been in Java for awhile (see http://docs.oracle.com/javase/6/docs/technotes/guides/security/StandardNames.html, search for PBKDF2WithHmacSHA1) Mark
- The PgJDBC project is ultra-conservative, there is still support for PostgreSQL 8.2 which the EOL was on Dec 2011, I think that up to 8.4 would make sense and even a more radical approach to follow the EOL of the server itself (drop support for Pg9.1 and lower) it's for me acceptable, most people that use ancient PostgreSQL versions uses ancient driver versions, and it's not common to update the driver for those versions anyway.
- The limited resources/voluntary work, makes hard to have support for many branches, so the "dead" of a version means no fixes/backports to that version anymore, it's a linear development where there is no look back, if Java 6 and/or Java 7 is dropped, it means the last version that supported them are "frozen" and any potential bug will be there forever.
- The End of Public Updates of Oracle JDK 6 was on Feb 2013, but there is an "premier" and "extended" support (paid of course) where the "extended" ends on Dec 2018.
- If you ask me, we should stick to the "premier" support dates for the PgJDBC, so basically Java 6 should have died in Dec 2015.
- Following the "premier" support, Java 7 should be dropped until Jul 2019.
- The Oracle JDK it's not the only JDK so the End of Public Updates from Oracle should not dictate the kill of a Java version, there is OpenJDK.
- The OpenJDK/IcedTea team, drop support for Java 6 just recently.
- The Azul Zulu team still supports Java 6 (at least I haven't hear the drop of support).
So +1 for drop support for Java 6, and -1 for drop support for Java 7.
And BTW, a drop of a Java version should increase the major version of the driver, so when that happens it should be called 43.0.0
On 03/04/17 17:28, Mark Rotteveel wrote:
> On 2017-04-03 13:36, Álvaro Hernández Tortosa wrote:
>> On 03/04/17 13:05, Dave Cramer wrote:
>> Alvaro,
>>
>>> So why do you want to write in java 8 ?
>>
>> Not a comprehensive or ordered list, but a few reasons:
>>
>> - JDK comes with Base64 and cryptographic functions like PBKDF2 that
>> are needed for SCRAM. In Java6 you either implement yourself or pull
>> external dependencies.
>
> Base64 can also be done using javax.xml.bind.DatatypeConverter
> (although that might be a dependency you don't want given it is not in
> the default modules of Java 9 and is slated for removal in Java 10(?)),
Exactly that's the point. Either I use a dependency now
(commons-codec) of I use DatatypeConverter, which will become
effectively a dependency with Java 9+.
> and otherwise implementing base 64 encoding or decoding is not rocket
> science.
That would be IMVHO, a waste of developer bandwidth. Re-inventing
the wheel is something I won't be doing at all.
> PBKDF2 has been in Java for awhile (see
> http://docs.oracle.com/javase/6/docs/technotes/guides/security/StandardNames.html,
> search for PBKDF2WithHmacSHA1)
Exception in thread "main" java.security.NoSuchAlgorithmException:
PBKDF2WithHmacSHA256 SecretKeyFactory not available
It is available for SHA1, but not SHA256 (which is the one used by
Postgres).
So it has to be coded by hand if using Java6.
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
+1 for 8.4+I strongly support the drop of old Java versions, and I'm one that thinks we should use the latest and greatest version of Java :-) but, for much I want to that happen it's hard to simply "drop" 2 Java version at once.[...]Now let's get some facts:
- The PgJDBC project is ultra-conservative, there is still support for PostgreSQL 8.2 which the EOL was on Dec 2011, I think that up to 8.4 would make sense and even a more radical approach to follow the EOL of the server itself (drop support for Pg9.1 and lower) it's for me acceptable, most people that use ancient PostgreSQL versions uses ancient driver versions, and it's not common to update the driver for those versions anyway.
- The limited resources/voluntary work, makes hard to have support for many branches, so the "dead" of a version means no fixes/backports to that version anymore, it's a linear development where there is no look back, if Java 6 and/or Java 7 is dropped, it means the last version that supported them are "frozen" and any potential bug will be there forever.
Agreed. Also in this line: Java8 may encourage more developers to join. Few developers I know would volunteer to contribute code without being able to use Java8. YMMV.
- The End of Public Updates of Oracle JDK 6 was on Feb 2013, but there is an "premier" and "extended" support (paid of course) where the "extended" ends on Dec 2018.
- If you ask me, we should stick to the "premier" support dates for the PgJDBC, so basically Java 6 should have died in Dec 2015.
- Following the "premier" support, Java 7 should be dropped until Jul 2019.
So.... we are going to be favoring customers paying extra premium fees to Oracle.... don't count with me! ^_^
I don't agree. For me EOL is EOL, not premier.
- The Oracle JDK it's not the only JDK so the End of Public Updates from Oracle should not dictate the kill of a Java version, there is OpenJDK.
- The OpenJDK/IcedTea team, drop support for Java 6 just recently.
Fair enough. But as a simple example, neither openjdk6 nor openjdk7 are available in my Ubuntu distro (16.04, not even bleeding edge).
- The Azul Zulu team still supports Java 6 (at least I haven't hear the drop of support).
So +1 for drop support for Java 6, and -1 for drop support for Java 7.
Still unconvinced of a strong reason to keep support for Java 7. My +1 for Java8+.
And BTW, a drop of a Java version should increase the major version of the driver, so when that happens it should be called 43.0.0
Absolutely necessary :)
Cheers,
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data
On 03/04/17 18:32, Jorge Solórzano wrote:The End of Public Updates of Oracle JDK 6 was on Feb 2013, but there is an "premier" and "extended" support (paid of course) where the "extended" ends on Dec 2018.So.... we are going to be favoring customers paying extra premium fees to Oracle.... don't count with me! ^_^
- If you ask me, we should stick to the "premier" support dates for the PgJDBC, so basically Java 6 should have died in Dec 2015.
- Following the "premier" support, Java 7 should be dropped until Jul 2019.
I don't agree. For me EOL is EOL, not premier.
- The Oracle JDK it's not the only JDK so the End of Public Updates from Oracle should not dictate the kill of a Java version, there is OpenJDK.
- The OpenJDK/IcedTea team, drop support for Java 6 just recently.
Fair enough. But as a simple example, neither openjdk6 nor openjdk7 are available in my Ubuntu distro (16.04, not even bleeding edge).
Still unconvinced of a strong reason to keep support for Java 7. My +1 for Java8+.
- The Azul Zulu team still supports Java 6 (at least I haven't hear the drop of support).
So +1 for drop support for Java 6, and -1 for drop support for Java 7.
Cheers,
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>data
On Mon, Apr 3, 2017 at 11:15 AM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 18:32, Jorge Solórzano wrote:The End of Public Updates of Oracle JDK 6 was on Feb 2013, but there is an "premier" and "extended" support (paid of course) where the "extended" ends on Dec 2018.So.... we are going to be favoring customers paying extra premium fees to Oracle.... don't count with me! ^_^
- If you ask me, we should stick to the "premier" support dates for the PgJDBC, so basically Java 6 should have died in Dec 2015.
- Following the "premier" support, Java 7 should be dropped until Jul 2019.
I don't agree. For me EOL is EOL, not premier.My point is not favoring customer paying extra premium fees to Oracle, is to choose "sane" dates to drop support in PgJDBC.
EOL is sane IMHO.
- The Oracle JDK it's not the only JDK so the End of Public Updates from Oracle should not dictate the kill of a Java version, there is OpenJDK.
- The OpenJDK/IcedTea team, drop support for Java 6 just recently.
Fair enough. But as a simple example, neither openjdk6 nor openjdk7 are available in my Ubuntu distro (16.04, not even bleeding edge).And that's why I use Azul Zulu JDK :-)
Still unconvinced of a strong reason to keep support for Java 7. My +1 for Java8+.
- The Azul Zulu team still supports Java 6 (at least I haven't hear the drop of support).
So +1 for drop support for Java 6, and -1 for drop support for Java 7.
Yes, there are not strong reasons to keep support for Java 7 (apart that it's still widely used), but there are not strong reasons to drop support for Java 7 neither.
The same as for dropping Java6. Out of the ones I mentioned at the beginning of this thread, Java7 improves on no one.
It looks like the java implementation mentioned scram-sasl supports Java 7,
I'm not going to use it. It has 0 tests, I don't trust it. I'm writing a new SCRAM implementation.
and BTW the Base64 class of Robert Harder is in PgJDBC, but hey if you convince the project maintainers to move to Java 8+ I'm not against it :-) as I said the project is ultra-conservative for better or worse.
The driver has done something which is really good: very wide support old versions (server, JDK, specs). I think this is not conservationism, but rather a feature: to cover such a wide spectrum. Having said that, and once that goal is fulfilled (as it is right now, with full-featured, mature and performant driver for many versions), it might be time to look into new features, such as supporting and embracing current technologies, and leveraging them for lower development cost.
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data
Hallo,
in the name of performance, and that should be the main aspect for a database driver:
· Don’t use lambdas! They are useful in a GUI where a few milliseconds are no problem, but shouldn’t IMHO be used on the server. Inner classes are slower to load but execute faster!
· Don’t use streams when you can simply iterate over an array or a list. Unnecessary object creating just for the sake of readable code? Don’t do this in a database driver either!
· Optionals: Why create objects for nothing? I’d rather have an if-check for null instead garbage on the heap.
Just my thoughts.
Regards,
Daniel Migowski
Von: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] Im Auftrag von Álvaro Hernández Tortosa
Gesendet: Montag, 3. April 2017 13:36
An: Dave Cramer <pg@fastcrypt.com>
Cc: John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Betreff: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 13:05, Dave Cramer wrote:
On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:
- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
Alvaro,
So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
On 03/04/17 19:48, Jorge Solórzano wrote:On Mon, Apr 3, 2017 at 11:15 AM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 18:32, Jorge Solórzano wrote:The End of Public Updates of Oracle JDK 6 was on Feb 2013, but there is an "premier" and "extended" support (paid of course) where the "extended" ends on Dec 2018.So.... we are going to be favoring customers paying extra premium fees to Oracle.... don't count with me! ^_^
- If you ask me, we should stick to the "premier" support dates for the PgJDBC, so basically Java 6 should have died in Dec 2015.
- Following the "premier" support, Java 7 should be dropped until Jul 2019.
I don't agree. For me EOL is EOL, not premier.My point is not favoring customer paying extra premium fees to Oracle, is to choose "sane" dates to drop support in PgJDBC.
EOL is sane IMHO.
- The Oracle JDK it's not the only JDK so the End of Public Updates from Oracle should not dictate the kill of a Java version, there is OpenJDK.
- The OpenJDK/IcedTea team, drop support for Java 6 just recently.
Fair enough. But as a simple example, neither openjdk6 nor openjdk7 are available in my Ubuntu distro (16.04, not even bleeding edge).And that's why I use Azul Zulu JDK :-)
Still unconvinced of a strong reason to keep support for Java 7. My +1 for Java8+.
- The Azul Zulu team still supports Java 6 (at least I haven't hear the drop of support).
So +1 for drop support for Java 6, and -1 for drop support for Java 7.
Yes, there are not strong reasons to keep support for Java 7 (apart that it's still widely used), but there are not strong reasons to drop support for Java 7 neither.
The same as for dropping Java6. Out of the ones I mentioned at the beginning of this thread, Java7 improves on no one.It looks like the java implementation mentioned scram-sasl supports Java 7,
I'm not going to use it. It has 0 tests, I don't trust it. I'm writing a new SCRAM implementation.and BTW the Base64 class of Robert Harder is in PgJDBC, but hey if you convince the project maintainers to move to Java 8+ I'm not against it :-) as I said the project is ultra-conservative for better or worse.
The driver has done something which is really good: very wide support old versions (server, JDK, specs). I think this is not conservationism, but rather a feature: to cover such a wide spectrum. Having said that, and once that goal is fulfilled (as it is right now, with full-featured, mature and performant driver for many versions), it might be time to look into new features, such as supporting and embracing current technologies, and leveraging them for lower development cost.
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>data
Hallo,
in the name of performance, and that should be the main aspect for a database driver:
· Don’t use lambdas! They are useful in a GUI where a few milliseconds are no problem, but shouldn’t IMHO be used on the server. Inner classes are slower to load but execute faster!
· Don’t use streams when you can simply iterate over an array or a list. Unnecessary object creating just for the sake of readable code? Don’t do this in a database driver either!
· Optionals: Why create objects for nothing? I’d rather have an if-check for null instead garbage on the heap.
Thank you for your thoughts.
I have heard these objections sometimes. I more or less agree with some of them. But don't want to fall into premature optimization: do you have some numbers to back these claims? If there would be performance drawbacks for using these, are they comparable to other performance hits in the driver?
Regards,
Álvaro
Just my thoughts.
Regards,
Daniel Migowski
Von: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] Im Auftrag von Álvaro Hernández Tortosa
Gesendet: Montag, 3. April 2017 13:36
An: Dave Cramer <pg@fastcrypt.com>
Cc: John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Betreff: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 13:05, Dave Cramer wrote:
On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:
- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
Alvaro,
So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro--Álvaro Hernández Tortosa-----------<8K>data
-- Álvaro Hernández Tortosa ----------- <8K>data
Hello Alvaro,
while the biggest performance hit currently in the driver is the switch to java.util.Logging (i will come up with numbers regarding that in a few days, comparing it to previous versions). Currently, and comparing to the 9.3 driver with the current driver, the Hibernate databases checks take twice the time than before! Even if some parts have improved (see changes in PGStream and VisibleBufferedInputStream, nice reuse of arrays there since 9.3) other things have changed to the bad.
I also already did my tests regarding the stuff below, and concluded that in our company lambda’s are useful in the GUI, but as I said shouldn’t be used on the server. In my tests they were about 50% percent slower in the long run.
Streams are the same thing… just look at the stack traces! Good for rarely used stuff, but honestly I prefer a nice loop where you see what is happening in terms of object creation over streams that might be concise, but are not needed. At least not for something you call potentially 100ths of times a second.
I like the switch to Java 8 to be able to use java build-in code vs. using external dependencies, so my upvote here. But please don’t start changing anything to Java 8 syntactic sugar if it even creates a single object more.
Regards,
Daniel Migowski
Von: Álvaro Hernández Tortosa [mailto:aht@8kdata.com]
Gesendet: Montag, 3. April 2017 20:33
An: Daniel Migowski <dmigowski@ikoffice.de>; Dave Cramer <pg@fastcrypt.com>
Cc: John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Betreff: Re: AW: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 20:24, Daniel Migowski wrote:
Hallo,
in the name of performance, and that should be the main aspect for a database driver:
· Don’t use lambdas! They are useful in a GUI where a few milliseconds are no problem, but shouldn’t IMHO be used on the server. Inner classes are slower to load but execute faster!
· Don’t use streams when you can simply iterate over an array or a list. Unnecessary object creating just for the sake of readable code? Don’t do this in a database driver either!
· Optionals: Why create objects for nothing? I’d rather have an if-check for null instead garbage on the heap.
Thank you for your thoughts.
I have heard these objections sometimes. I more or less agree with some of them. But don't want to fall into premature optimization: do you have some numbers to back these claims? If there would be performance drawbacks for using these, are they comparable to other performance hits in the driver?
Regards,
Álvaro
Just my thoughts.
Regards,
Daniel Migowski
Von: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] Im Auftrag von Álvaro Hernández Tortosa
Gesendet: Montag, 3. April 2017 13:36
An: Dave Cramer <pg@fastcrypt.com>
Cc: John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Betreff: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 13:05, Dave Cramer wrote:
On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:
- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
Alvaro,
So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro--Álvaro Hernández Tortosa-----------<8K>data
--
Álvaro Hernández Tortosa
-----------
<8K>data
On 03/04/17 20:24, Daniel Migowski wrote:Hallo,
in the name of performance, and that should be the main aspect for a database driver:
· Don’t use lambdas! They are useful in a GUI where a few milliseconds are no problem, but shouldn’t IMHO be used on the server. Inner classes are slower to load but execute faster!
· Don’t use streams when you can simply iterate over an array or a list. Unnecessary object creating just for the sake of readable code? Don’t do this in a database driver either!
· Optionals: Why create objects for nothing? I’d rather have an if-check for null instead garbage on the heap.
Thank you for your thoughts.
I have heard these objections sometimes. I more or less agree with some of them. But don't want to fall into premature optimization: do you have some numbers to back these claims? If there would be performance drawbacks for using these, are they comparable to other performance hits in the driver?
Regards,
Álvaro
Just my thoughts.
Regards,
Daniel Migowski
Von: pgsql-jdbc-owner@postgresql.
org [mailto:pgsql-jdbc-owner@ postgresql.org] Im Auftrag von Álvaro Hernández Tortosa
Gesendet: Montag, 3. April 2017 13:36
An: Dave Cramer <pg@fastcrypt.com>
Cc: John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Betreff: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 13:05, Dave Cramer wrote:
On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:
- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
Alvaro,
So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro--Álvaro Hernández Tortosa-----------<8K>data-- Álvaro Hernández Tortosa ----------- <8K>data
postgresql-42.0.0.jre7.jar: 7837
postgresql-42.0.0.jre6.jar: 16587
postgresql-9.4.1212.jar: 78122
postgresql-9.4.1212.jre7.jar: 71585
postgresql-9.4.1212.jre6.jar: 34292
postgresql-9.4.1211.jar: 17128
postgresql-9.4.1211.jre7.jar: 805
postgresql-9.4.1211.jre6.jar: 2315
postgresql-9.4.1210.jar: 11435
postgresql-9.4.1210.jre7.jar: 363
postgresql-9.4.1210.jre6.jar: 680
postgresql-9.4.1209.jar: 18020
postgresql-9.4.1209.jre7.jar: 881
postgresql-9.4.1209.jre6.jar: 1210
postgresql-9.4.1208.jar: 6886
postgresql-9.4.1208.jre7.jar: 100792
postgresql-9.4.1208.jre6.jar: 4793
Hello Alvaro,
while the biggest performance hit currently in the driver is the switch to java.util.Logging (i will come up with numbers regarding that in a few days, comparing it to previous versions). Currently, and comparing to the 9.3 driver with the current driver, the Hibernate databases checks take twice the time than before! Even if some parts have improved (see changes in PGStream and VisibleBufferedInputStream, nice reuse of arrays there since 9.3) other things have changed to the bad.
I also already did my tests regarding the stuff below, and concluded that in our company lambda’s are useful in the GUI, but as I said shouldn’t be used on the server. In my tests they were about 50% percent slower in the long run.
Streams are the same thing… just look at the stack traces! Good for rarely used stuff, but honestly I prefer a nice loop where you see what is happening in terms of object creation over streams that might be concise, but are not needed. At least not for something you call potentially 100ths of times a second.
While I agree Lambdas and Streams should be used with care, I'm still unconvinced that they really take a hit in performance (if the compiler is not optimizing that, which most of the time does). I would really love to see some numbers to prove my wrong in this respect. But I don't see much trends towards not using them in the Java world (but the contrary) and I talk to very performance conscious people.
I like the switch to Java 8 to be able to use java build-in code vs. using external dependencies, so my upvote here. But please don’t start changing anything to Java 8 syntactic sugar if it even creates a single object more.
Object creation worries me, for example, when serializing and deserializing data. That's what the real returns are in optimization. Tiny object creation in non-repeated places is of no importance to me.
Cheers,
Álvaro
Regards,
Daniel Migowski
Von: Álvaro Hernández Tortosa [mailto:aht@8kdata.com]
Gesendet: Montag, 3. April 2017 20:33
An: Daniel Migowski <dmigowski@ikoffice.de>; Dave Cramer <pg@fastcrypt.com>
Cc: John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Betreff: Re: AW: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 20:24, Daniel Migowski wrote:
Hallo,
in the name of performance, and that should be the main aspect for a database driver:
· Don’t use lambdas! They are useful in a GUI where a few milliseconds are no problem, but shouldn’t IMHO be used on the server. Inner classes are slower to load but execute faster!
· Don’t use streams when you can simply iterate over an array or a list. Unnecessary object creating just for the sake of readable code? Don’t do this in a database driver either!
· Optionals: Why create objects for nothing? I’d rather have an if-check for null instead garbage on the heap.
Thank you for your thoughts.
I have heard these objections sometimes. I more or less agree with some of them. But don't want to fall into premature optimization: do you have some numbers to back these claims? If there would be performance drawbacks for using these, are they comparable to other performance hits in the driver?
Regards,
Álvaro
Just my thoughts.
Regards,
Daniel Migowski
Von: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] Im Auftrag von Álvaro Hernández Tortosa
Gesendet: Montag, 3. April 2017 13:36
An: Dave Cramer <pg@fastcrypt.com>
Cc: John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Betreff: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 13:05, Dave Cramer wrote:
On 2 April 2017 at 19:03, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
On 03/04/17 00:56, John R Pierce wrote:On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:
- Java 6 EOLed 2/2013.
- Java 7 EOLed 4/2015.
- Java 8 was released 3 years ago, and brought significant improvements.
- Java 9 will be (may be) released this year.
isn't there a significant lag in version support by things like web services (j2ee, etc, as embedded in things like IBM WebSphere) ? j2ee 8 isn't even out yet. Pretty sure a whole lot of that space is still stuck back in Java 6 land.
Those are not related things. You can perfectly run J2EE 6 servers with Java 8 (and indeed, it is beneficial).
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
Alvaro,
So why do you want to write in java 8 ?
Not a comprehensive or ordered list, but a few reasons:
- JDK comes with Base64 and cryptographic functions like PBKDF2 that are needed for SCRAM. In Java6 you either implement yourself or pull external dependencies.
- You can write conciser code (which improves significantly readability):
* Lambas: anonymous classes. Callback-heavy code turns becomes readable.
* Streams: unnecessary for loops and other goodies.
* Optional: unnecessary ifs.
* Since Java7: try-with-resources, 10_000 vs 10000 etc.
- Reading Javadoc doesn't hurt my eyes ^_^
- Time API, CompletableFuture.
- Default and static methods in interfaces!
Álvaro--Álvaro Hernández Tortosa-----------<8K>data
--Álvaro Hernández Tortosa-----------<8K>data
-- Álvaro Hernández Tortosa ----------- <8K>data
Dave,
* Dave Cramer (pg@fastcrypt.com) wrote:
> On 3 April 2017 at 14:33, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> Quick eyeball of the latest two versions shows significant download of
> jre6, and a scary data of 1208 jre7. I wonder what project is using that?
Chef.
All but ~4000 of those hits were by either "Chef Client" or "Chef
Knife", most of which were, unsurprisingly, just 304's ("not modified").
There were 241 actual downloads, all from Chef Client or Chef Knife
again and from just as recent as a few days ago.
That was from 93 distinct IPs.
Thanks!
Stephen
Attachment
Hi everyone.
On 2017-04-03 21:58, Stephen Frost wrote:
> Dave,
>
> * Dave Cramer (pg@fastcrypt.com) wrote:
>> On 3 April 2017 at 14:33, Álvaro Hernández Tortosa <aht@8kdata.com>
>> wrote:
>> Quick eyeball of the latest two versions shows significant download of
>> jre6, and a scary data of 1208 jre7. I wonder what project is using
>> that?
>
> Chef.
>
> All but ~4000 of those hits were by either "Chef Client" or "Chef
> Knife", most of which were, unsurprisingly, just 304's ("not
> modified").
From 100 000 downloads?
This link shows which other POMs are referring to 9.4.1208.jre7:
http://mvnrepository.com/artifact/org.postgresql/postgresql/9.4.1208.jre7/usages
Keep in mind that I don't know how reliable is this data, but Clojure
and Spring Boot are quite popular projects.
> There were 241 actual downloads, all from Chef Client or Chef Knife
> again and from just as recent as a few days ago.
>
> That was from 93 distinct IPs.
>
> Thanks!
>
> Stephen
Hello Alvaro, On 2017-04-03 21:53, Álvaro Hernández Tortosa wrote: > On 03/04/17 20:47, Daniel Migowski wrote: > >> Hello Alvaro, >> >> while the biggest performance hit currently in the driver is the >> switch to java.util.Logging (i will come up with numbers regarding >> that in a few days, comparing it to previous versions). Currently, >> and comparing to the 9.3 driver with the current driver, the >> Hibernate databases checks take twice the time than before! Even if >> some parts have improved (see changes in PGStream and >> VisibleBufferedInputStream, nice reuse of arrays there since 9.3) >> other things have changed to the bad. >> >> I also already did my tests regarding the stuff below, and concluded >> that in our company lambda’s are useful in the GUI, but as I said >> shouldn’t be used on the server. In my tests they were about 50% >> percent slower in the long run. >> >> Streams are the same thing… just look at the stack traces! Good >> for rarely used stuff, but honestly I prefer a nice loop where you >> see what is happening in terms of object creation over streams that >> might be concise, but are not needed. At least not for something you >> call potentially 100ths of times a second. > > While I agree Lambdas and Streams should be used with care, I'm > still unconvinced that they really take a hit in performance (if the > compiler is not optimizing that, which most of the time does). I would > really love to see some numbers to prove my wrong in this respect. But > I don't see much trends towards not using them in the Java world (but > the contrary) and I talk to very performance conscious people. I've remembered about this writing: http://blog.takipi.com/benchmark-how-java-8-lambdas-and-streams-can-make-your-code-5-times-slower/ They have the code available, I haven't verified it personally. Also it is possible the outcome to be different with the newer releases of the JDK. Please note the difference between the original results and the updated ones. The base line is: you have to be extra careful with the streams, autoboxing and to avoid using lamdas in "hot" places. At least for the tested use case - "sorting ArrayList populated with 100 000 random integers". >> I like the switch to Java 8 to be able to use java build-in code vs. >> using external dependencies, so my upvote here. But please don’t >> start changing anything to Java 8 syntactic sugar if it even creates >> a single object more. > > Object creation worries me, for example, when serializing and > deserializing data. That's what the real returns are in optimization. > Tiny object creation in non-repeated places is of no importance to me. > > Cheers, > > Álvaro > >> Regards, >> >> Daniel Migowski >> >> VON: Álvaro Hernández Tortosa [mailto:aht@8kdata.com] >> GESENDET: Montag, 3. April 2017 20:33 >> AN: Daniel Migowski <dmigowski@ikoffice.de>; Dave Cramer >> <pg@fastcrypt.com> >> CC: John R Pierce <pierce@hogranch.com>; List >> <pgsql-jdbc@postgresql.org> >> BETREFF: Re: AW: [JDBC] RFC: Make new versions of pgjdbc Java8+ >> >> On 03/04/17 20:24, Daniel Migowski wrote: >> >>> Hallo, >>> >>> in the name of performance, and that should be the main aspect for >>> a database driver: >>> >>> · Don’t use lambdas! They are useful in a GUI where a >>> few milliseconds are no problem, but shouldn’t IMHO be used on >>> the server. Inner classes are slower to load but execute faster! >>> >>> · Don’t use streams when you can simply iterate over an >>> array or a list. Unnecessary object creating just for the sake of >>> readable code? Don’t do this in a database driver either! >>> >>> · Optionals: Why create objects for nothing? I’d rather >>> have an if-check for null instead garbage on the heap. >> >> Thank you for your thoughts. >> >> I have heard these objections sometimes. I more or less agree >> with some of them. But don't want to fall into premature >> optimization: do you have some numbers to back these claims? If >> there would be performance drawbacks for using these, are they >> comparable to other performance hits in the driver? >> >> Regards, >> >> Álvaro >> >> Just my thoughts. >> >> Regards, >> >> Daniel Migowski >> >> VON: pgsql-jdbc-owner@postgresql.org >> [mailto:pgsql-jdbc-owner@postgresql.org] IM AUFTRAG VON Álvaro >> Hernández Tortosa >> GESENDET: Montag, 3. April 2017 13:36 >> AN: Dave Cramer <pg@fastcrypt.com> >> CC: John R Pierce <pierce@hogranch.com>; List >> <pgsql-jdbc@postgresql.org> >> BETREFF: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+ >> >> On 03/04/17 13:05, Dave Cramer wrote: >> >> On 2 April 2017 at 19:03, Álvaro Hernández Tortosa >> <aht@8kdata.com> wrote: >> >> On 03/04/17 00:56, John R Pierce wrote: >> >> On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote: >> >> - Java 6 EOLed 2/2013. >> - Java 7 EOLed 4/2015. >> - Java 8 was released 3 years ago, and brought significant >> improvements. >> - Java 9 will be (may be) released this year. >> >> isn't there a significant lag in version support by things like web >> services (j2ee, etc, as embedded in things like IBM WebSphere) ? >> j2ee 8 isn't even out yet. Pretty sure a whole lot of that space >> is still stuck back in Java 6 land. > > Those are not related things. You can perfectly run J2EE 6 servers > with Java 8 (and indeed, it is beneficial). > > Álvaro > > -- > > Álvaro Hernández Tortosa > > ----------- > <8K>data > > Alvaro, > > So why do you want to write in java 8 ? > > Not a comprehensive or ordered list, but a few reasons: > > - JDK comes with Base64 and cryptographic functions like PBKDF2 that > are needed for SCRAM. In Java6 you either implement yourself or pull > external dependencies. > > - You can write conciser code (which improves significantly > readability): > * Lambas: anonymous classes. Callback-heavy code turns becomes > readable. > * Streams: unnecessary for loops and other goodies. > * Optional: unnecessary ifs. > * Since Java7: try-with-resources, 10_000 vs 10000 etc. > > - Reading Javadoc doesn't hurt my eyes ^_^ > > - Time API, CompletableFuture. > > - Default and static methods in interfaces! > > Álvaro > > -- > > Álvaro Hernández Tortosa > > ----------- > > <8K>data > > -- > > Álvaro Hernández Tortosa > > ----------- > > <8K>data > > -- > > Álvaro Hernández Tortosa > > ----------- > <8K>data Cheers, Radoslav
On 03/04/17 21:34, rado@edno.moe wrote: > Hello Alvaro, > > On 2017-04-03 21:53, Álvaro Hernández Tortosa wrote: >> On 03/04/17 20:47, Daniel Migowski wrote: >> >>> Hello Alvaro, >>> >>> while the biggest performance hit currently in the driver is the >>> switch to java.util.Logging (i will come up with numbers regarding >>> that in a few days, comparing it to previous versions). Currently, >>> and comparing to the 9.3 driver with the current driver, the >>> Hibernate databases checks take twice the time than before! Even if >>> some parts have improved (see changes in PGStream and >>> VisibleBufferedInputStream, nice reuse of arrays there since 9.3) >>> other things have changed to the bad. >>> >>> I also already did my tests regarding the stuff below, and concluded >>> that in our company lambda’s are useful in the GUI, but as I said >>> shouldn’t be used on the server. In my tests they were about 50% >>> percent slower in the long run. >>> >>> Streams are the same thing… just look at the stack traces! Good >>> for rarely used stuff, but honestly I prefer a nice loop where you >>> see what is happening in terms of object creation over streams that >>> might be concise, but are not needed. At least not for something you >>> call potentially 100ths of times a second. >> >> While I agree Lambdas and Streams should be used with care, I'm >> still unconvinced that they really take a hit in performance (if the >> compiler is not optimizing that, which most of the time does). I would >> really love to see some numbers to prove my wrong in this respect. But >> I don't see much trends towards not using them in the Java world (but >> the contrary) and I talk to very performance conscious people. > > I've remembered about this writing: > http://blog.takipi.com/benchmark-how-java-8-lambdas-and-streams-can-make-your-code-5-times-slower/ > > They have the code available, I haven't verified it personally. Also > it is possible the outcome to be different with the newer releases of > the JDK. Please note the difference between the original results and > the updated ones. > > The base line is: you have to be extra careful with the streams, > autoboxing and to avoid using lamdas in "hot" places. At least for the > tested use case - "sorting ArrayList populated with 100 000 random > integers". Yeah, that's exactly what I meant: they should be used with care. But that is quite different from never using them at all :) Thank you for the link, I read that in the past and is a good example. Cheers, Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
On 2017-04-03 at 12:48-05, Jorge Solórzano wrote:
> So +1 for drop support for Java 6, and -1 for drop support for Java 7.
I agree. 6 is droppable, but there are still too many users stuck with Java 7 to drop it.
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> However, I wonder if it would be such a big deal for people that are upgrading to
> Postgres 10 and require SCRAM not to ask them to upgrade their JVM to a non EOLed
> version.
If only the people who want the new functionality are required to upgrade to Java 8, then I think it is not a big deal.
If everyone who wants the latest pgjdbc patches has to upgrade to Java 8, then I think it is a big deal.
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> I think the intersection of people who go for very modern PG and non supported Java if almost 0.
The problem with using that argument as a reason to move to Java 8 is that Java 6 and 7 are supported - just not for free.
On 2017-04-03 at 12:48-05, Jorge Solórzano wrote:
> So +1 for drop support for Java 6, and -1 for drop support for Java 7.
I agree. 6 is droppable, but there are still too many users stuck with Java 7 to drop it.
But as I said, they already have many versions to choose from.
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> However, I wonder if it would be such a big deal for people that are upgrading to
> Postgres 10 and require SCRAM not to ask them to upgrade their JVM to a non EOLed
> version.
If only the people who want the new functionality are required to upgrade to Java 8, then I think it is not a big deal.
If everyone who wants the latest pgjdbc patches has to upgrade to Java 8, then I think it is a big deal.
I believe the intersection is minimal. What is the chance of users willing to upgrade to Postgres 10, needing SCRAM, running JRE6 or JRE7 and *not* wanting to upgrade their JRE? (all four conditions need to apply).
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> I think the intersection of people who go for very modern PG and non supported Java if almost 0.
The problem with using that argument as a reason to move to Java 8 is that Java 6 and 7 are supported - just not for free.
I stand corrected. I mean now "non supported for free" or equivalent :)
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data
On 03/04/17 21:15, rado@edno.moe wrote:
> Hi everyone.
> On 2017-04-03 21:58, Stephen Frost wrote:
>> Dave,
>>
>> * Dave Cramer (pg@fastcrypt.com) wrote:
>>> On 3 April 2017 at 14:33, Álvaro Hernández Tortosa <aht@8kdata.com>
>>> wrote:
>>> Quick eyeball of the latest two versions shows significant download of
>>> jre6, and a scary data of 1208 jre7. I wonder what project is using
>>> that?
>>
>> Chef.
>>
>> All but ~4000 of those hits were by either "Chef Client" or "Chef
>> Knife", most of which were, unsurprisingly, just 304's ("not modified").
>
> From 100 000 downloads?
> This link shows which other POMs are referring to 9.4.1208.jre7:
> http://mvnrepository.com/artifact/org.postgresql/postgresql/9.4.1208.jre7/usages
> Keep in mind that I don't know how reliable is this data, but Clojure
> and Spring Boot are quite popular projects.
This doesn't seem to happen with current version 42:
http://mvnrepository.com/artifact/org.postgresql/postgresql/42.0.0.jre7/usages
(not used so far)
BTW, description of this version of the driver, according to
http://mvnrepository.com/artifact/org.postgresql/postgresql/42.0.0.jre7 is:
"Java JDBC 4.2 (JRE 8+) driver for PostgreSQL database"
LOL!
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
On 03/04/17 21:15, rado@edno.moe wrote:Hi everyone.
On 2017-04-03 21:58, Stephen Frost wrote:Dave,
* Dave Cramer (pg@fastcrypt.com) wrote:On 3 April 2017 at 14:33, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
Quick eyeball of the latest two versions shows significant download of
jre6, and a scary data of 1208 jre7. I wonder what project is using that?
Chef.
All but ~4000 of those hits were by either "Chef Client" or "Chef
Knife", most of which were, unsurprisingly, just 304's ("not modified").
From 100 000 downloads?
This link shows which other POMs are referring to 9.4.1208.jre7: http://mvnrepository.com/artifact/org.postgresql/postgresql/ 9.4.1208.jre7/usages
Keep in mind that I don't know how reliable is this data, but Clojure and Spring Boot are quite popular projects.
This doesn't seem to happen with current version 42:
http://mvnrepository.com/artifact/org.postgresql/postgresql/ 42.0.0.jre7/usages (not used so far)
BTW, description of this version of the driver, according to http://mvnrepository.com/artifact/org.postgresql/postgresql/ 42.0.0.jre7 is:
"Java JDBC 4.2 (JRE 8+) driver for PostgreSQL database"
LOL!
On 03/04/17 21:47, Brad DeJong wrote:
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> However, I wonder if it would be such a big deal for people that are upgrading to
> Postgres 10 and require SCRAM not to ask them to upgrade their JVM to a non EOLed
> version.
If only the people who want the new functionality are required to upgrade to Java 8, then I think it is not a big deal.
If everyone who wants the latest pgjdbc patches has to upgrade to Java 8, then I think it is a big deal.
I believe the intersection is minimal. What is the chance of users willing to upgrade to Postgres 10, needing SCRAM, running JRE6 or JRE7 and *not* wanting to upgrade their JRE? (all four conditions need to apply).
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> I think the intersection of people who go for very modern PG and non supported Java if almost 0.
The problem with using that argument as a reason to move to Java 8 is that Java 6 and 7 are supported - just not for free.
I stand corrected. I mean now "non supported for free" or equivalent :)
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>data
On 2017-04-03 23:02, Dave Cramer wrote:
> On 3 April 2017 at 16:01, Álvaro Hernández Tortosa <aht@8kdata.com>
> wrote:
>
>> On 03/04/17 21:15, rado@edno.moe wrote:
>> Hi everyone.
>> On 2017-04-03 21:58, Stephen Frost wrote:
>> Dave,
>>
>> * Dave Cramer (pg@fastcrypt.com) wrote:
>> On 3 April 2017 at 14:33, Álvaro Hernández Tortosa
>> <aht@8kdata.com> wrote:
>> Quick eyeball of the latest two versions shows significant download
>> of
>> jre6, and a scary data of 1208 jre7. I wonder what project is using
>> that?
>>
>> Chef.
>>
>> All but ~4000 of those hits were by either "Chef Client" or "Chef
>> Knife", most of which were, unsurprisingly, just 304's ("not
>> modified").
>
> From 100 000 downloads?
> This link shows which other POMs are referring to 9.4.1208.jre7:
> http://mvnrepository.com/artifact/org.postgresql/postgresql/9.4.1208.jre7/usages
> [1]
> Keep in mind that I don't know how reliable is this data, but Clojure
> and Spring Boot are quite popular projects.
>
> This doesn't seem to happen with current version 42:
>
> http://mvnrepository.com/artifact/org.postgresql/postgresql/42.0.0.jre7/usages
> [2] (not used so far)
The big projects that embed jdbc drivers are not so many and probably
they are not releasing new versions only because of the dependencies
updates. And the 42.0.0 release is quite new.
As a side note: Hibernate 5.2 is officially Java8 only:
https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2#move-to-java-8-for-baseline
And they soon will drop support for 5.1
(http://in.relation.to/2017/03/14/hibernate-orm-515-final-release/) when
5.3 is released. They've changed their policy last year and now you get
bug fixes only for the current and the previous release.
The upcoming version of Spring platform is also Java8:
https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-the-Spring-Framework#whats-new-in-spring-framework-5x
Spring 4.x is Java6, but Spring Boot requires Java7 and recommends
Java8:
http://docs.spring.io/spring-boot/docs/1.5.2.RELEASE/reference/htmlsingle/#getting-started-system-requirements
IMO these two will drive some migration effort to Java8.
> BTW, description of this version of the driver, according to
> http://mvnrepository.com/artifact/org.postgresql/postgresql/42.0.0.jre7
> [3] is:
>
> "Java JDBC 4.2 (JRE 8+) driver for PostgreSQL database"
>
> LOL!
>
> guess I'll have to fix that
Here the release tag seems OK:
http://search.maven.org/#artifactdetails|org.postgresql|postgresql|42.0.0.jre7|jar
Probably it's a bug in mvnrepository.com
>
> Dave Cramer
>
> davec@postgresintl.com
> www.postgresintl.com [4]
>
>
>
> Links:
> ------
> [1]
> http://mvnrepository.com/artifact/org.postgresql/postgresql/9.4.1208.jre7/usages
> [2]
> http://mvnrepository.com/artifact/org.postgresql/postgresql/42.0.0.jre7/usages
> [3]
> http://mvnrepository.com/artifact/org.postgresql/postgresql/42.0.0.jre7
> [4] http://www.postgresintl.com/
From: Jorge Solórzano <jorsol@gmail.com>
To: Álvaro Hernández Tortosa <aht@8kdata.com>
Cc: Brad DeJong <Brad.Dejong@infor.com>; Dave Cramer <pg@fastcrypt.com>; John R Pierce <pierce@hogranch.com>; List <pgsql-jdbc@postgresql.org>
Sent: Mon, Apr 3, 2017 4:27 pm
Subject: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+
On 03/04/17 21:47, Brad DeJong wrote:On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:> However, I wonder if it would be such a big deal for people that are upgrading to> Postgres 10 and require SCRAM not to ask them to upgrade their JVM to a non EOLed> version.If only the people who want the new functionality are required to upgrade to Java 8, then I think it is not a big deal.If everyone who wants the latest pgjdbc patches has to upgrade to Java 8, then I think it is a big deal.
I believe the intersection is minimal. What is the chance of users willing to upgrade to Postgres 10, needing SCRAM, running JRE6 or JRE7 and *not* wanting to upgrade their JRE? (all four conditions need to apply).
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:> I think the intersection of people who go for very modern PG and non supported Java if almost 0.The problem with using that argument as a reason to move to Java 8 is that Java 6 and 7 are supported - just not for free.
I stand corrected. I mean now "non supported for free" or equivalent :)
Álvaro-- Álvaro Hernández Tortosa ----------- <8K>data
On Mon, Apr 3, 2017 at 1:58 PM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:On 03/04/17 21:47, Brad DeJong wrote:
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> However, I wonder if it would be such a big deal for people that are upgrading to
> Postgres 10 and require SCRAM not to ask them to upgrade their JVM to a non EOLed
> version.
If only the people who want the new functionality are required to upgrade to Java 8, then I think it is not a big deal.
If everyone who wants the latest pgjdbc patches has to upgrade to Java 8, then I think it is a big deal.
I believe the intersection is minimal. What is the chance of users willing to upgrade to Postgres 10, needing SCRAM, running JRE6 or JRE7 and *not* wanting to upgrade their JRE? (all four conditions need to apply).
On 2017-04-03 at 09:32-05, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> I think the intersection of people who go for very modern PG and non supported Java if almost 0.
The problem with using that argument as a reason to move to Java 8 is that Java 6 and 7 are supported - just not for free.
I stand corrected. I mean now "non supported for free" or equivalent :)Well, as I said Oracle JDK is not the only JDK, the OpenJDK/IcedTea Team still supports actively Java 7 (and it's recent the drop of Java 6) and it's free in both as speech and as in beer. :-) if you use Ubuntu 14.04 (which should be supported until April 2019) you will get openjdk-7, and you can get the Azul Zulu JDK for free too :-)
You are right, there is still a path for free and supported Java 7 :)
Thanks,
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data
On 03/04/17 22:53, rado@edno.moe wrote:
> On 2017-04-03 23:02, Dave Cramer wrote:
>> On 3 April 2017 at 16:01, Álvaro Hernández Tortosa <aht@8kdata.com>
>> wrote:
>>
>>> On 03/04/17 21:15, rado@edno.moe wrote:
>>> Hi everyone.
>>> On 2017-04-03 21:58, Stephen Frost wrote:
>>> Dave,
>>>
>>> * Dave Cramer (pg@fastcrypt.com) wrote:
>>> On 3 April 2017 at 14:33, Álvaro Hernández Tortosa
>>> <aht@8kdata.com> wrote:
>>> Quick eyeball of the latest two versions shows significant download
>>> of
>>> jre6, and a scary data of 1208 jre7. I wonder what project is using
>>> that?
>>>
>>> Chef.
>>>
>>> All but ~4000 of those hits were by either "Chef Client" or "Chef
>>> Knife", most of which were, unsurprisingly, just 304's ("not
>>> modified").
>>
>> From 100 000 downloads?
>> This link shows which other POMs are referring to 9.4.1208.jre7:
>> http://mvnrepository.com/artifact/org.postgresql/postgresql/9.4.1208.jre7/usages
>>
>> [1]
>> Keep in mind that I don't know how reliable is this data, but Clojure
>> and Spring Boot are quite popular projects.
>>
>> This doesn't seem to happen with current version 42:
>>
>> http://mvnrepository.com/artifact/org.postgresql/postgresql/42.0.0.jre7/usages
>>
>> [2] (not used so far)
>
> The big projects that embed jdbc drivers are not so many and probably
> they are not releasing new versions only because of the dependencies
> updates. And the 42.0.0 release is quite new.
>
> As a side note: Hibernate 5.2 is officially Java8 only:
> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2#move-to-java-8-for-baseline
> And they soon will drop support for 5.1
> (http://in.relation.to/2017/03/14/hibernate-orm-515-final-release/)
> when 5.3 is released. They've changed their policy last year and now
> you get bug fixes only for the current and the previous release.
> The upcoming version of Spring platform is also Java8:
>
https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-the-Spring-Framework#whats-new-in-spring-framework-5x
> Spring 4.x is Java6, but Spring Boot requires Java7 and recommends
> Java8:
> http://docs.spring.io/spring-boot/docs/1.5.2.RELEASE/reference/htmlsingle/#getting-started-system-requirements
>
> IMO these two will drive some migration effort to Java8.
Agreed. Very interesting. I think we should also "recommend" our
users to move forward. I don't see someone willing to upgrade to
PostgreSQL 10 but not willing to update the JRE (it's either both or
none, and if it is none, they are well served with existing drivers).
So what do we do? I can still develop SCRAM for either version of
Java (and while I have already expressed my preference, I will do it
even for Java6, if that's the decision) :) I'm not a committer, so
committers: please let me know what would be the "official" final
decision. Thanks,
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
Agreed. Very interesting. I think we should also "recommend" our users to move forward. I don't see someone willing to upgrade to PostgreSQL 10 but not willing to update the JRE (it's either both or none, and if it is none, they are well served with existing drivers).
On 03/04/17 22:53, rado@edno.moe wrote:On 2017-04-03 23:02, Dave Cramer wrote:On 3 April 2017 at 16:01, Álvaro Hernández Tortosa <aht@8kdata.com>
wrote:On 03/04/17 21:15, rado@edno.moe wrote:
Hi everyone.
On 2017-04-03 21:58, Stephen Frost wrote:
Dave,
* Dave Cramer (pg@fastcrypt.com) wrote:
On 3 April 2017 at 14:33, Álvaro Hernández Tortosa
<aht@8kdata.com> wrote:
Quick eyeball of the latest two versions shows significant download
of
jre6, and a scary data of 1208 jre7. I wonder what project is using
that?
Chef.
All but ~4000 of those hits were by either "Chef Client" or "Chef
Knife", most of which were, unsurprisingly, just 304's ("not
modified").
From 100 000 downloads?
This link shows which other POMs are referring to 9.4.1208.jre7:
http://mvnrepository.com/artifact/org.postgresql/postgresql/ 9.4.1208.jre7/usages
[1]
Keep in mind that I don't know how reliable is this data, but Clojure
and Spring Boot are quite popular projects.
This doesn't seem to happen with current version 42:
http://mvnrepository.com/artifact/org.postgresql/postgresql/ 42.0.0.jre7/usages
[2] (not used so far)
The big projects that embed jdbc drivers are not so many and probably they are not releasing new versions only because of the dependencies updates. And the 42.0.0 release is quite new.
As a side note: Hibernate 5.2 is officially Java8 only: https://github.com/hibernate/hibernate-orm/wiki/Migration-Gu ide---5.2#move-to-java-8-for- baseline
And they soon will drop support for 5.1 (http://in.relation.to/2017/03/14/hibernate-orm-515-final-re lease/) when 5.3 is released. They've changed their policy last year and now you get bug fixes only for the current and the previous release.
The upcoming version of Spring platform is also Java8: https://github.com/spring-projects/spring-framework/wiki/ What%27s-New-in-the-Spring- Framework#whats-new-in-spring- framework-5x
Spring 4.x is Java6, but Spring Boot requires Java7 and recommends Java8: http://docs.spring.io/spring-boot/docs/1.5.2.RELEASE/referen ce/htmlsingle/#getting-started -system-requirements
IMO these two will drive some migration effort to Java8.
So what do we do? I can still develop SCRAM for either version of Java (and while I have already expressed my preference, I will do it even for Java6, if that's the decision) :) I'm not a committer, so committers: please let me know what would be the "official" final decision. Thanks,
On 4 April 2017 at 11:11, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:Agreed. Very interesting. I think we should also "recommend" our users to move forward. I don't see someone willing to upgrade to PostgreSQL 10 but not willing to update the JRE (it's either both or none, and if it is none, they are well served with existing drivers).
On 03/04/17 22:53, rado@edno.moe wrote:On 2017-04-03 23:02, Dave Cramer wrote:On 3 April 2017 at 16:01, Álvaro Hernández Tortosa <aht@8kdata.com>
wrote:On 03/04/17 21:15, rado@edno.moe wrote:
Hi everyone.
On 2017-04-03 21:58, Stephen Frost wrote:
Dave,
* Dave Cramer (pg@fastcrypt.com) wrote:
On 3 April 2017 at 14:33, Álvaro Hernández Tortosa
<aht@8kdata.com> wrote:
Quick eyeball of the latest two versions shows significant download
of
jre6, and a scary data of 1208 jre7. I wonder what project is using
that?
Chef.
All but ~4000 of those hits were by either "Chef Client" or "Chef
Knife", most of which were, unsurprisingly, just 304's ("not
modified").
From 100 000 downloads?
This link shows which other POMs are referring to 9.4.1208.jre7:
http://mvnrepository.com/artifact/org.postgresql/postgresql/ 9.4.1208.jre7/usages
[1]
Keep in mind that I don't know how reliable is this data, but Clojure
and Spring Boot are quite popular projects.
This doesn't seem to happen with current version 42:
http://mvnrepository.com/artifact/org.postgresql/postgresql/ 42.0.0.jre7/usages
[2] (not used so far)
The big projects that embed jdbc drivers are not so many and probably they are not releasing new versions only because of the dependencies updates. And the 42.0.0 release is quite new.
As a side note: Hibernate 5.2 is officially Java8 only: https://github.com/hibernate/hibernate-orm/wiki/Migration-Gu ide---5.2#move-to-java-8-for- baseline
And they soon will drop support for 5.1 (http://in.relation.to/2017/03/14/hibernate-orm-515-final-re lease/) when 5.3 is released. They've changed their policy last year and now you get bug fixes only for the current and the previous release.
The upcoming version of Spring platform is also Java8: https://github.com/spring-projects/spring-framework/wiki/ What%27s-New-in-the-Spring- Framework#whats-new-in-spring- framework-5x
Spring 4.x is Java6, but Spring Boot requires Java7 and recommends Java8: http://docs.spring.io/spring-boot/docs/1.5.2.RELEASE/referen ce/htmlsingle/#getting-started -system-requirements
IMO these two will drive some migration effort to Java8.
So what do we do? I can still develop SCRAM for either version of Java (and while I have already expressed my preference, I will do it even for Java6, if that's the decision) :) I'm not a committer, so committers: please let me know what would be the "official" final decision. Thanks,Keep going with java 8 for now. Given that the use of MD5 the way we actually use it is not really an issue, I'm less worried about this than I originally thought. I do have some feelers out in the enterprise though to get some feed back
Great, I will do that.
If, then, at some point we get strong feedback, I'd volunteer to help backport the code to Java6/7.
Cheers,
Álvaro
-- Álvaro Hernández Tortosa ----------- <8K>data