Classparser API

[Michael Bien]

I feel the new cadence only put the spotlight on an issue which was 
there for a long time already. If you have a dusty project using common 
dependencies like spring, google guice, apache struts and eclipselink, 
you already have four different versions of asm in it. Because 
frameworks began at a certain point to repackage their own copy of asm 
under a different namespace.

This makes JDK upgrades more "interesting" than they should be. Things 
like taking loom for a spin is often not possible unless you are working 
on a green field project.

best regards,
michael

On 22.09.20 20:15, Remi Forax wrote:
> Hi Robert,
>
> Yes, ASM 9 was released this morning, as a meagre consolation, it seems the classfile will not change in the next releases until the introduction of Valhalla.
>
> And yes, the new release cadence has some ripple effects but at the same time, it's not a reason to not try to streamline a little more the release process of any Apache projects.
> After all, we are in 2020, releasing a software or a library should be something casual and not an exceptional daunting task.
>
> regards,
> Rémi
>
> ----- Mail original -----
>> De: "Robert Scholte" <rfscholte at apache.org>
>> À: "jdk-dev" <jdk-dev at openjdk.java.net>
>> Envoyé: Mardi 22 Septembre 2020 19:23:25
>> Objet: Classparser API
>> With the new release of Java followed by a new release of ASM comes a returning
>> task where some of our Maven plugins and libraries should update this
>> dependency. They make use of the classfile parser, the upgrade is required to
>> understand the new bytecode version.
>>
>> Due to the Apache Software Foundation Policy (for legal reasons) every release
>> comes with an amount of overhead. Doing a release for just a single dependency
>> update to ease the usage for Maven users has always felt awkward.
>>
>> Is there any chance that the JDK will be extended with an API for parsing
>> classfiles?
>>
>> thanks,
>> Robert Scholte