> OpenJDK's backwards-compatibility breaking crusade.

First, Java has always been very explicit about where it offers backward compatibility and where it does not. You cannot break backward compatibility where it must not be expected. These are classes that carry a warning saying: these are internal classes that offer no kind of backward compatibility and can be changed at any time and without warning; by depending on them you are accepting upon yourself the responsibility to respond to any change. Nevertheless, in most situations we are offering plenty of advance warning.

Second, the "crusade" isn't done to break anything or against anyone, but because these internal and not-backward-compatibility-breaking changes are necessary to offer Java users the features they're asking for, which, in turn, rely on integrity [1]. We're talking about changes to the very core assumptions of the platform, which could violate any invariant and have a global impact, that could have been made by any code in any transitive library. In order to offer certain features the platform must know which of its invariants it may trust (for example, the JIT compiler cannot perform certain optimisations that assume strings are immutable because even though it is an invariant of the platform, some third-level dependency could have decided that actually strings would be mutable in any application that consumes this library).

Nevertheless, the platform does not prevent code from choosing to violate integrity invariants. It just prevents libraries from doing so -- which has a global effect on the application -- without the application's knowledge.

> "For security" without being particularly clear about how that update contributes to security.

The changes I was referring to above (deep reflection, Unsafe, JNI/FFM, dynamic agents) are about integrity, not security (you can think of integrity as a generalisation of memory safety, which is a special case of integrity; it is not security in itself, but it can make security easier). We are very clear both about that and about the relationship between integrity and security [1].

As far as this particular change to annotation processing, however -- a change I'm not personally involved with and don't know the specifics of -- the email does mention security as the motivation. It has been a long-standing policy of the JDK team (as well as that of many other projects) not to disclose any specifics about any vulnerabilities involved. OpenJDK has a specialised vulnerability group [2], made up of people from multiple companies, and they are given access to the vulnerabilities.

> It's sort of like stating that security is improved by ensuring that it is no longer possible to open the front door from inside the house without a key. Seems nice - but, they're... already inside the house.

Yeah, one, it's not about security but about integrity -- as explained in the motivation [1] -- which is, indeed, essential for security but for other important things as well, and two, your security analysis is just wrong. That is why for security is best to rely on security experts and not on people unfamiliar with the field who go by what seems to make sense to them.

> if you are running malicious code inside a JVM, we've got much, much bigger problems.

Benevolent, well-meaning code with unintended vulnerabilities is a far bigger security problem than malicious code in server applications. Malicious code is a common problem on the client, but benevolent code is the bigger danger on the server, so if you start thinking about what it is that malicious code could do you know you're thinking in the wrong direction.

[1]: https://openjdk.org/jeps/8305968

[2]: https://openjdk.org/groups/vulnerability/