Consider ClassFile API for reading class metadata from bytecode

[bclozel]

Spring Framework currently shades ASM for several features:

1. bytecode generation with cglib
2. reading class metadata from bytecode

Our usage of ASM is not a problem these days and we tend to allow use of up-to-date JDK versions in Spring apps thanks to swift upgrades of our shaded version. Still, we should consider our options with the new ClassFile API.

Spring Framework maintains two implementations of metadata reading: one based on Class reflection (org.springframework.core.type.StandardClassMetadata) and another one based on bytecode reading with ASM (org.springframework.core.type.classreading.SimpleMetadataReaderFactory). This API does not expose any ASM type and is a good use case for the ClassFile API.

The ClassFile API JEP 457 is currently in preview mode but should be out of preview for JDK 24.

With this issue, we should:

• prototype an implementation variant of SimpleMetadataReaderFactory based on ClassFile
• consider how this variant should be involved. As a feature flag only? Should it be the default on JDK24+?
• decide which Spring Framework version we should target; while not user facing, this is an important change that we should schedule accordingly

[bclozel]

I've extended the existing test suite and got a working prototype with a ClassFileMetadataReader that passes all tests on Java 24 early access.

So far I chose to add new static factory methods to MetadataReaderFactory - instantiating the SimpleMetadataReaderFactory on JDK < 24 and ClassFileMetadataReaderFactory on JDK 24+. This is the easiest way to test things so far, but we could consider a feature flag in SpringProperties.

[liach]

Should it be the default on JDK24+?

The ClassFile API aims to reduce the hussles with ASM dependency bumps when Java version is bumped - for example, to parse Java 23 class files, you need to bump ASM to 9.7.1. The ClassFile API, being part of the JDK, naturally parses new class files, and thus improves the compatibility with future Java versions.

[bclozel]

@liach Thanks for your input. So you're saying this should be the default for Java 24+? You can't think of a case where falling back to ASM would be preferable? Why?

[liach]

I recommend so. I think ClassFile API already covers whatever ASM parses; feel free to keep ASM as a fallback, though I cannot think of a use case (except custom attribute reading/writing with Code offsets or explicit max stack and locals, but I don't think metadata handling needs those). Feel free to check out https://github.com/raphw/asm-jdk-bridge for how ASM functionalities are rerouted to JDK, but this for sure will be less efficient than using the JDK APIs directly.