9 ms·

I'm surprised that it's now common for software to require a certain (old) Java version. Wasn't the whole "write once run anywhere" promise about backwards com

I'm surprised that it's now common for software to require a certain (old) Java version. Wasn't the whole "write once run anywhere" promise about backwards compatibility too?

the8472 5y ago
That generally holds when you stick to public APIs. But there are many libraries that used reflection to access unstable internals. And that broke with modules.
- native_samples 5y ago
  No, it was more than that. Java has broken a ton of backwards compatibility in recent years. They stopped shipping a lot of stuff (like JavaFX), JavaEE stuff was removed from the JDK and then re-namespaced, they changed the formatting of the version number, they removed Web Start, they moved some stuff out of Unsafe, they changed how you access class files inside the JDK and so on. The idea that the only thing that changed was access to internals isn't really the case, but a lot of these changes were "allowed" because Java cares about compatibility with its own spec rather than specific popular apps.
  - josefx 5y ago
    > They stopped shipping a lot of stuff (like JavaFX), I thought they just split up the JDK into modules, making some libraries optional for a smaller footprint if you decided to ship your program with the JDK included. I am quite sure swing was also split of and all my toy programs still run despite that. > JavaEE stuff was removed from the JDK and then re-namespaced, JavaEE was never part of the standard JDK. Never used it, but you can probably still find the old java package somewhere. > they moved some stuff out of Unsafe out of sun.misc.Unsafe, an internal API of the Sun JDK that wasn't in the java namespace, wasn't documented and had nearly every IDE scream at you.
    - brabel 5y ago
      > I am quite sure swing was also split of and all my toy programs still run despite that. Swing is still distributed with the JDK, but JavaFX isn't. If you use JavaFX, you need to either add Maven dependencies on the JavaFX modules or compile with a JDK distribution which still includes JavaFX (e.g. jdk-fx from Azul: https://www.azul.com/downloads/?package=jdk-fx https://www.azul.com/downloads/?package=jdk-fx).
pram 5y ago
Tried running a Java applet recently? ;P
- msgilligan 5y ago
  The answer to this question is almost certainly "no". It is ironic that what was originally the most hyped feature of Java has now been removed. But nobody is going to miss it.
  - lucumo 5y ago
    I worked on one this year. You need Java 8 for it and an insanely old browser. They didn't mention the applet part in the job description. That was my shortest tenure ever, including Summer jobs and internships...
    - msgilligan 5y ago
      Ugh. Sounds horrible.
    - vbezhenar 5y ago
      Some applets could be launched with javaws, but it would require some tinkering to extract proper jnlp file from HTML or JavaScript. I managed to do so with HP iLO remote KVM app.
      - marwis 5y ago
        javaws was also removed =)
        vbezhenar 5y ago
        Need to use old Java, yep. Not as painful as using old browser.
  - tablespoon 5y ago
    >> Tried running a Java applet recently? ;P > The answer to this question is almost certainly "no". For me, it's a yes. My employer uses some ancient monitoring application called SiteScope. They recently "upgraded" from an ancient version to a newer one (I think the latest), and nearly the whole frontend appears to be implemented as a Java Applet. Since no browser on the Mac supports Applets anymore, their workaround was to download some Java App that ran the UI. The older version we had used HTML.
NovemberWhiskey 5y ago
At the byte code level, maybe - but any language as large as Java is (over the course of 20+ years) going to have changes to its libraries, including deprecations / removals.
msgilligan 5y ago
It's common to require a certain old Java version or newer. In general Java is extremely backward compatible. There have been a few minor breaking changes from JDK 8 to JDK 17, but the worst ones have had command-line options to disable them. Maybe you're referring to JEE and/or specific "enterprise" software which does tend to move much more slowly.
- colechristensen 5y ago
  I’ve run into several performance regressions from 8 -> 11 -> beyond Code still worked but services would easily get overloaded, there would be one piece of code which ran crazy slow, or new memory issues would come up. It absolutely is not just safe to jump versions in production, usually it’s been weeks of testing finding and fixing perf bugs.
  - msgilligan 5y ago
    Yes, what you describe is entirely believable. And one of the legitimate reasons why enterprise software is slow to upgrade.
