[native_samples]

Typical reason for this is that JVM changed bytecode parsing in a backwards-incompatible way (yes this happens frequently e.g. to fix validation bugs) and the fix for this was then only rolled into a new version of the bytecode manipulation library, but that in turn had its own set of API changes, regressions and bugfixes, meaning that now whatever code sits on top has to be changed, etc.

Also most of the breaking changes from Java 8-11 are/were not spec changes. The spec leaves out many aspects of the Java platform that real apps rely on.

This idea that only apps that used JVM internals broke is totally wrong. I think the guys who work on Java think this because they don't actually use or work on any Java apps themselves beyond the ones that are a part of the JDK itself.

[chrisseaton]

Thanks. Have you got any example issues that are public on GitHub or something? I can't imagine changes in byte-code parsing for example that you'd hit if you were following the spec from the start.

[native_samples]

e.g. the validation of invokeinterface changed at some point in ways that broke common tools, if I recall correctly. I don't have bug links to hand right now. The JVM previously accepted something that it was later changed to reject. This often happens including in cases where it doesn't matter. See the Java 17 release notes about the change to validation of agentmain entry points for an example of the sort of thing that is done constantly, even where it isn't actually required by any other change.

People don't execute specs, they execute implementations. In the end whether something is or is not fully compliant with the spec doesn't change the costs involved in fixing it.

[avereveard]

Exactly, it's not always easy to replace a transitive dependency and we're dismissing the platform anyway