3 ms·

> It is not "never urgent", it is a fundamental pillar of Java that users will never have to rewrite their code, and that is one of the major reasons that Java

> It is not "never urgent", it is a fundamental pillar of Java that users will never have to rewrite their code, and that is one of the major reasons that Java is so popular with business. During my (admittedly short) time at a Java shop we were running all of our stuff on Java X, where X was at least 2 versions less than the currently released version. The newer versions had some nice features that would have been great to use, but we never upgraded for fear of breaking something. I got the hell out of Java-land as soon as I could, so I don't really know whether people were justifiably afraid or just overly paranoid, but either way this seems to be at odds with the "fundamental pillar" you mentioned. My experience could very well have been an uncommon outlier though. EDIT: Fixing formatting. I wish HN used Markdown or something instead of its own unique snowflake of a markup format.

angelbob 15y ago
I share your experience. We had to do a huge amount of maintenance to upgrade from Java 5 to Java 6. It was definitely not just drop-in. Does that mean the code was written badly? Possibly. It wasn't amazing. Still, that seems more like the rule than the exception.
- InclinedPlane 15y ago
  It shouldn't matter how well the code was written. Binary compatibility should be binary compatibility, period. If it compiles it should be compatible across JVMs. The fact that this is not the case is just another nail in the coffin.
- lemming 15y ago
  I'd be interested to know what problems you had. We literally dropped Java 6 into our million line project without problems. Despite what the OP implies, this was huge for us. If Java were maintained like, say, Rails we'd still be on 1.3.
  - haldean 15y ago
    I'd like to know as well -- my team (~1MLOC Java product) upgraded from Java 5 to Java 6, and then Java 6 to Java 7, by changing a line in our build script, and everything worked fine.
  - srdev 15y ago
    In my team's case, the only problem we had was having to modify a bunch of decorators that implemented the java.sql.Connection interface. They added a bunch of methods to the interface in the upgrade.

angelbob 15y ago

I share your experience. We had to do a huge amount of maintenance to upgrade from Java 5 to Java 6. It was definitely not just drop-in. Does that mean the code was written badly? Possibly. It wasn't amazing. Still, that seems more like the rule than the exception.

InclinedPlane 15y ago
It shouldn't matter how well the code was written. Binary compatibility should be binary compatibility, period. If it compiles it should be compatible across JVMs. The fact that this is not the case is just another nail in the coffin.
lemming 15y ago
I'd be interested to know what problems you had. We literally dropped Java 6 into our million line project without problems. Despite what the OP implies, this was huge for us. If Java were maintained like, say, Rails we'd still be on 1.3.
- haldean 15y ago
  I'd like to know as well -- my team (~1MLOC Java product) upgraded from Java 5 to Java 6, and then Java 6 to Java 7, by changing a line in our build script, and everything worked fine.
- srdev 15y ago
  In my team's case, the only problem we had was having to modify a bunch of decorators that implemented the java.sql.Connection interface. They added a bunch of methods to the interface in the upgrade.