Hacker News new | ask | show | jobs
by avereveard 1737 days ago
A lot of bcel/aspect code had to be rewritten. I've had to patch a couple transitive dependencies to bring a 2018 platform from Java 1.8 into Java 12 land, and it's stuck there forever since after 12 something else it depended on was removed. We're migrating to a simpler, saner runtime, but still, stuff takes time.
1 comments
chrisseaton 1737 days ago
> A lot of bcel/aspect code had to be rewritten.

But why? What changed in the spec that forced a rewrite?

link
native_samples 1737 days ago
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.

link
chrisseaton 1736 days ago
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.
link
native_samples 1736 days ago
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.

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