>Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java
This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively developed and Oracle will not even sell support for java 1, let alone release security updates.
Typically version N+1 of a language compiles version N, N-1, all the way back to version 1. Usually, when this isn't the case, the incompatible areas of a language were either marked experimental, or obscure use cases that very few people use.
Today's Java compiler will compile source code written for Java 1.
The issue with Python 2 and Python 3 is extremely unusual in a language.
An exerpt from the Compatibility Guide for JDK 8 [1]:
>In general, the source compatibility policy is to avoid introducing source code incompatibilities. However, implementation of some Java SE 8 features required changes that could cause code that compiled with Java SE 7 to fail to compile with Java SE 8. See Incompatibilities between Java SE 8 and Java SE 7 and Incompatibilities between JDK 8 and JDK 7 for information.
There are also a plethora of deprecated and removed APIs throughout Java's history.
After seeing the months- to years-long process that enterprises have undertaken when migrating from one JDK version to another because of these "obscure areas", I have little empathy for anyone delaying a python upgrade they've been given a 10+ year window for. Ruby 1.8 to 1.9 was similarly painful to python.
Exactly. People who think that the Python situation is normal don't have any experience with programming languages. C compilers can compile code that was written 40 years ago. Java can do this all the way to version 1. Python requires you to make an effort to chose the version of language you want, otherwise the tooling system won't let you run that code. It is true that they later created tools to help with this process, but the mere existence of such hackery shows only how poorly conceived the idea really was.
If you think that’s true, you haven’t supported enough legacy C code. Yes, the core language hasn’t changed much - like Python - but the includes, libraries, operating system APIs, etc. have - and that’s before you learn how vague compatibility was for code written before sometime in the 90s. Similarly, I’ve seen large Java projects take years to upgrade while comparability issues are sorted out.
In all cases, the real problem is technical debt management: rather than attacking people who gave you something for free, ask whether it’s possible that the experience has more to do with procrastinating on upgrades until many large changes have to be made at once with inadequate test automation.
Python 2 and 3 are different compiler/interpreters. Python 2 code might run on a Python 3 interpreter, but probably not. When you run your python2 code, you can specify that it is to run on the Python 2 compiler/interpreter. The Python 2 compiler/interpreter will continue to run and thus be able to run python2 code for a very long time.
This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively developed and Oracle will not even sell support for java 1, let alone release security updates.