VM anonymous classes are an implementation detail that is opaque to system components except for the lowest layers of the JDK runtime and the JVM itself. Transformers and other instrumentation should not look inside them expecting to interpose on their behavior. Ideally we should not make them visible at all, but sometimes it helps (e.g., with single stepping through BCs).
VM anonymous classes may be (and are) replaced or interchanged unpredictably with similar mechanisms, such as JNI-based reflection, or indirect invocation via MemberName tokens. You can't rely on any of this meaning what you think it means, even if it appears to have a classfile structure. Even if you were able to "transform" one of these classfiles, it wouldn't necessary do what you think it should do, because its structure is a private internal-only contract of the JDK and JVM. And, as you probably have already noticed, the number and structure of these VMAC classfiles change over time. We may (at some point) replace the classes with some completely different internal representation, which, even if it is visible somehow to instrumentation, cannot meaningfully be parsed and re-implemented. Likewise, lambdas are translated into inner classes, but this also can change at any time; the metafactory API makes few or no promises as to the internal structure of the invokedynamic binding. In fact, some JVMs use special polymorphic nodes, instead of the standard inner-class translation. Suddenly, some or all of these classfiles may disappear, when the runtime begins to optimize them differently. Please don't lead your users to rely on them. I second Vladimir's suggestion, that the only sane way to interpose on lambdas is to transform the class that defines the lambda (including perhaps the parameters of the indy that create the lambda), and not dig into system internals. System internals are nothing like user code, and cannot be transformed like user code. Sorry to bear bad news, — John
