refactor: fix getDriverVersion and getDriverName and getJDBCMajor/MinorVersion methods

[jorsol]

The driver name is "PostgreSQL JDBC Driver"
The output of the driver version should not include "PostgreSQL"

[vlsi]

The output of the driver version should not include "PostgreSQL"

Any specific reason for doing so?
I'm afraid it might trigger unexpected backward-compatibility issues

[codecov-io]

Current coverage is 64.37% (diff: 41.66%)

Merging #668 into master will increase coverage by 0.14%

@@             master       #668   diff @@
==========================================
  Files           163        163          
  Lines         15142      15140     -2   
  Methods           0          0          
  Messages          0          0          
  Branches       2987       2987          
==========================================
+ Hits           9727       9747    +20   
+ Misses         4182       4156    -26   
- Partials       1233       1237     +4   

Powered by Codecov. Last update e1a2578...b564f42

[jorsol]

@vlsi, prior to maven conversion the version was returned in this format:

42c2e3b#diff-a82520f846ea7ba590d13a466aeafffeL498

The output of postgresql-9.3-1103.jdbc3.jar is "PostgreSQL 9.3 JDBC3g (build 1103)"
and the output of postgresql-9.4-1206-jdbc42.jar is "PostgreSQL 9.4 JDBC4.2 (build 1206)"
so there was already a "potential" backward-compatibility issue since now returns "PostgreSQL 9.4.1211".

I doubt anyone is using that to "parse" the version of the driver, for that there is getDriverMajorVersion() and getDriverMinorVersion() methods. It's a matter of correctness since getDriverVersion() means version.

[davecramer]

given that nobody looks at it, I guess this is fine, on the other hand nobody looks at it ;)

[panchenko]

getDriverName() incompatibility has potentially higher impact than getDriverVersion().

[davecramer]

Good catch. Please revert this change

[jorsol]

@panchenko have you find a project that use getDriverName() to implement logic and cause a potentially higher impact? I don't have found any.

[jorsol]

IMO general applications use getDriverVersion() and getDriverName() for printing information not for implement logic.

I did a quick find (nothing deep) on "potential" projects that "probably" use this information which are mostly ORMs, on JOOQ, Sprint-JDBC, Hibernate and found.... nothing.

Since we have entered in a highly speculative area I will close this PR.

[jorsol]

Now that we have moving forward with versioning 42 this can be reconsidered.

[vlsi]

Any clue

[vlsi]

In general looks good, except two things:

1. I would like to refrain from copy-pasting inherited javadocs. The build process handles that just fine (I mean it is smart enough to copy javadocs from java.sql.* and alike).
2. string split in getXXXversion look odd.

[vlsi]

Any clue why do you copy javadocs for @Override methods?

AFAIK, javadoc build does handle that just fine.
See http://static.javadoc.io/org.postgresql/postgresql/9.4.1212.jre7/org/postgresql/Driver.html#getParentLogger() as an example.

So I would remove all the inherited copy-pasted javadocs unless they have some postgresql specifics.
For instance, connect method does have some PG specific, so it is LGTM. On the other hand, things like Retrieves the major JDBC version number for this driver add little value and can be inherited.

However, in this particular method adding some pgjdbc-specific example would help a lot. For instance "The method returns the driver major version, not the versions of the backend. This method would return something like 42 ad pgjdbc versions are like 42.x.y."

[jorsol]

Good point, I will look at it.

[vlsi]

Well, technically speaking, there's non-trivial build step that unzips jdk sources (e.g. https://github.com/pgjdbc/pgjdbc-parent-poms/blob/master/pgjdbc-core-parent/pom.xml#L270-L278) and adds them to javadoc tool, however it does "just work".

[vlsi]

Is mvn.project.property.parsedversion.majorversion better here?

[jorsol]

No, the mvn.project.property.parsedversion.majorversion is for the driver version, not for the JDBC specification version, so this should return 4 as the major specification version, this is get from mvn.project.property.jdbc.specification.version and parsed the first number.

[vlsi]

Is mvn.project.property.parsedversion.minorversion better here

[jorsol]

No, the mvn.project.property.parsedversion.minorversion is for the driver version, not for the JDBC specification version, so this should return 0 for Java 6, 1 for Java 7 and 2 for Java 8 as the major specification version, this is get from mvn.project.property.jdbc.specification.version and parsed the second number.

[jorsol]

@vlsi, requested changes done, removed javadoc that can be inherited, I could not reproduce the behavior using mvn javadoc:javadoc but since the release artifact use a special "unzip jdk" I guess it's ok.

For the second point, the other form to split the version is with a StringTokenizer, but the JavaDocs say:

StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead.

Happy New Year!

[jorsol]

Another comment about this?

[jorsol]

@vlsi , is there any other request on this?

[panchenko]

I would rather remove "throws" from code, rather then documenting it.

[panchenko]

Is this default absolutely necessary?

[jorsol]

And why not?

[panchenko]

Theoretically, one might want a connection without this property. I don't have a real world example for that, just being cautious about unnecessary changes :-)

[panchenko]

in poms there is also jdbc.specification.version.nodot - might be use it and int math operations instead?

[jorsol]

Maybe, but the problem with the split is?

[panchenko]

Less operations during runtime, it will be just a compile time constant.

[vlsi]

1. static final fields are initialized once, so there's no point in discussing "runtime overhead"
2. My main concern on .split was it is hard to get right ("off by one" errors and so on).

[jorsol]

The property is set by default on the pom, so it should be hard to "break" or get the "off by one" errors, I can use the int math if you wish, at least it will allow to catch bad values at compile time.

To be completely safe there must be the properties in the pom.xml and use those values.
jdbc.specification.majorversion
jdbc.specification.minorversion

[jorsol]

Now is using the int math, what do you think?

[hmatt1]

It turns out ActiveMQ was relying on the original name, so this change broke compatibility. See this issue: https://issues.apache.org/jira/browse/AMQ-6780

[davecramer]

@hmatt1 not sure how that is our problem ?

[hmatt1]

@davecramer it's not, no action needed on your part. I figured I share because jorsol commented

IMO general applications use getDriverVersion() and getDriverName() for printing information not for implement logic.

and it turns out ActiveMQ is relying on getDriverName()

[jorsol]

Yes, and it's ActiveMQ fault to relying on getDriverName(), for instance if I want to use pgjdbc-ng or a custom fork of PgJDBC, it makes impossible to change it.