- technion 5y ago
  This really hasn't been consistent with my experience as an end user. I have POS software that will blow up if any POS terminal applies a minor point release update on any terminal. I have current PMS software from Oracle that will infinitely NullPointerException if upgrade to a currently supported version of Oracle's JRE. It's going back a few years but I remember backups being unreadable if you upgraded JRE on a Backup Exec server.
pabl0rg 5y ago
Yes. But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. I’m not surprised that people seem to be leaving the ecosystem.
- oauea 5y ago
  > It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. > I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. Could you clarify what you ran into? Why docker? I'll have to do this soon.
  - Alupis 5y ago
    Specifically, a ton of used-to-be-included in the standard JDK things like nearly all XML processing are now broken out into modules or require maven dependencies, etc. So it's not "turn-key" to upgrade to jdk 9 or above, like say, 6 -> 7 -> 8 was. Sounds simple... "just add it to your maven deps!" - but in practice it's more complicated than that and requires careful planning and testing. Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. Java 9 created quite a mess. Once you finish that upgrade though, moving into Java 11 or anything newer is basically turn-key like it was before. But, this had the effect of many companies staying with Java 8 until forced to upgrade.
    - _hilro 5y ago
      from OP > Could you clarify what you ran into? Why docker? Not sure I follow why you had to turn to docker > Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. The JVM is deterministic - I don't follow this statement?
osrec 5y ago
I know it does happen, but I wouldn't say it's common. Generally speaking, most of the software I use runs without issues on newer JVMs, despite being built for an old one.
_pmf_ 5y ago
All desktop software I knew around 2009 already used a bundled JRE.
paulmd 5y ago
Oracle moved away from their "free" license to requiring a $100 or $200 per seat license for home users (and I think even more for business users), so the clock stopped ticking at Java 8u202 for a lot of people who refused to (or couldn't) move to OpenJDK. edit: although this appears to have recently changed! https://blogs.oracle.com/java/post/free-java-license https://blogs.oracle.com/java/post/free-java-license It was really a terrible idea from a security perspective - and unfortunately there are organizations that won't consider software without a support contract.
gdsdfe 5y ago
Java 8 was out 7 years ago ... That's like century in the software world
EdwardDiego 5y ago
The big issue is around four things: 1) Certain libraries that were part of the JDK being moved out of the JDK, which usually required adding them as a module or dependency in $BUILD_TOOL_INSTRUCTIONS_FILE 2) Internal JVM APIs that weren't public being used via reflection by clever libraries, and then when they change, those libraries break 3) Bytecode emitting libraries - various frameworks love these, but bytecode that worked for Java 8 can fail on Java 9. Hence Spring 4 only supports JDKs 6 - 8. So to move to JDK 9+, you had to upgrade Spring to 5.x, and things that were tied to your version of Spring... and this process can very often suck. 4) New versions of library X only being available in class formats that Java 8 can't run. I encountered this with Jetty - version 10+ only support Java 11+, so if you're stuck on Java 8, you're limited to bug fix releases on the last version that supported Java 8. Since Java 9, the JVM has been warning if you use internal APIs. As of Java 17, they have started enforcing strong encapsulation of those APIs ("private means private yo"), to give the JDK freedom to evolve without worrying about every library that got clever with the internals of the JVM. But given the very long lead time and ample messaging on this, I don't expect Java 17 breaking too many things. At my last job, we had a rather large monolithic build that was tied to Java 8 because some modules would die a horrible death when compiled with or for a higher version Java. So I introduced Maven and Gradle toolchains[1] so that individual modules could compile using their preferred Java version, which freed up new modules/apps to use Java >8 as they saw fit. All the legacy apps that broke on Java 9+ could stay on 8, but the rest of the project was freed from their legacy crap. [1]: https://docs.gradle.org/current/userguide/toolchains.html https://docs.gradle.org/current/userguide/toolchains.html
magpi3 5y ago
Write once test everywhere was the problem. If you wanted a fully tested app, you have to bundle a JRE, and if you are bundling a JRE then backward compatibility is not as important.
stockerta 5y ago
Taht never worked. I had to use a goverment java web applet that run on only one exact java version, down to the patch level. Anything else, it didn't work. And also that java version was already out of date, so every browser was crying about it. fsck java.

