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." I understand this, however we are creating a problem of our own making. There is a natural expectation that a classloader has references to all the classes it has defined. The implementation of that (which was completely visible to anyone who cared to look) was via the classes Vector. We are now saying the Vector is redundant because we implicitly track this in the VM, and further the vector is causing memory issues, so lets scrap the Vector. But now something that has always worked will stop working. So we are breaking things. As I see it we have three choices: 1. Don't get rid of the Vector and just accept it will consume memory 2. Get rid of the Vector but synthesize a means to still find all the defined classes 3. Get rid of the Vector and accept the breakage I would prefer (2) but I understand the extreme reluctance to subvert the `FollowReferences` spec. If we insiste the vector must go then that only leaves (3) but we do have to deal with the compatibility story and give users time to adjust - so as I see it there is no quick fix here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32519#issuecomment-5594669389
