JDK-6343068 : Applets failure after updating to 5.0u5
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0u5
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-10-28
  • Updated: 2010-05-10
  • Resolved: 2005-11-18
Related Reports
Duplicate :  
JDK-6343137 - DNS Implementation is faulty
Relates :  
JDK-6353684 - Unnecessary service name in getaddrinfo calls
Description
When consumers update JRE from an older version say 1.4.2 or 1.5.0_04 to the current and latest version 1.5.0_05, applets fail to run entirely with Internet Explorer and Firefox/Mozilla browser. The applet fails to load and a General Exception error dialog is seen.

Case scenario:
Updated to 5.0u5 from Java update notification button or from http://java.com/en/download/index.jsp
Installation is complete and successful. (Install log attached as install.log file). Ensured that browsers are enabled completely to run Java applets from the web. Tested the installation through test vm applet at:
http://javaweb.sfbay.sun.com/~kc146510/test/testvm.html gave exception (screen shot attached)
tried java.com testvm applet at:
http://java.com/en/download/help/testvm.xml
tried yahoo bounce out applet. All tests fail with the same error message dialog.

On saving and loading the applet locally, it succeeded as expected.


Java Console Information:
Java Plug-in 1.5.0_05
Using JRE version 1.5.0_05 Java HotSpot(TM) Client VM
User home directory = D:\Documents and Settings\ps148196
network: Loading user-defined proxy configuration ...
network:     Proxy list: webcache.japan.sun.com:8080
network:     Proxy override: null
network: Done.
network: Loading manual proxy configuration ...
network: Done.
network: Proxy Configuration: Manual Configuration
     Proxy: http=webcache.japan.sun.com:8080,https=webcache.japan.sun.com:8080,ftp=webcache.japan.sun.com:8080,gopher=webcache.japan.sun.com:8080
     Proxy Overrides:

basic: Cache is enabled
basic: Location: D:\Documents and Settings\ps148196\Application Data\Sun\Java\Deployment\cache\javapi\v1.0
basic: Maximum size: unlimited
basic: Compression level: 0

----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------

basic: Registered modality listener
liveconnect: Invoking JS method: document
liveconnect: Invoking JS method: URL
basic: Referencing classloader: sun.plugin.ClassLoaderInfo@126e85f, refcount=1
basic: Added progress listener: sun.plugin.util.GrayBoxPainter@1006d75
basic: Loading applet ...
basic: Initializing applet ...
basic: Starting applet ...
network: Connecting http://java.com/applet/testvm.class with proxy=HTTP @ webcache.japan.sun.com:8080
network: Connecting http://java.com/applet/testvm/class.class with proxy=HTTP @ webcache.japan.sun.com:8080
load: class testvm.class not found.
java.lang.ClassNotFoundException: testvm.class
    at sun.applet.AppletClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadCode(Unknown Source)
    at sun.applet.AppletPanel.createApplet(Unknown Source)
    at sun.plugin.AppletViewer.createApplet(Unknown Source)
    at sun.applet.AppletPanel.runLoader(Unknown Source)
    at sun.applet.AppletPanel.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed.
    at sun.applet.AppletClassLoader.getBytes(Unknown Source)
    at sun.applet.AppletClassLoader.access$100(Unknown Source)
    at sun.applet.AppletClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    ... 10 more
basic: Exception: java.lang.ClassNotFoundException: testvm.class
java.lang.ClassNotFoundException: testvm.class
    at sun.applet.AppletClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadCode(Unknown Source)
    at sun.applet.AppletPanel.createApplet(Unknown Source)
    at sun.plugin.AppletViewer.createApplet(Unknown Source)
    at sun.applet.AppletPanel.runLoader(Unknown Source)
    at sun.applet.AppletPanel.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed.
    at sun.applet.AppletClassLoader.getBytes(Unknown Source)
    at sun.applet.AppletClassLoader.access$100(Unknown Source)
    at sun.applet.AppletClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    ... 10 more