I'm surprised that it's now common for software to require a certain (old) Java version. Wasn't the whole "write once run anywhere" promise about backwards compatibility too?

the8472 5y ago

That generally holds when you stick to public APIs. But there are many libraries that used reflection to access unstable internals. And that broke with modules.

native_samples 5y ago
No, it was more than that. Java has broken a ton of backwards compatibility in recent years. They stopped shipping a lot of stuff (like JavaFX), JavaEE stuff was removed from the JDK and then re-namespaced, they changed the formatting of the version number, they removed Web Start, they moved some stuff out of Unsafe, they changed how you access class files inside the JDK and so on. The idea that the only thing that changed was access to internals isn't really the case, but a lot of these changes were "allowed" because Java cares about compatibility with its own spec rather than specific popular apps.
- josefx 5y ago
  > They stopped shipping a lot of stuff (like JavaFX), I thought they just split up the JDK into modules, making some libraries optional for a smaller footprint if you decided to ship your program with the JDK included. I am quite sure swing was also split of and all my toy programs still run despite that. > JavaEE stuff was removed from the JDK and then re-namespaced, JavaEE was never part of the standard JDK. Never used it, but you can probably still find the old java package somewhere. > they moved some stuff out of Unsafe out of sun.misc.Unsafe, an internal API of the Sun JDK that wasn't in the java namespace, wasn't documented and had nearly every IDE scream at you.
  - brabel 5y ago
    > I am quite sure swing was also split of and all my toy programs still run despite that. Swing is still distributed with the JDK, but JavaFX isn't. If you use JavaFX, you need to either add Maven dependencies on the JavaFX modules or compile with a JDK distribution which still includes JavaFX (e.g. jdk-fx from Azul: https://www.azul.com/downloads/?package=jdk-fx https://www.azul.com/downloads/?package=jdk-fx).

pram 5y ago

Tried running a Java applet recently? ;P

msgilligan 5y ago
The answer to this question is almost certainly "no". It is ironic that what was originally the most hyped feature of Java has now been removed. But nobody is going to miss it.
- lucumo 5y ago
  I worked on one this year. You need Java 8 for it and an insanely old browser. They didn't mention the applet part in the job description. That was my shortest tenure ever, including Summer jobs and internships...
  - msgilligan 5y ago
    Ugh. Sounds horrible.
  - vbezhenar 5y ago
    Some applets could be launched with javaws, but it would require some tinkering to extract proper jnlp file from HTML or JavaScript. I managed to do so with HP iLO remote KVM app.
    - marwis 5y ago
      javaws was also removed =)
      - vbezhenar 5y ago
        Need to use old Java, yep. Not as painful as using old browser.
- tablespoon 5y ago
  >> Tried running a Java applet recently? ;P > The answer to this question is almost certainly "no". For me, it's a yes. My employer uses some ancient monitoring application called SiteScope. They recently "upgraded" from an ancient version to a newer one (I think the latest), and nearly the whole frontend appears to be implemented as a Java Applet. Since no browser on the Mac supports Applets anymore, their workaround was to download some Java App that ran the UI. The older version we had used HTML.

NovemberWhiskey 5y ago

At the byte code level, maybe - but any language as large as Java is (over the course of 20+ years) going to have changes to its libraries, including deprecations / removals.

msgilligan 5y ago

It's common to require a certain old Java version or newer. In general Java is extremely backward compatible. There have been a few minor breaking changes from JDK 8 to JDK 17, but the worst ones have had command-line options to disable them. Maybe you're referring to JEE and/or specific "enterprise" software which does tend to move much more slowly.

colechristensen 5y ago
I’ve run into several performance regressions from 8 -> 11 -> beyond Code still worked but services would easily get overloaded, there would be one piece of code which ran crazy slow, or new memory issues would come up. It absolutely is not just safe to jump versions in production, usually it’s been weeks of testing finding and fixing perf bugs.
- msgilligan 5y ago
  Yes, what you describe is entirely believable. And one of the legitimate reasons why enterprise software is slow to upgrade.
