Hacker News new | ask | show | jobs
by pjmlp 4077 days ago
Breaking changes in Java 8

http://www.oracle.com/technetwork/java/javase/8-compatibilit...

Breaking changes in Java 7

http://www.oracle.com/technetwork/java/javase/compatibility-...

Breaking changes in Java 6

http://www.oracle.com/technetwork/java/javase/compatibility-...

Breaking changes in Java 5

http://www.oracle.com/technetwork/java/javase/compatibility-...

Breaking changes in all Java versions up to 1.4

http://www.oracle.com/technetwork/java/javase/compatibility-...

I no longer remember which version it was and don't feel like going through those lists now, but I remember one of those versions changed some JDBC interfaces which would break any application using JDBC.

2 comments

Well, it kinda depends on exactly what the breaking changes are and how much code they break, don't you think? Certainly none of the languages you mention in the grandparent comment broke Hello, world. It's also a question of what share of issues can be automatically flagged and when (build, run?)

Python had its share of breaking changes as well over the years and there wasn't much fuss about them. Who refused to upgrade over class name(object) or say hex(-1) producing '-0x1' instead of '0xffffffff'?

> but I remember one of those versions changed some JDBC interfaces which would break any application using JDBC

lol wut? How exactly does adding a method to a JDBC interface "break any application using JDBC"?

The code will fail to compile because the implementation no longer matches the interface? Duh.

Maybe I should have written extending the JDBC classes instead.

Yeah, you should have. An application is not supposed to implement JDBC. The database driver is supposed to implemented JDBC. If your application implements JDBC you're doing it wrong.

Just like nobody walks around and complains that new versions of the servlet API break any Java web application because web applications are not supposed to implement the servlet API. That's the job of the server.

Someone needs to implement those drivers...
Yeah, but not your application. If the driver specification gets updated it's not really surprising that the drivers will need to be updated. But the same is true for every specification. However your application doesn't need to be changed.
Those drivers can be application specific, as it was the case in the application I had to fix. Why it was made so, will be kept under the covers of the NDA agreement.

Another use case, many developers mock JDBC by creating their own dummy drivers, specially in large companies where mocking libraries are frown upon.