Consider the following sequence of events:

1. The application is started, with the main JAR file as well as the JRE
    on a network drive.

2. There is a network outage cause the network drive to become unavailable.

3. An attempt to load a class that has not so far been used results in
    a ClassNotFoundException.

4. Network connectivity is restored.

5. Subsequent attempts to access the class from step 3 continue to fail
    (they do not retry the file access).

The attached test case can be used to demonstrate the problem and RFE requirement. The test case loads a simple class from a jar file everytime you press the return key (loads "Test" class for 3-4 iterations and loads "Test2"
later in an infinite loop.

There are two scenarios that can fork off from the above:

Scenario I: The n/w connectivity is restored and you visually inspect the
n/w mapped folder to confirm that the data is accessible before hitting
return key to load a class again.

Scenario II: The n/w connectivity is NOT restored and we continue to hit the
return to load the class.

While the Scenario I is being addressed via Bug id # 5031910, we are submitting this RFE to address Scenario II as below:

The test case used to demonstrate both the current and expected
behaviour is the same one used with both scenarios. The expected
behaviour is to have a timer associated with "loadClass" API such that
if there were to be a network outage or network congestion/busy
conditions, the API would continue to try loading the class till the
timer expires or the data becomes available, whichever happens first.

Also, a meaningful exception should be associated with the fail/timeout
case and the timeout value should be in milliseconds.