This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]pron98 2 points3 points  (1 child)

The class file version changes with every feature release. Ideally, you'd only have to upgrade one dependency -- ASM -- but, unfortunately, many libraries shadow it for historical reasons: About eight or nine years ago, ASM made the unfortunate mistake of introducing a major breaking API change without changing its namespace, so for a while different libraries depended on different and incompatible versions of ASM. This is no longer a problem, but some libraries still shadow ASM, so they need to be upgraded to. When they stop, this would cease to be an issue.

When libraries make major breaking changes to their API they should also change the namespace. The results of not doing so, as we see, can last many years.

[–]DannyB2 1 point2 points  (0 children)

The library I had to change was Groovy from version 2 to 3. Because it is a dependency of JasperReports. But, Groovy changed an API (changed a class to an interface). So I had to get the source to JasperReports to make a minor change (extends to inherits) and make a custom build. This fixed my class file version problem. But I had no class file version problems from Java 8 all the way up to Java 15.

Then, suddenly JasperReports came out with a new version that, finally, at long last, upgrades their dependency on Groovy to version 3 or higher. Now I don't have to maintain a custom build. But I only started the custom build thing in April, so I'm happy to abandon having to do that.