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

[Remi Forax]

----- Mail original -----
> De: "Luke Hutchison" <luke.hutch at gmail.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Vendredi 11 Octobre 2019 22:51:41
> Objet: Re: Please stop incrementing the classfile version number when there are no format changes

> On Fri, Oct 11, 2019 at 2:21 PM Brian Goetz <brian.goetz at oracle.com> wrote:
> 
[...]

> ASM works hard to have a release ready for JDK N by the time JDK is
>> ready to ship.  If other bytecode libraries want to play in this space,
>> that's the bar, and it's a reasonable one.  It's not like changes to the
>> classfile format aren't broadly discussed in public forums for a long
>> time prior to making a change.  The ASM guys have figured out what good
>> citizenship looks like here (thanks Remi!); other libraries should take
>> a page from their book.
>>
> 
> One of the biggest sources of user disruption are N-step dependencies,
> where N>1. Many bugs have been reported against ClassGraph that were
> already fixed, by users who run into a bug due to depending upon library X
> which itself depends upon an old version of ClassGraph. This happened
> specifically, about three times, in the case of the bump to JDK 9, which
> introduced the new constant pool tag types I mentioned. To your point, ASM
> ran into this problem with many downstream dependencies for the same
> reason, again due to second- or nth-degree dependencies (I saw at least a
> couple of GitHub bug reports and a several different StackOverflow
> questions about exactly this issue, over a year after JDK 9 was released,
> because it took a very long time for the Java ecosystem to upgrade to ASM
> 6.0 beta or later).  Even fixing the core issue in the concerned library
> does not always fix the issue for the entire ecosystem, because literally
> every library, and its entire transitive dependency graph, have to be fixed
> every time there's a bump in version that either breaks something, or
> because the library throws an exception because the version number has been
> bumped. And very frequently, to fix an issue (such as bumping the version
> number for the ASM dependency), you have to do a lot of work to adopt to a
> new API or to fix other breakage. You simply cannot expect the entire Java
> ecosystem to upgrade all transitive dependency chains every 6 months,
> that's just not the level of efficiency that the broader ecosystem operates
> under. This is why it is very important to incur as little disruption as
> possible, and to make libraries as backwards- and forwards-compatible as
> possible.
> 
> Throwing an exception just because a library "might" not handle a file only
> causes havoc. See also: https://en.wikipedia.org/wiki/Robustness_principle

This is the part if don't get, you can use a newer version of ASM without having to update all your dependencies because inside ASM we force our user to specify which version of ASM they want to use, so you can use the latest release of ASM with a code that believe you are using ASM4 because when creating the visitors you will ask for the ASM4 API.

So you don't have to wait until all your transitive dependencies are updated.

regards,
Rémi