jdk-25+ STF build broken by move of ASM classes from java.base

[andrew-m-leonard]

jdk-25+ upstream change https://bugs.openjdk.org/browse/JDK-8346986 has moved the internal
java.base ASM classes to hotspot jtreg test library instead, thus breaking building of STF library:

java.base/share/classes/jdk/internal/org/objectweb/asm
moved to:
hotspot/jtreg/testlibrary/asm/org/objectweb/asm

[andrew-m-leonard]

These various openjdk.test.debugging hcr agent classes relate to this original PR #394
but it's not obvious why we need to use the JVM "asm" as opposed to the public "asm" ? Ref: eclipse-openj9/openj9#11642 (comment)

Note, currently for jdk-21+ the failing test in question HCRLateAttachWorkload_previewEnabled is now excluded: https://github.com/adoptium/aqa-tests/blob/2af60d42925f48ffbc831676c0a8a010163da925/system/otherLoadTest/playlist.xml#L364

@pshipton @llxia Wonder if you can help here please, as I presume openj9 fails to build jdk-25+ system classes now the JVM "asm" has been removed from java.base ?

[pshipton]

I believe the JVM asm supported new versions of Java before any public asm was available.

Since OpenJ9's DDR won't build without asm, and DDR is required, we've temporarily restored asm in jdk25 until we can rewrite the code to use JEP 484.

ibmruntimes/openj9-openjdk-jdk#919

Another point is that it's too early for OpenJ9 to be running any testing on jdk25. We build it, but so far don't test it.

[andrew-m-leonard]

@smlambert @sophia-guo @llxia With above in mind, is this a potential temporary fix to get jdk-25 STF building for Temurin?
https://github.com/adoptium/aqa-systemtest/pull/497/files

[smlambert]

Shall we kick off a few Grinders to see how it behaves?

aarch64_linux: https://ci.adoptium.net/job/Grinder/12679
x86-64_window: https://ci.adoptium.net/job/Grinder/12680/ (unhappy for a different reason?)