Обсуждение: Maven Artifact JDK Suffix

On Sun, 10 Jan 2016 19:02:59 -0500, Sehrope Sarkuni <sehrope@jackdb.com>
wrote:
> Why doesn't the JDK 8 version of the Maven artifact for the driver
include
> the .jre8 suffix?
>
> Here's what's currently on the main README:
>
>   <dependency>
>     <groupId>org.postgresql</groupId>
>     <artifactId>postgresql</artifactId>
>     <version>9.4.1207</version> <!-- Java 8 -->
>     <version>9.4.1207.jre7</version> <!-- Java 7 -->
>     <version>9.4.1207.jre6</version> <!-- Java 6 -->
>   </dependency>
>
>
> The other versions are JDK version suffixed and at some point there will
be
> a JDK 9. Why not name it X.jre8 so that we're ready for when that day
> comes?

I agree. Having one unsuffixed is confusing.

> Somewhat related, is it possible for more than one JDBC release to come
out
> for the same JDK version or will that not happen anymore?

That is not possible with the current way of working. The JDBC API is part
of the Java SE API and can only change together with a new Java SE version;
changing that would likely break a lot of things ;)

> If so, we'd be better off naming the releases off the JDBC version (ex:
> 9.4.127.jdbc42). Each JDBC version already has a min supported JDK
version
> associated with it (ex: JDBC 4.2 requires JDK 8+) so it's super set of
> tracking JDK versions. Then again, if the days of JDBC updates out of
band
> from JDK updates are gone, it's just extra noise/confusion (vs. tracking
> against the JDK version).

As far as I know JDBC has never been updated out of band (maybe with the
exception of the JDBC 2 Extensions, although I believe that was also part
of Java 1.3).

> 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

On Mon, 11 Jan 2016 12:04:54 +0300, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
>> 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.

But it makes it less intuitive; a newer version of the same dependency
will suddenly stop working with an incompatible class version error. What
if I am on the latest jre8 version when Java 9 is out, and I need to go
back to an earlier version: then I need to track when the switch from
unsuffixed Java 8 to suffixed Java 8 version occurred to be able to
downgrade (granted, that is a bit less common scenario).

On the other hand, for Jaybird somewhere in the past someone outside the
Firebird project released Jaybird 2.1.6 on maven without a suffix, and it
has still a relatively big share of the downloads. I am unsure why that is.
I am still considering whether I should **also** release the highest
version unsuffixed (next to the suffixed version).

Mark

>What if I am on the latest jre8 version when Java 9 is out, and I need to go
>back to an earlier version: then I need to track when the switch from
>unsuffixed Java 8 to suffixed Java 8 version occurred to be able to
>downgrade (granted, that is a bit less common scenario).

Frankly speaking, I do not get the use-case you are trying to convey.

Suppose you have x.y.z and that is the latest jre8 version at some
point in time.
Even after jre9 is launched, the same x.y.z will still be jre8.

So if you "do not want to upgrade", you just keep your version x.y.z.

If you want to upgrade (suppose, the most current version is "k.l.m"),
you just use k.l.m-jre8 if you a still stuck with jre8.

> What if I am on the latest jre8 version when Java 9 is out, and I need to go
> back to an earlier version

As I said above, I see no practical use case, except for some "bug
hunting via driver version bisection".
If that is the case, there is always list of all the versions:
https://jdbc.postgresql.org/download.html#others

Vladimir

>[2]: 9.4.1210.jre7 > 9.4.1207.jre8

So what is the problem with that?
I do not think there is a "proper" way to compare 1210.jre7 vs 1207.jre8.
I do not think it outweights "multiartifact" drawbacks I list below.

What I fear is java 10 when we would hit a string literal comparison wall.
Thus we might want use jre07, jre08, jre09 to be prepared for jre10 :)

> They're entirely different artifacts

They are not.
For instance: is it sane to include _both_ artifacts at the same time?
I do not think so.

Having different artifact ids would:
1) Open can of worms with "multiple pgjdbc artifacts at the same time".
2) Make upgrading pgjdbc very hard.

If jreX is a part of version, then you can define the version in
parent pom, and all the child projects just inherit it.
You can easily flip version back and forth by altering version in parent.

If jreX is artifact id, then you would have to change all the child
projects to use updated artifact id.

