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

[Brian Goetz]

Yep, we're well aware of the friction this causes (and it affects us 
too, since the JDK contains a lot of code that manipulates bytecode, and 
uses ASM for some of it.)  This is something that we would eventually 
like to address, but the answer absolutely, positively, isn't "just 
standardize ASM."  We hope to have a better answer here eventually.

On 10/11/2019 2:31 PM, Mike Hearn wrote:
> 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 
> <mailto: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.
>
>