JEP 484: Class-File API (JDK 24)

[homedirectory]

What is the ByteBuddy's approach to using the Class-File API introduced in JDK 24?
The project's README says that there is some ongoing integration with this new API:

Integration to the JDK's Class File API is contained in multi-release folders for version 24 and later. These folders can be stripped without consequence, other than loosing support for the Class File API.

However, I haven't been able to find anything else related to this integration.

I assume that the total replacement of ASM by the Class-File API is not a goal.

I understand that ASM and the Class-File API are two distinct APIs. Then, what would an integration with the Class-File API look like?
A second implementation of ByteBuddy's API? (This does not make sense to me.)
Or an extension to the ByteBuddy's API that enables the use of the Class-File API, similarly to how it is currently possible to write your own low-level ASM visitors?

[raphw]

It's using this bridge: https://github.com/raphw/asm-jdk-bridge

But ASM is used as the API. I don't have any plans to migrate, the change would be to disruptive, but as an engine, you can already use it and it's used by any version that ASM does not support by default.

[homedirectory]

What are the benefits of using the Class-File API as an engine?

According to the JEP, one of the advantages of the Class-File API is the ability to evolve simultaneously with the JDK, which is due to the fact that the API will be maintained by JDK developers, as opposed to using a third-party library.

The JDK has its own class-file library inside the javac compiler. It also bundles ASM to implement tools such as jar and jlink, and to support the implementation of lambda expressions at run time. Unfortunately, the JDK's use of a third-party library causes a tiresome delay in the uptake of new class-file features across the ecosystem. The ASM version for JDK N cannot finalize until after JDK N finalizes, so tools in JDK N cannot handle class-file features that are new in JDK N, which means javac cannot safely emit class-file features which are new in JDK N until JDK N+1. This is especially problematic when JDK N is a highly anticipated release such as JDK 21, and developers are eager to write programs that entail the use of new class-file features.

I do not understand what it means to "finalize" an ASM version. Regardless, the point being made is: "use of a third-party library causes a tiresome delay in the uptake of new class-file features across the ecosystem".

Given that ByteBuddy has previously depended on ASM alone for the support of new class-file features, does the integration of the Class-File API reap the benefits quoted above?
I fail to see how, since ASM remains in the role of the API, thereby setting ByteBuddy's pace for supporting new class-file features.

[raphw]

The advantage of using the Class File API is that one can be certain that the class file is parsed correctly, which ASM cannot as it cannot anticipate what changes future versions will bring. Most of the time, there are none, and using the Class File API can assure this whereas ASM cannot. This way, there is no longer a need to update Byte Buddy to run on a newer JDK, unless there is a new byte code concept being introduced.

If a new byte code or class file concept is introduced, one does however need to update. The existance of the class file API does not change that.

[homedirectory]

I see. Using the bridge in this repository, ByteBuddy will always link with the active JDK's version of the Class-File API, so there is indeed no need to update ByteBuddy if new class-file features are not of interest.

Regarding the introduction of new class-file features, where one does need to update, ByteBuddy will have to wait for the ASM API to evolve first, despite the Class-File API having already been updated by the JDK team.

[raphw]

That is exactly right.

[01es]

Thank you, gents, for an excellent discussion and for clearly explaining the relationship between AMS and the Class-File API as they are used in ByteBuddy. This information is very useful.