4 ms·

It doesn't. You just install the latest java and it's fully backwards compatible.

towelrod 11y ago
That's not really true. We still run some older Apache camel components that require Java 7. And when Java 8 first came out it had bugs that crippled Solr, it took a long time before that was stable enough to use everywhere.
dham 11y ago
Well Ruby is too. If something worked on 1.9 it works on 2.3.
- yxhuvud 11y ago
  Yeah? Try rails 3.2.17 which work perfectly on ruby 1.9 and see how well it works on 2.2. (java is not fully backwards compatible either, but it may be a bit more tolerant in some cases)
  - briandear 11y ago
    Rails isn't ruby.
    - fuzzygroove 11y ago
      It's Ruby on Rails
    - yxhuvud 11y ago
      Did I claim that? However, it is written in ruby and as such it is a valid counterexample to the claim in the comment I commented on.
  - breckenedge 11y ago
    I've done the work before to make rails 3.2 work on 2.2. I recall the problem is due to a breaking Bcrypt name change and Yaml serialization, and it's a one line patch. The maintainers are aware of the issue but held back so as to not break every 3.2 installation on a minor upgrade (would have to be called Rails 3.3 for semver?). Rails 4.0 isnt that hard of an upgrade path if you include the attraccessible gem.
    - yxhuvud 11y ago
      It took quite a while before rails released a version of 3.2 that worked. As for how fun upgrading to rails4 is, you obviously don't have a project with 200 database tables that has models using the attr_protected for the five columns (appwide) that actually need it. Forced whitelisting is not fun, regardless of if it is on model or controller level.
wpietri 11y ago
I'm not sure that's really true, but it regardless misses the point. No matter what language you're using, you'll eventually need to be able to deal with multiple versions of it. Even if you're running an operation small enough that you can upgrade every single runtime in use all in one step, you'll still need to have two versions around while you test. But many, many places have to deal with multiple language versions simultaneously. E.g., if you maintain an open source library and have any regard for your users, you have to test how it behaves in multiple language versions.
deleted 11y ago
[deleted]
yxhuvud 11y ago
No, Java is not fully backwards compatible. It may be more backwards compatible compared to ruby, but claiming that it is fully backwards compatible is simple false.

That's not really true. We still run some older Apache camel components that require Java 7. And when Java 8 first came out it had bugs that crippled Solr, it took a long time before that was stable enough to use everywhere.

dham 11y ago

Well Ruby is too. If something worked on 1.9 it works on 2.3.

yxhuvud 11y ago
Yeah? Try rails 3.2.17 which work perfectly on ruby 1.9 and see how well it works on 2.2. (java is not fully backwards compatible either, but it may be a bit more tolerant in some cases)
- briandear 11y ago
  Rails isn't ruby.
  - fuzzygroove 11y ago
    It's Ruby on Rails
  - yxhuvud 11y ago
    Did I claim that? However, it is written in ruby and as such it is a valid counterexample to the claim in the comment I commented on.
- breckenedge 11y ago
  I've done the work before to make rails 3.2 work on 2.2. I recall the problem is due to a breaking Bcrypt name change and Yaml serialization, and it's a one line patch. The maintainers are aware of the issue but held back so as to not break every 3.2 installation on a minor upgrade (would have to be called Rails 3.3 for semver?). Rails 4.0 isnt that hard of an upgrade path if you include the attraccessible gem.
  - yxhuvud 11y ago
    It took quite a while before rails released a version of 3.2 that worked. As for how fun upgrading to rails4 is, you obviously don't have a project with 200 database tables that has models using the attr_protected for the five columns (appwide) that actually need it. Forced whitelisting is not fun, regardless of if it is on model or controller level.

wpietri 11y ago

I'm not sure that's really true, but it regardless misses the point. No matter what language you're using, you'll eventually need to be able to deal with multiple versions of it. Even if you're running an operation small enough that you can upgrade every single runtime in use all in one step, you'll still need to have two versions around while you test. But many, many places have to deal with multiple language versions simultaneously. E.g., if you maintain an open source library and have any regard for your users, you have to test how it behaves in multiple language versions.

deleted 11y ago

[deleted]

yxhuvud 11y ago

No, Java is not fully backwards compatible. It may be more backwards compatible compared to ruby, but claiming that it is fully backwards compatible is simple false.