4 ms·

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 imme

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

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).