| 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: | Whole Thread | Raw Message | 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
| 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 |