I talked with Ken Russell of the HotSpot team. Basically the JVM doesn't support the notion of error recovery. That is, since the JRE is also located on a remote machine, when you unplug the network, meanwhile if the JVM is trying to access some JVM files such as those in rt.jar, it will encounter an IO error, as a result it throws a ClassDefNotFoundError. If the application really wants to recover from this kind of error, it can catch it and continue (I tried it, it works), or it can restart the JVM.
Depending on the status of the JVM and what it's trying to execute next, you could encounter other file not found (i.e it's not limited to "sun/reflect/MethodAccessorGenerator"). To see this, you can try to kill the vm by "ctrl-c" while having the network cable unplugged, and it would complain about "java/lang/Shutdown" not being found.
But what is interesting about "sun/reflect/MethodAccessorGenerator" is that it provides an optimization to reflection (newInstance uses reflection). It kicks in after the reflection method being called 15 times. So even if you have already loaded a class, in this case Test2, if you unplug the network, you would continue to be able to load and instantiate Test2. However, after about 15 times, you would suddenly see "NoClassDefFoundError: sun/reflect/MethodAccessorGenerator ...". This is because the JVM optimizer starts to kick in and needs to load MethodAccessorGenerator class (part of rt.jar), but due to network inaccessibility, it couldn't load it, thus the error.
In summary, this is not a bug.
There are a number of scenarios where we could try to be more robust
in the face of I/O failures.
On Windows, a jar file is represented internally as a file descriptor.
If that file descriptor is closed because the network became temporarily
unavailable, it is certainly reasonable to try to reopen it. However,
this is a high-risk change that should only be contemplated for a future
release, in my opinion. Another consideration is that we may someday use
mapped files on Windows, as we do on Unix.
A similar scenario where we could imagine being more robust is when
a jar file is replaced on disk. If we notice this, we can discard
our in-memory cache of the central directory and re-read it, avoiding
errors on the next Class load operation.
In any case, I don't think these sorts of changes are appropriate for
older releases. Even for future releases, we have more important
bugs/features in the jar/zip implementation to take core of first.
Fix caused a build failure. Hence, backed out from 1.4.2_08/b01.
###@###.### 10/27/04 17:31 GMT