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

[Luke Hutchison]

Right, the fix (which I also suggested to my own users) is to forcibly
update the transitive dependency versions in Maven or Gradle, if you don't
directly depend upon the library yourself -- but most people don't seem to
know that you can do that, and it's not always possible (eg. for some forms
of shaded jars, where the package names for all classes of a dependency are
actually changed and rewritten with some prefix). I'm guessing that there
would be other unique complexities in JDK 9+ involving patching module
layers.



On Fri, Oct 11, 2019, 3:12 PM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- 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
>