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

[Mike Hearn]

A thought that just occurred to me is that this problem is really caused by
ASM being separate from the JDK. If ASM was a standard java.lang.bytecode
API instead of a third party library, then Java upgrades wouldn't trigger
version skew asserts and the problem would largely vanish given ASM's
ubiquity.

The general problem isn't really specific to ASM of course - any time a
dependency very low down in the dependency pyramid needs to be changed it
takes forever, because you may have to push it up through three, four or
even five levels of dependencies, each with their own releases and which
may be abandoned or require forking. But fortunately most libraries don't
break on every Java upgrade: just ASM. It could be seen as a special case.



On Fri, Oct 11, 2019 at 20:23:28, Mike Hearn <mike at plan99.net> wrote:

> OK. I understand your point that the policy has in some sense not changed.
> But from the user's view the effect is quite different: during the Java 8
> timeframe there were years of upgrades and bug fixes that didn't change the
> class file format and which were essentially drop-in. But now every six
> months of improvements/bugfixes does change it, so if something can't
> handle the new version that's a constant series of upgrade problems, rather
> than once every few years as before.
>
> As Cedric has noted (I should have mentioned this), Gradle isn't ready to
> release  Java 13 compatibility because ASM is really a dependency of
> Groovy, which in turn has rolled the new ASM into a general upgrade which
> may have regressions. It wasn't released as a point release. And then
> Gradle 6 is itself a new major release which may break builds because of
> the removal of deprecated APIs and so on. This pattern is common -
> supporting new versions of Java isn't treated like a security hotfix but
> rather, as a feature to be released with all the others.
>
> Also, this isn't unique to Gradle. We use Quasar, and we use ASM directly,
> and I think we use other libraries that also incorporate ASM snapshots in
> various ways, so we end up with ASM dependencies in quite a few places. All
> of these have to be upgraded in sync to support Java 13.
>
> So in theory Java 13 is backwards compatible with 12 and should be able to
> run existing projects. But in practice, because of a single version assert
> in ASM, it could be quite a while before we can actually upgrade and it
> will require a lot of work to propagate the change up through the giant
> dependency pyramid we sit on top of. Actually we still haven't managed to
> ship Java 11 support in our project yet, as it took months of work by a
> dedicated developer (it should be in our next release but of course, 11 is
> already obsolete). I think many projects will be in similar situations;
> bytecode manipulation/synthesis is just so widely used throughout the
> ecosystem that any time it breaks it causes a big bubble in the upgrade
> pipeline.
>