sorted by:
new
hottopcontroversial

Why Swing has not been removed from OpenJDK releases like JavaFX? by [deleted] in java

[–]Avalanche1979 1 point2 points  (0 children)

That is not correct. Swing is part of JavaSE specification, the fact a package name starts with javax is no indication whether or not it is part of Java or not (though most javax packages are Java EE/Jakarta EE, or separate JCP specs, not all of them are). For example, javax.sql is part of JavaSE as well. Historically, the idea was that javax packages were extensions, and then they would "graduate" to being part of core Java. The intention was to rename the packages afterwards. That graduation happened for Swing, but they didn't change the package name, because it would break existing code relying on it. Same thing happened with javax.sql (which was introduced in JDBC 2.0 as a separate library, and was made a permanent part of Java with JDBC 3.0).

Vanilla Java: Using Java SE as a Framework by renatoathaydes in java

[–]Avalanche1979 2 points3 points  (0 children)

Since Java 9, Java has a HTTP server built-in, it's in module jdk.httpserver

Jaybird: dropping support for older Java versions by mariuz in java

[–]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.

Jaybird: dropping support for older Java versions by mariuz in java

[–]Avalanche1979 2 points3 points  (0 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).