VisibleClasses can take very long on high delay networks. The issue is that visibleClasses does not include signatures in its response, and when we on the client side cache the result we need the signature. So for classes that are not previously cached we will do sequential remote calls to load their signature. Those remote calls are what causes the client to "hang" for several minutes.

Worth noting is that most classes will already be cached, with signatures, by either an initial allClasses call, or by the internal event handler. But those only cache classes that are prepared, so this is a problem for unprepared classes.

The ideal solution to this would be to add a new visibleClassesWithSignatures the JDWP spec, which includes signatures.

Another way to fix this (in a hackish way) would be to stop caching some classes. Either caching could be skipped entirely for visibleClasses, or only classes that do not have a signature provided could be skipped. Or, as Martin Entlicher has suggested in JDK-6457137, caching can be removed entirely from JDI.