JDK-7099086 : Java Web Start 10.1.* is considerably slower than Web Start 1.4.2, using getresource() repeatedly
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 7,7u1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2011-10-10
  • Updated: 2013-12-04
  • Resolved: 2011-10-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u30-revFixed 7u2Fixed 8 b12Fixed
Related Reports
Duplicate :  
JDK-7072155 - Resource files contained in jar files degrade Java Web Start app launch time
Relates :  
JDK-7100860 - URLClassPath may be very slow if jar index is used
Description
Java Web Start 10.1.0.8 (Java SE 7 Update 1) is considerably slower 
compared to Java Web Start 1.4.2, when loading resources by
com.sun.jnlp.JNLPClassLoader.getResource(String) repeatedly.
Comments
verified with 8 b108 output Loaded classes 99 in 1141mills, loaded files 99 firsttime in 213mills second time in 130mills
04-12-2013
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
11-10-2011
EVALUATION Problem seem to be related to inefficient processing of indexed jar files. More research is needed to identify best solution. Suggested workaround: do not index jar files.
11-10-2011