EVALUATION
Here is what happens:
1) Test application uses jar index
2) Test application consists of many jar files (100) that share same package names. Every jar has just one class in "test" package and 1000 other jar entries.
3) Test app tries to load classes from "test" package one by one.
4) Current implementation in DeployURLClassPath (and in fact URLClassPath
but this needs to be addresses on JDK side) performs validation of the jar index in case index points to jar as candidate to contain requested resource but resource is not found.
5) validation procedure checks jar has at least one entry in the requested
package. In the test scenario this means we iterate through 1000
entries in jar before we find index is ok. And we repeat it for every
false positive jar (remember they all have "test" package).
Total cost of "validation" for this scenario is 100*1000*(100/2)=5 000 000 jar entries read
(calculated as numberOfLookups*CostOfLookupInOneJar*AverageJarsToLookIn)
This is obviously expensive and real customer app is even bigger (1000+ jars) => possible even more expensive.
On other hand the value of this validation check is questionable
(originally was added in 2001, 1.3 timeframe).
The only outcome we get different exception instead of ClassNotFound.
In any case attempt to load class will fail. In case of malformed index
it will file with RuntimeException and apps may not be catching it.
Anyway, check does not seem to worth it.
Suggested fix is to remove validation check. With this change time for second stage
of test is reduced to about 100ms (from 10000ms) and this is comparable with what is reported for 1.4.2
|
Java