Re: RFC: Make new versions of pgjdbc Java8+

On 3 April 2017 at 14:03, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> wrote:

>
>
> On 03/04/17 19:48, Jorge Solórzano wrote:
>
> On Mon, Apr 3, 2017 at 11:15 AM, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>
> wrote:
>
>>
>> On 03/04/17 18:32, Jorge Solórzano wrote:
>> The End of Public Updates
>> <https://blogs.oracle.com/java/end-of-public-updates-for-java-se-6> of *Oracle
>> JDK* 6 was on Feb 2013, *but* there is an "premier" and "extended"
>> support <http://www.oracle.com/technetwork/java/eol-135779.html> (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.
>>
>
>
> ​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
>> <http://blog.fuseyism.com/index.php/2017/01/11/discontinuation-of-support-for-icedtea-1-x/>
>> 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 :-)
> ​
>
>
>>
>>
>> - The Azul Zulu <http://zulu.org/> 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+.
>>
>>
> ​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
> <https://github.com/ogrebgr/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
> <https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/util/Base64.java>
> 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
>
>

Let me clarify my position:

I consider the JDBC driver to be an interface to PostgreSQL for as many
users as possible.
At the most recent pgconf in NJ one of the keynote speakers talked about
the importance of convenience from the users point of view.

So if I look at this discussion from that angle what I see is that the
driver should attempt to provide as many features of *PostgreSQL* to as
many users as possible.

This ends up putting the complexity in the driver to provide the simplicity
for the user.

That being said; I earlier said that I would accept the implementation of
SCRAM for java 8 only in the interest of expediency. However I do expect to
have to rewrite it to support java 6+

As for being conservative; PostgreSQL could be painted with that brush as
well, for good reason. We value the sanctity of your data.

Regards,

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com