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

[Jorn Vernee]

On 12/10/2019 01:12, Maurizio Cimadamore wrote:
> I think a crucial point was hit earlier in this discussion; nearly 
> every complex piece of software out there relies on some classfile 
> library; if classfile version is updated often, classfile libraries 
> must also be updates often (as ASM does, thanks Remi). Which means 
> that _all_ software artifacts that depend on classfile libraries must 
> also be updates as often, or they risk being left behind. Which seems 
> to suggest that, if _some_ bytecode library was bundled in the JDK, as 
> noted earlier in this thread, the problem described here would be 
> mostly non-existent. As Brian said, this is a need that we anticipated 
> coming, and we hope to do something in this space.

On that last point; the perceived 'problem' is that the class file 
changes every 6 months. Fine, the reasons for that are sound, that's 
just how it is. One level above in the dependency chain we have bytecode 
libraries, which will also have to be updated every 6 months in order to 
keep up with the class file change. But! the bytecode library can nicely 
abstract the class file changes away if they are inconsequential to the 
user of the library. So far so good, and then we get to the real 
problem; libraries that have these frequently changing bytecode 
libraries as a dependency do not allow independently upgrading the 
bytecode library. Instead, we have to wait until the library that 
depends on the bytecode library is updated in it's entirety, which 
causes delays up the dependency chain.

At first glance, having a bytecode library in the JDK seems like a 
convenient vehicle for solving this problem, because most 
libraries/build systems already allow independently setting the JDK 
(.e.g Maven uses JAVA_HOME). But, having a dependency on a bytecode 
library inside the JDK might actually make this particular problem 
worse, since dependent libraries would have to support the entire new 
JDK release, instead of just the next release of the bytecode library.

Instead, libraries that depend on bytecode libraries _really ought to_ 
support upgrading this dependency separately, since it is known to need 
frequent, but hopefully non-breaking updates. The solution of pointing a 
build tool at the next version of the bytecode library seems like a good 
path to take. It is up to libraries depending on bytecode libraries to 
support this independent upgrade, as it's up to bytecode libraries to 
stay backwards compatible, as it's up to users to update the dependency 
every once in a while (preferably as soon as possible, so they can 
report problems to the authors of the problematic library).

Jorn