[mperor]

What you'll learn

• How to parse an existing .class file into a ClassModel and inspect its methods and fields with ClassFile.of().parse(...)
• How to generate a brand-new class at runtime with ClassFile.of().build(...), load it as a hidden class via MethodHandles.Lookup.defineHiddenClass, and invoke it with a MethodHandle
• How to rewrite an existing class with a ClassTransform (here: dropping one method) and get back new, valid bytecode

Why it matters

The Class-File API is the JDK's own supported replacement for ASM/BCEL-style bytecode libraries: it tracks the JVM spec release-by-release, so tools built on it (debuggers, bytecode processors, dynamic-proxy generators) no longer need to vendor a separate bytecode library that risks falling behind a new class file version.

Read more

JEP 484: Class-File API

Quiz

After a ClassTransform.dropping(...) removes a method from a class's bytecode and the result is re-parsed into a ClassModel, does the original class's declared constructor (<init>) still show up in classModel.methods()?

Answer

Yes. Every constructor compiles to a regular method named <init> in the class file, and ClassTransform.dropping only removes the elements matched by the predicate — it was not asked to drop <init>, so it passes through untouched along with every other method.

Note: this sandbox's network policy blocked every JDK distribution host (including the Gradle toolchain resolver), so ./gradlew :JavaReleases:test could not run locally with only JDK 21 installed. CI has since run on JDK 25 and is green (306 tests, +3, 0 failures), confirming all three new tests pass.

Closes #110

[github-actions]

Test Results

306 tests  +3   303 ✅ +3   4s ⏱️ -2s
 84 suites ±0     3 💤 ±0 
 84 files   ±0     0 ❌ ±0 

Results for commit 77d43b8. ± Comparison against base commit a9c068a.