Please stop incrementing the classfile version number when there are no format changes (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Sat Oct 12 16:45:09 UTC 2019

On 12/10/2019 13:07, Mike Hearn wrote:

:

Finally, there's a more general observation to make on backwards compatibility. In the 1990s Microsoft became famous for bending over backwards to keep running code, even if it was buggy or totally unreasonable. With the internet this intensity slackened because vendors could release new versions to users, but only a little bit - companies go bankrupt and projects become unmaintained. Java today is backwards compatible in theory but not in practice. Every release breaks something, often something fundamental like our build systems. If OpenJDK is serious about wanting users to upgrade every six months then the backwards compatibility philosophy will need to change to be like Microsoft's: remove the constructor /after/ Groovy accepted a patch to stop using it, not before. I don't know if you have the full context here or not. This is not about removing a constructor from the API, instead the change was to the signature of a private constructor. It's way too fragile to have important tools or libraries hacking into private fields or other members and expecting them to work from release to release (even build to build!). Also remember that the JDK has been emitting warnings at run-time since JDK 9 to help identify code like this.

On your more general point then it would be very unfair to suggest that that there isn't a culture of compatibility in this project. The effort that goes into maintaining compatibility is incredible to observe at times. Every major feature has to painstakingly work through the implications on every other part of "the system". Small changes too where experienced committers and reviewers need to take compatibility into account when reviewing a change. Then there is the Compatibility & Specification Review (CSR) group that is the review body to review all changes that have potential compatibility issues. Despite the heroic efforts there will be bugs and compatibility issues that slip through. This is where this project depends on a larger cohort of developers to help by trying out their libraries, tools, and other existing code to find issues, ideally long before GA. In the case of TLS 1.3 (which was a massive project, several person years of effort, several supporting JEPs) there was great help on security-dev from several projects and individuals and many bugs were reported and fixed. Somehow we need to dial up this participation a hundredfold and catch more issues before GA, not after GA. I think it will only work if the maintainers of all the main stream tools and libraries are willing to get involved and not wait for a release to GA before adding support.

-Alan

More information about the jdk-dev mailing list