Please stop incrementing the classfile version number when there are no format changes

[Alan Bateman]

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