On Tue, 8 Sep 2026 23:32:16 GMT, Dan Heidinga <[email protected]> wrote:
> This contradicts the FollowReferences spec which explicitly says "This > function reports a Java programming language view of object references, not a > virtual machine implementation view." If there is no Java programming > language reference (ie: Classloader.classes is removed), then we should not > report such references. This conclusion does not look right. Even though the `Classloader.classes` is removed there are still equivalents of this. And we already provide API's depending on it like JVMTI [GetClassLoaderClasses](https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetClassLoaderClasses) and Instrumentation.[getInitiatedClasses](https://docs.oracle.com/en/java/javase/25/docs/api/java.instrument/java/lang/instrument/Instrumentation.html#getInitiatedClasses(java.lang.ClassLoader)). Also, the `Classloader.classes` would not be removed now if it was not a duplication. One more though about this JVMTI statement: > This function reports a Java programming language view of object references, > not a virtual machine implementation view. We do not report references to loaded classes as from a JVM `ClassLoaderData` but as they are from a Java `ClassLoader` object transitively. And my reading is that it matches the JVMTI statement above. But if there any doubts let's ask Alan who designed this Heap Walking API. But suppose I'm wrong here. This statement is not a final deciding point. We have to account for compatibility as well. It is why we need a CSR here. . . . I see that David just posted his opinion. In fact, I agree with David that "there is a natural expectation that a classloader has references to all the classes it has defined." I'd also prefer the choice #2 from David's list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5594735969