technion 5y ago
This really hasn't been consistent with my experience as an end user. I have POS software that will blow up if any POS terminal applies a minor point release update on any terminal. I have current PMS software from Oracle that will infinitely NullPointerException if upgrade to a currently supported version of Oracle's JRE. It's going back a few years but I remember backups being unreadable if you upgraded JRE on a Backup Exec server.

pabl0rg 5y ago

Yes. But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. I’m not surprised that people seem to be leaving the ecosystem.

oauea 5y ago
> It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. > I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. Could you clarify what you ran into? Why docker? I'll have to do this soon.
- Alupis 5y ago
  Specifically, a ton of used-to-be-included in the standard JDK things like nearly all XML processing are now broken out into modules or require maven dependencies, etc. So it's not "turn-key" to upgrade to jdk 9 or above, like say, 6 -> 7 -> 8 was. Sounds simple... "just add it to your maven deps!" - but in practice it's more complicated than that and requires careful planning and testing. Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. Java 9 created quite a mess. Once you finish that upgrade though, moving into Java 11 or anything newer is basically turn-key like it was before. But, this had the effect of many companies staying with Java 8 until forced to upgrade.
  - _hilro 5y ago
    from OP > Could you clarify what you ran into? Why docker? Not sure I follow why you had to turn to docker > Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. The JVM is deterministic - I don't follow this statement?

osrec 5y ago

I know it does happen, but I wouldn't say it's common. Generally speaking, most of the software I use runs without issues on newer JVMs, despite being built for an old one.

_pmf_ 5y ago

All desktop software I knew around 2009 already used a bundled JRE.

paulmd 5y ago

Oracle moved away from their "free" license to requiring a $100 or $200 per seat license for home users (and I think even more for business users), so the clock stopped ticking at Java 8u202 for a lot of people who refused to (or couldn't) move to OpenJDK. edit: although this appears to have recently changed! https://blogs.oracle.com/java/post/free-java-license https://blogs.oracle.com/java/post/free-java-license It was really a terrible idea from a security perspective - and unfortunately there are organizations that won't consider software without a support contract.

gdsdfe 5y ago

Java 8 was out 7 years ago ... That's like century in the software world

EdwardDiego 5y ago

The big issue is around four things: 1) Certain libraries that were part of the JDK being moved out of the JDK, which usually required adding them as a module or dependency in $BUILD_TOOL_INSTRUCTIONS_FILE 2) Internal JVM APIs that weren't public being used via reflection by clever libraries, and then when they change, those libraries break 3) Bytecode emitting libraries - various frameworks love these, but bytecode that worked for Java 8 can fail on Java 9. Hence Spring 4 only supports JDKs 6 - 8. So to move to JDK 9+, you had to upgrade Spring to 5.x, and things that were tied to your version of Spring... and this process can very often suck. 4) New versions of library X only being available in class formats that Java 8 can't run. I encountered this with Jetty - version 10+ only support Java 11+, so if you're stuck on Java 8, you're limited to bug fix releases on the last version that supported Java 8. Since Java 9, the JVM has been warning if you use internal APIs. As of Java 17, they have started enforcing strong encapsulation of those APIs ("private means private yo"), to give the JDK freedom to evolve without worrying about every library that got clever with the internals of the JVM. But given the very long lead time and ample messaging on this, I don't expect Java 17 breaking too many things. At my last job, we had a rather large monolithic build that was tied to Java 8 because some modules would die a horrible death when compiled with or for a higher version Java. So I introduced Maven and Gradle toolchains[1] so that individual modules could compile using their preferred Java version, which freed up new modules/apps to use Java >8 as they saw fit. All the legacy apps that broke on Java 9+ could stay on 8, but the rest of the project was freed from their legacy crap. [1]: https://docs.gradle.org/current/userguide/toolchains.html https://docs.gradle.org/current/userguide/toolchains.html

magpi3 5y ago

Write once test everywhere was the problem. If you wanted a fully tested app, you have to bundle a JRE, and if you are bundling a JRE then backward compatibility is not as important.

stockerta 5y ago

Taht never worked. I had to use a goverment java web applet that run on only one exact java version, down to the patch level. Anything else, it didn't work. And also that java version was already out of date, so every browser was crying about it. fsck java.