Fix for 7099086 removed validation check for "invalid index file" from deploy version of URLClassPath but same code is still present in the 
URLClassPath. It should be fairly straightforward to reproduce performace problem using testcase from 7099086 using URLClassPath without deployment code. 

Jar specification says:

> "Once the class loader finds a INDEX.LIST file in a particular jar
> file, it always trusts the information listed in it. If a mapping is
> found for a particular class, but the class loader fails to find it
> by following the link, an InvalidJarIndexException is thrown. When
> this occurs, the application developer should rerun the jar tool on
> the extension to get the right information into the index file."

But this appears to be poor specification.
If i read it correctly then if class is actually missing but its package
is referenced in jar index then we are supposed to get
InvalidJarIndexException?
This will be runtime exception and potentially breaking code that only
expects CNFE while checking for "optional" class (once jar index is added)? 

IMHO, such check is useful for developers but not for end users.
For end user it is binary - app either works or fails. If it fails and if developer can reproduce it
then detailed error on the user side is not really needed. It may be even more confusing.

Note that generally speaking this runtime exception can happen on arbitrary thread and may simply cause thread to exit
=> this will not look easier to understand. And this discussion confirms it:
      http://stackoverflow.com/questions/5926333/how-to-track-down-jar-with-corrupt-jar-index-that-cause-invalidjarindexexception

IMHO, it would be better to have way to enable "sanity" checks or debug mode if developr needs it at the expense of performance, etc.
Adding "expensive" development-centerd checks does not seem like good idea as for 99+% of uses they are likely to be useful. 

IMHO, best way to do this sanity check is to update jar tool to "revalidate" index file if jar is updated and index file is present.
And add "validate" index command to jar command in addition to "jar -i" (and remove check from UCP implementation)

If somebody is using zip or other means to update jar and index is not correct - i'd not worry about it.
IMHO, it is not very different if they make mistype in the class name and class is not found because of it.