3 ms·

Add to this that multi-release JARs created a way for Java 9 to break your code even when you're staying on Java 8†, and it's pretty easy to see why long-time J

Add to this that multi-release JARs created a way for Java 9 to break your code even when you're staying on Java 8†, and it's pretty easy to see why long-time Java shops are jumpy. Things had been moving along relatively slowly and placidly for quite a long time, and then, all of a sudden, Java gets a bee in its bonnet and decides that it, too, needs to move fast and break things. † Admittedly only if you're getting feisty with run-time reflection fanciness. Which you probably shouldn't, in principle, be doing in the first place. But, in practice, it's pretty standard practice in Java.

pron 6y ago
Change is not made for the thrill, but because changing hardware, hosting, software requirements and changes in the wider software ecosystem demand it. Most of what Java broke and is about to break is the ability of libraries to too-strongly depend on implementation details -- what you admit you know is bad but do anyway; if every implementation detail is exposed and relied on, then the necessary changes cannot be made in a backward compatible way. In other words, Java is breaking the ability of libraries to break its backward compatibility. I'm sure this will require some adjustment, but is overall a better plan for backward compatibility in the long term than reducing investment in the platform and not coping with necessary change.
- mumblemumble 6y ago
  All of this is true. But avoiding change is not just knee-jerk stodginess, either. In a large, long-lived Java codebase, the cost to test for breaks can be immense. So you've got to convince yourself that the cost to stay on the old JDK is greater than the cost of moving to a new one. I think we can see from the Python 2->3 precedent that it's easy for new projects to adopt the new platform. That, in turn, incentivizes library maintainers to make the migration. But the only thing that will really motivate many business users to migrate is an end of support. Which, in Java 8's case, means we'll start seeing more movement as 2030 looms closer. That's an entirely rational business decision. 2030 is a long way away. Anything could happen on that kind of a time scale, including things that would render a migration past Java 8 a waste of resources, like the project being canceled or migrated off of Java entirely.
  - pron 6y ago
    True, some businesses will likely stay on 8 for as long as their application lasts, and this can certainly be a rational decision. But I completely reject the comparison to Python. The effort required to update from 8 to 9+ is nowhere near that of Python 2->3. Virtually all code runs unchanged... except for code that hacks into the JDK and depends on implementation details that have changed, which mostly exists in libraries. The snags are usually in libraries that have made some major API change 5 years ago that the application hasn't adapted to, and the old versions don't run on 9+ for some reason. So the obstacles are real, but it's not like the platform could have avoided them. In the future, such problems will hopefully be avoided when hacking into the JDK is blocked (which might happen as soon as JDK 16, due next March). The benefits are also quite different from the Python case. The hardware/hosting savings in recent versions compared to JDK can easily more than offset the cost of migration in a big number of cases if not the majority. If you upgrade to a new JDK you get money, possibly quite a lot. That wasn't the case with Python. So while there could be good reasons to stay on 8 for the lifetime of an application, the cost of upgrade is substantially lower, and the benefit is substantially higher than the case of Python (and by "substantially" I mean something like 10x).

pron 6y ago

Change is not made for the thrill, but because changing hardware, hosting, software requirements and changes in the wider software ecosystem demand it. Most of what Java broke and is about to break is the ability of libraries to too-strongly depend on implementation details -- what you admit you know is bad but do anyway; if every implementation detail is exposed and relied on, then the necessary changes cannot be made in a backward compatible way. In other words, Java is breaking the ability of libraries to break its backward compatibility. I'm sure this will require some adjustment, but is overall a better plan for backward compatibility in the long term than reducing investment in the platform and not coping with necessary change.

mumblemumble 6y ago
All of this is true. But avoiding change is not just knee-jerk stodginess, either. In a large, long-lived Java codebase, the cost to test for breaks can be immense. So you've got to convince yourself that the cost to stay on the old JDK is greater than the cost of moving to a new one. I think we can see from the Python 2->3 precedent that it's easy for new projects to adopt the new platform. That, in turn, incentivizes library maintainers to make the migration. But the only thing that will really motivate many business users to migrate is an end of support. Which, in Java 8's case, means we'll start seeing more movement as 2030 looms closer. That's an entirely rational business decision. 2030 is a long way away. Anything could happen on that kind of a time scale, including things that would render a migration past Java 8 a waste of resources, like the project being canceled or migrated off of Java entirely.
- pron 6y ago
  True, some businesses will likely stay on 8 for as long as their application lasts, and this can certainly be a rational decision. But I completely reject the comparison to Python. The effort required to update from 8 to 9+ is nowhere near that of Python 2->3. Virtually all code runs unchanged... except for code that hacks into the JDK and depends on implementation details that have changed, which mostly exists in libraries. The snags are usually in libraries that have made some major API change 5 years ago that the application hasn't adapted to, and the old versions don't run on 9+ for some reason. So the obstacles are real, but it's not like the platform could have avoided them. In the future, such problems will hopefully be avoided when hacking into the JDK is blocked (which might happen as soon as JDK 16, due next March). The benefits are also quite different from the Python case. The hardware/hosting savings in recent versions compared to JDK can easily more than offset the cost of migration in a big number of cases if not the majority. If you upgrade to a new JDK you get money, possibly quite a lot. That wasn't the case with Python. So while there could be good reasons to stay on 8 for the lifetime of an application, the cost of upgrade is substantially lower, and the benefit is substantially higher than the case of Python (and by "substantially" I mean something like 10x).