JDK-8056013 : Web Start looks in currently directory for all classes prior to jars - slow
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 7u67,8u20,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2014-08-25
  • Updated: 2017-07-13
  • Resolved: 2015-07-20
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 JDK 9
6u115Resolved 7u111Fixed 8u72Fixed 9 b76Fixed
Description
FULL PRODUCT VERSION :
Using JRE version 1.7.0_67-b01 Java HotSpot(TM) Client VM
Java Web Start 10.67.2.01


ADDITIONAL OS VERSION INFORMATION :
Window 7 Service Pack 1 

EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 11 

A DESCRIPTION OF THE PROBLEM :
"java.class.path" starting with 1.7.0_67 is "."  (in 1.7.0_60 it was deploy.jar).  

Therefore the "root" class loader (sun.misc.Launcher$AppClassLoader) is first given the chance to load the class from the file system in the current directory ("user.dir") .  This results in very slow startup time when there are thousand of classes to load and the "user.dir" is a network drive ( 3 minutes vs 10 seconds before ).

Can verify what is the java.class.path and user.dir by having java console started and pressing letter "s"

REGRESSION.  Last worked in version 7u60

ADDITIONAL REGRESSION INFORMATION: 
JRE version 1.7.0_67-b01 Java HotSpot(TM) Client VM

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) install process monitor to see file activity 
a) download zip from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
b) unzip
c) start Procmon.exe
d) press Filter Icon
e) Select "Process Name" "is" "jp2launcher.exe" "Include"
f) press Add
g) Select "Path" "ends with" ".class" "Include"
h) press Add

2) Start Internet Explorer 11
3) Navigate to http://docs.oracle.com/javase/tutorial/uiswing/examples/misc/index.html
4) click on Launch for AccessibleScrollDemo ( or any other)


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Process Monitor shows no class files accessed since they are all in JAR files.
ACTUAL -
Process Monitor shows classes being accessed in "user.dir", all show  PATH NOT FOUND

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Process Monitor shows PATH NOT FOUND

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See java examples on web for a JNLPs.  Any JNLP file will show the problem with trying to access class files in current directory.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround found. Cannot override classpath or set user.dir using java-vm-args or property name/values in JNLP file.


Comments
verified with reproduce steps against 9b177 on Windows 7-x86/Ie11
13-07-2017

Added cr-watch for 1602 so we can sort out what to do here on the 7u and 6u backport issues
01-02-2016

Does the fix need to be backported to JDK 8 and JDK 7?
13-10-2015

javaws always used deploy.jar, because it is already loaded, so there is no additional cost, and looking in <jre_home>/classes has potential problem of it existing and classes actually being loaded from there. Modified both plugin and webstart cases to use deploy.jar as classpath arg Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1211
17-07-2015

This is a bug in the secure launcher jp2launcher.exe. If I add the deployment.properties entry "deployment.security.use.insecure.launcher=true" then run any javaws app and hit "s" in the console: java.class.path = C:\Program Files (x86)\Java\jre1.9.0\lib\deploy.jar without that deployment.property: java.class.path = . javaws launcher passes the correct "-Djava.class.path=%s\\deploy.jar" (where %s is the jre lib dir) But in both Jp2Launcher.cpp and clutter.cpp, it tries to add: "-Djava.class.path=%s\\classes" where %s is jreHome (this is a nonsense place, a non-existant dir in most cases) but only in plugin case, in webstart it dosn't add a java.class.path arg, and as a result VM defaults to "."
16-07-2015

I can reproduce it with latest jre9 build, for now it's 9b73.
16-07-2015

The problem is reproducible on jre8u20 and jre9, as well.
03-10-2014