Re: Maven Artifact JDK Suffix

From: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
To: Mark Rotteveel <mark(at)lawinegevaar(dot)nl>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Maven Artifact JDK Suffix
Date: 2016-01-11 09:04:54
Message-ID: CAB=Je-HwcmdtEjCDiQY5uqkX_apNFikwgXsoHFuKTSFVrEWLFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

> a JDK 9. Why not name it X.jre8 so that we're ready for when that day
> comes?

The idea is "unsuffixed is the latest version while others being
second-class citizens".
When jdk9 comes, a new project is added for jre8, and unsuffixed
becomes jre9 only.
Well, I think we can make jre8 explicit and avoid unsuffixed versions.
I do not have strong option there.

>> If so, we'd be better off naming the releases off the JDBC version (ex:
>> 9.4.127.jdbc42).

The problem with jdbc42 is regular developers just do not care of JDBC versions.
For instance: I'm a performance engineer. I do lots of SQL/Java
tuning, yet I do not care the difference of JDBC X vs Y. Typical case
is just "execute a plain old SQL statement".

From release engineering point of view, .jreX suffixes are much easier
to manage: it is just obvious if "a wrong version is included".

For instance, can you tell which JDBC spec added method
https://docs.oracle.com/javase/8/docs/api/java/sql/PreparedStatement.html#setObject-int-java.lang.Object-java.sql.SQLType-

?

Javadoc for that method reads just "since 1.8".

I believe, the main use-case is "what is the latest driver version for my JRE".
I can hardly imagine a case when developer wants "JDBC 4.1 compliant driver".

Vladimir

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Mark Rotteveel 2016-01-11 09:16:24 Re: Maven Artifact JDK Suffix
Previous Message Mark Rotteveel 2016-01-11 08:52:46 Re: Maven Artifact JDK Suffix