Vladimir

On Fri, 15 Jan 2016 06:24:21 -0500, Dave Cramer <davecramer@gmail.com>
wrote:
> I would have to agree with this. I think people will be surprised (not
in a
> good way) if we upgrade to java 9 and all of a sudden maven pulls down
JDBC
> for java 9

As far as I know, starting with Java 9 this problem could be solved with
multi-release JARs (JEP-238, http://openjdk.java.net/jeps/238). The main
content could then be Java 8, and the Java 9 versions of classes could go
into META-INF/versions/9 (assuming that is the final way JEP-238 will be
realised, I am not sure if it is already in). For efficiency it would be
best to only put in a Java 9 version of classes that really need a Java 9
version.

Mark

On Fri, 15 Jan 2016 06:56:54 -0500, Dave Cramer <pg@fastcrypt.com> wrote:
> On 15 January 2016 at 06:51, Mark Rotteveel <mark@lawinegevaar.nl>
wrote:
>
>> On Fri, 15 Jan 2016 06:24:21 -0500, Dave Cramer <davecramer@gmail.com>
>> wrote:
>> > I would have to agree with this. I think people will be surprised
(not
>> in a
>> > good way) if we upgrade to java 9 and all of a sudden maven pulls
down
>> JDBC
>> > for java 9
>>
>> As far as I know, starting with Java 9 this problem could be solved
with
>> multi-release JARs (JEP-238, http://openjdk.java.net/jeps/238). The
main
>> content could then be Java 8, and the Java 9 versions of classes could
go
>> into META-INF/versions/9 (assuming that is the final way JEP-238 will
be
>> realised, I am not sure if it is already in). For efficiency it would
be
>> best to only put in a Java 9 version of classes that really need a Java
9
>> version.
>>
>> Yes, but in my example the customer would still be running Java 8. Does
> Java 8 know how to read this jar

Yes it would, because Java 8 doesn't know about META-INF/versions/... so
it will just read the (Java 8) classes in the root. The idea behind JEP-238
is that Java versions that don't understand it will use the classes in the
root as they would normally do, and that Java versions that do understand
it will first read a class in their version folder (if it exists), and fall
back to the classes in the root if no version-specific class is found.

At least, that is the theory as I understand it.

Mark

I wonder how that plays with "javadoc & source" jars.

I'm inclined to adding ".jre8" as qualifier.

Vladimir

On Fri, 15 Jan 2016 15:28:29 +0300, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
> I wonder how that plays with "javadoc & source" jars.
>
> I'm inclined to adding ".jre8" as qualifier.
>
> Vladimir

I don't think this will work for javadoc, no.

Mark

Well, if multi-release javadocs/sources/debugging are not supported,
then I would prefer jreXY versions.

So what about renaming jre6 -> jre06, jre7 -> jre07,  nosuffix -> jre08?

Vladimir

The reason is Maven sorts strings literally, thus java10 would be
collated before jre9

Vladimir

>Using two digits won't fix anything

Well, if one module depends on "jre9 and another depends on jre10",
then jre9 will be used by Maven.

Another issue: maven badge would display wrong version.
https://maven-badges.herokuapp.com/maven-central/org.postgresql/postgresql/badge.svg

>looks odd compared to how JRE versions are generally referred.

This is true.

Vladimir

>* jre07-9.4.1207

This is not a valid Maven version.
Valid version should be <major>.<minor>.<patch><qualifier> where
major/minor/patch are numerics

We'd probably better follow "plug&pray" development style and go ahead
with jre6/jre7/jre8 then.

Any volunteers to prepare such a PR? (I'm not sure if there's anything
more than mvn versions:set is required)

Vladimir

On Fri, Jan 15, 2016 at 9:15 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:

>* jre07-9.4.1207
 

We'd probably better follow "plug&pray" development style and go ahead
with jre6/jre7/jre8 then.

Yes I guess we don't really have much other choice besides complicating things quite a bit with separate dependencies for the API itself (and/or separate artifacts per JDK).

We should add a note to the README about this as well. I'm sure someone will eventually run into the issue of a dependency specifying a newer driver version with a lower JDK. Would be nice to have it documented somewhere that the solution is to make sure the top level Maven project specifies the latest version for the desired JDK version.