basic: Modality pushed
basic: Modality popped
basic: Modality pushed
basic: Modality popped

----------------------------------------------------------------------------------------------------------

EXPECTED VERSUS ACTUAL BEHAVIOR
Expected:
After JRE is installed successfully, and browsers are enabled for Java Plug-in under normal behavior applets should run without failure.

Actual:
Applets fails to run after doing all the necessary steps.

------------------------------------------------------------
Useful Information:
If you uninstall 5.0u5 and install version from 1.4.2 series, say 1.4.2_09, everything works fine including able to run test vm applet from:
http://java.com/en/download/help/testvm.xml
Comments
EVALUATION I finally figured what the problem is. It seems MSN Messenger 7.5, when installing itself, changes the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters\DatabasePath from REG_EXPAND_SZ to REG_SZ. Since that key usually has %SystemRoot% has part of the path, it breaks it since it won't be expanded any longer. The solution is to revert that key back to REG_EXPAND_SZ, or to replace %SystemRoot% with a C:\Windows or D:\Windows depending on your installation, but I don't recommend that last solution. Unfortunately it doesn't seem possible to change the type of an existing key, so you have to delete it and re-create it with the proper type.
18-11-2005
EVALUATION After investigation on one of the machines which shows the problem I have determined: - This is an IPv6 issue which explains why 1.4.x was working fine (support for IPv6 on Windows started with 1.5) - 1.5.0u4 shows the same problems - a native program written in C shows the same problem: getaddrinfo(name, "domain") fails. It seems that install of Windows can't translate service names, which creates the issue. Therefore it seems very likely this is a Windows IPv6 config issue and not a J2SE bug. I will try to find what caused that mis-configuration, in the meantime I'm lowering the priority of this bug. See the suggested workarounds.
17-11-2005
WORK AROUND 2 possible workarounds for the moment: - disable IPv6 on the machine - run the JVM with the system property "java.net.preferIPv4Stack" set to "true"
17-11-2005
EVALUATION I'm still unable to reproduce this on another machine, but it seems to be IPv6 related. If I run the test with -Djava.net.preferIPv4Stack=true it succeeds. Looks like getaddrinfo doesn't work on that machine. Need to run some native code tests...
16-11-2005
EVALUATION The previous test is not a valid one. It only shows the machine it's being run on is not configured to handle partial domain names. When testing always use fully qualified domain names like dispensable.east.sun.com. The same code run perfectly fine on all the machines I've tested it on. I am also totally unable to reproduce the initial bug on my Windows XP SP2 bug with 1.5.0u5, whether on or outside swan.
16-11-2005
EVALUATION I was able to log onto Pardeep's machine in India and reproduce this bug. I was able to narrow down the DNS problem down from the Applet not working to basic J2SE behavior not working as expected. The sample code below tries to establish a connection with a computer on the SWAN. The connection fails using the computer named "dispensable.east" but works as expected with the actual IP address. There seems to be some issue doing name resolution. I put a simple program in the c:\java_debug folder. To run the program type % java -classpath testURL.jar testurl this is what the code is doing: url = new URL("http://dispensable.east"); InputStream is = url.openStream(); System.out.println(" >>>> Stream is : " + is.toString() ); } catch (Exception e) { e.printStackTrace(); } url = new URL("http://129.148.174.90"); InputStream is = url.openStream(); System.out.println(" >>>> Stream is : " + is.toString() ); }catch (Exception e) { e.printStackTrace(); }
15-11-2005
EVALUATION webcache.japan.sun.com was temporarly used for testing the bug. This is tried with both of these proxies including webcache.sfbay.sun.com independentally as well in combination with the same result.
11-11-2005
EVALUATION Could I get the VNC information so I can evaluate the bug on a machine that can reproduce this bug? I was unable to reproduce it in our lab. I also notice the proxy in the install log is webcache.sfbay.sun.com:8080 yet the error shows the Applet connection to webcache.japan.sun.com Is the Java Control Panel set to use the browser settings, or are the browser settings being overridden in the Java Control Panel?
01-11-2005