4 ms·

Code for older Java versions still compiles in Java 8. Code written for python 2.x will not run on python 3.x.

by Proleps 11y ago

pjmlp 11y ago
Breaking changes in Java 8 http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198 http://www.oracle.com/technetwork/java/javase/8-compatibilit... Breaking changes in Java 7 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 6 http://www.oracle.com/technetwork/java/javase/compatibility-137541.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 5 http://www.oracle.com/technetwork/java/javase/compatibility-137462.html 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-142878.html 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.
- _yosefk 11y ago
  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'?
- needusername 11y ago
  > 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"?
  - pjmlp 11y ago
    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.
    - needusername 11y ago
      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.
      - pjmlp 11y ago
        Someone needs to implement those drivers...
        needusername 11y ago
        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.
        pjmlp 11y ago
        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.
        needusername 11y ago
        > Those drivers can be application specific, Nope, they are database specific. So we went from "would break any application using JDBC" to large company rolling their own database drivers for reasons that can't be disclosed (probably to protect the guilty). > 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. Standard case of a large company doing it wrong and blaming somebody else when it comes back to bite them rather than fixing it. And hiding behind an NDA. Seriously what was the expectation? That JDBC never changes? Because at that time JDBC was already at version 3.0 which is obviously the final version after which no features would ever be added again. > Another use case, many developers mock JDBC by creating their own dummy drivers, specially in large companies where mocking libraries are frown upon. If you're doing it wrong then you're doing it wrong. Nobody to blame but yourself. Just because you're a large company doesn't make it right. Part of why it's wrong is that it will come back and bite you later on. And that's the problem in this case? The compiler tells you where you need to implement which methods. Two give you two other examples. Interfaces for HTTP likely need to be updated when something in HTTP changes (WebSockets, HTTP/2). Servers implementing this will need to be updated to implement this. You don't accuse the language of the web server to make a breaking change. That's just how these things work. Same for SSL/TLS features like SNI. Sure it could be that you absolutely have to run your own web server or SSL/TLS implementations for reasons that you can't disclose because you're under an NDA. But then you expect that you'll have to maintain them and add additional features, don't you?

Code for older Java versions still compiles in Java 8. Code written for python 2.x will not run on python 3.x.

by Proleps 11y ago

Code for older Java versions still compiles in Java 8. Code written for python 2.x will not run on python 3.x.

pjmlp 11y ago

Breaking changes in Java 8 http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198 http://www.oracle.com/technetwork/java/javase/8-compatibilit... Breaking changes in Java 7 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 6 http://www.oracle.com/technetwork/java/javase/compatibility-137541.html#incompatibilities http://www.oracle.com/technetwork/java/javase/compatibility-... Breaking changes in Java 5 http://www.oracle.com/technetwork/java/javase/compatibility-137462.html 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-142878.html 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.

_yosefk 11y ago
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'?
needusername 11y ago
> 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"?
- pjmlp 11y ago
  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.
  - needusername 11y ago
    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.
    - pjmlp 11y ago
      Someone needs to implement those drivers...
      - needusername 11y ago
        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.
        pjmlp 11y ago
        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.
        needusername 11y ago
        > Those drivers can be application specific, Nope, they are database specific. So we went from "would break any application using JDBC" to large company rolling their own database drivers for reasons that can't be disclosed (probably to protect the guilty). > 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. Standard case of a large company doing it wrong and blaming somebody else when it comes back to bite them rather than fixing it. And hiding behind an NDA. Seriously what was the expectation? That JDBC never changes? Because at that time JDBC was already at version 3.0 which is obviously the final version after which no features would ever be added again. > Another use case, many developers mock JDBC by creating their own dummy drivers, specially in large companies where mocking libraries are frown upon. If you're doing it wrong then you're doing it wrong. Nobody to blame but yourself. Just because you're a large company doesn't make it right. Part of why it's wrong is that it will come back and bite you later on. And that's the problem in this case? The compiler tells you where you need to implement which methods. Two give you two other examples. Interfaces for HTTP likely need to be updated when something in HTTP changes (WebSockets, HTTP/2). Servers implementing this will need to be updated to implement this. You don't accuse the language of the web server to make a breaking change. That's just how these things work. Same for SSL/TLS features like SNI. Sure it could be that you absolutely have to run your own web server or SSL/TLS implementations for reasons that you can't disclose because you're under an NDA. But then you expect that you'll have to maintain them and add additional features, don't you?