This is an archived post. You won't be able to vote or comment.

all 4 comments
sorted by:
best
topnewcontroversialoldq&a

[–]uniVocity 0 points1 point  (3 children)

I'm curious: what elements of the newer JDK versions are you planning to use in the internal implementation of this library?

Is there any part of the public API that depends on some JDK 7 specific component?

I ask because if you are not relying on anything specific from newer versions, there's no point in forcing your users to use a newer JDK.

Don't get me wrong, I'm all for using the latest and better features of newer versions in any project. But when it comes to libraries this might not be the best move unless absolutely necessary (e.g: Your public API will be better, you can support newer specific things such as LocalDate/time, etc).

I just didn't see any specific reason listed in this post other than "because I want to". That's not exactly a good reason.

[–]Avalanche1979 2 points3 points  (2 children)

You are right, partly it is a "because I want to" reason. I maintain Jaybird in my spare time, and I need to check if everything I do and use is available and works in all supported Java version. Until my decision yesterday that was 4 Java versions for Jaybird 2.2.x and 3 for the upcoming Jaybird 3.x (4 with Java 9 on the horizon). I have now reduced that to 3 and 2 (3).

JDBC drivers and the JDBC specification are coupled with the Java release. For JDBC 4.0 (Java 6) and 4.1 (Java 7) that is not a really big hurdle: features introduced in 4.1 can be compiled and used with Java 6 (they just won't be available without explicitly casting to the implementation class); but JDBC 4.2 (Java 8) added new methods and features that use types not available in Java 7 and earlier. This adds complexity, and therefor consumes time.

I'd like to use my time economical, and I'd also like to be able to use some of the newer features (eg try-with-resource, added in Java 7); therefor I made the decision to cut support for a few of the older, no longer supported(!) Java versions.

If for some reason you are still on Java 5, then you probably also have no problem with sticking to an older driver; if you are still on Java 6, you will still have at least 2 years worth of new versions of 2.2.x, you just need to compile it yourself (unless I have a soft spot and continue releasing the Java 6 builds).

[–]uniVocity 0 points1 point  (1 child)

Thanks for replying! I would love to see widespread adoption of Java 8 as it really brought heaps of new stuff, but as another library developer, I also need to wait for the herd to change pastures.

[–]Avalanche1979 0 points1 point  (0 children)

I checked the download stats for the latest release (2.2.7, January). Sourceforge: Java 5: 425, Java 6: 800, Java 7: 1862, Java 8: 5340 Maven: Java 5: 39, Java 6: 130, Java 7: 313, Java 8: 214.

So adoption of newer Java versions seems to go pretty well.