4 ms·

When was this true ? I remember since forever the "DON'T UPGRADE JVM ON THIS SERVER" notices since Java 5-6 days. Hell I've seen a case where a minor update wo

When was this true ? I remember since forever the "DON'T UPGRADE JVM ON THIS SERVER" notices since Java 5-6 days. Hell I've seen a case where a minor update would break a production app. And I don't even do Java development. Not to mention android and gradle being broken and randomly failing to work between different JVM versions - depending on the gradle flavour of the day. I don't really see JVM as a pillar of stability and backwards compatibility.

martontoth 6y ago
Thats not a JVM, but an application/library level issue. The JVM ABI has been stable for quite some time.
- reader_mode 6y ago
  I see limited value in that when JVM ships with frameworks which break compatibility regularly - I doubt Python packages which had no dependencies on core libraries had any problems using 2to3 to migrate.
  - overtomanu 6y ago
    can you give examples?
  - pjmlp 6y ago
    Other than a few breaking changes in JDBC, there was hardly any other breaking change in the standard library. And modules was a single breaking change, hardly a regular thing.
- toast0 6y ago
  What's the difference? I still can't run my existing jar with a new JVM package; so the new JVM package isn't compatible with old binaries. And I have to horde old installers if I want specific programs to work (thankfully, I only have one or maybe two Java programs I'd like to run)
kaba0 6y ago
That’s just false. There have been some minor changes over the last 25 years, but the jvm will run a jar file compiled with a really old javac just fine, and I think you would be hard-pressed to find any platform with even a remotely similar level of stability and backward compatibility. The don’t upgrade thing on the server is a generally wanted stable environment, or do you upgrade libc in prod without testing it first? Also, it happens mostly in banks and other not-too technically up-to-date places that often times depend on bugs themselves. Trailing the latest OpenJDK is the best thing one can do. Also, android is not/barely Java.
- pjmlp 6y ago
  Android Java is Google's J++ and should be dealt the same way as J++ was.
- reader_mode 6y ago
  What are you talking about ? I had a problem with Gradle failing to work with OpenJDK a while ago [1] and the solution was to downgrade. We literally had software in production that wouldn't work when you upgraded the JVM and their official documentation said it wouldn't work if you updated and you were unsupported (and IIRC downgrading was also a PITA) - this was in JVM 5 -> JVM 6 days which AFAIK was a big change (TBH I don't know back then I didn't do app development I did system integration). [1] https://github.com/gradle/gradle/issues/8681 https://github.com/gradle/gradle/issues/8681
  - kaba0 6y ago
    First of all, gradle is mostly groovy, not java. Second, I didn’t say it is in every single case backward compatible, since that is impossible in a continuously evolving platform. But there are really few “user”-facing changes in the JVM. And so I still state that calling the JVM non-stable (for which you provided no evidence), or non-backward compatible is simply false. Please tell me a platform which is stable/backward compatible according to you to at least this degree. (Also, we are at java 16!, java 5, 6 is so old that it is not particularly telling about anything)

martontoth 6y ago

Thats not a JVM, but an application/library level issue. The JVM ABI has been stable for quite some time.

reader_mode 6y ago
I see limited value in that when JVM ships with frameworks which break compatibility regularly - I doubt Python packages which had no dependencies on core libraries had any problems using 2to3 to migrate.
- overtomanu 6y ago
  can you give examples?
- pjmlp 6y ago
  Other than a few breaking changes in JDBC, there was hardly any other breaking change in the standard library. And modules was a single breaking change, hardly a regular thing.
toast0 6y ago
What's the difference? I still can't run my existing jar with a new JVM package; so the new JVM package isn't compatible with old binaries. And I have to horde old installers if I want specific programs to work (thankfully, I only have one or maybe two Java programs I'd like to run)

kaba0 6y ago

That’s just false. There have been some minor changes over the last 25 years, but the jvm will run a jar file compiled with a really old javac just fine, and I think you would be hard-pressed to find any platform with even a remotely similar level of stability and backward compatibility. The don’t upgrade thing on the server is a generally wanted stable environment, or do you upgrade libc in prod without testing it first? Also, it happens mostly in banks and other not-too technically up-to-date places that often times depend on bugs themselves. Trailing the latest OpenJDK is the best thing one can do. Also, android is not/barely Java.

pjmlp 6y ago
Android Java is Google's J++ and should be dealt the same way as J++ was.
reader_mode 6y ago
What are you talking about ? I had a problem with Gradle failing to work with OpenJDK a while ago [1] and the solution was to downgrade. We literally had software in production that wouldn't work when you upgraded the JVM and their official documentation said it wouldn't work if you updated and you were unsupported (and IIRC downgrading was also a PITA) - this was in JVM 5 -> JVM 6 days which AFAIK was a big change (TBH I don't know back then I didn't do app development I did system integration). [1] https://github.com/gradle/gradle/issues/8681 https://github.com/gradle/gradle/issues/8681
- kaba0 6y ago
  First of all, gradle is mostly groovy, not java. Second, I didn’t say it is in every single case backward compatible, since that is impossible in a continuously evolving platform. But there are really few “user”-facing changes in the JVM. And so I still state that calling the JVM non-stable (for which you provided no evidence), or non-backward compatible is simply false. Please tell me a platform which is stable/backward compatible according to you to at least this degree. (Also, we are at java 16!, java 5, 6 is so old that it is not particularly telling about anything)