JDK-6786875 : portal netlet crashed with NPE with Firefox3/IE7 and JRE1.6.10 or 1.6.11 on Win XP
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u11
  • Priority: P2
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: generic
  • Submitted: 2008-12-18
  • Updated: 2011-02-23
  • Resolved: 2009-01-13
Related Reports
Relates :  
JDK-6789865 - Java Plugin isInNet implementation returns incorrect value in some cases
Description
With the new generation java plugin of 1.6.0_10 or 1.6.0_11 we see the following error 
with Firefox3.0.x on Win xp OR IE7 on Win xp and VISTA.

on client side java console:
Java version : 1.6.0_10
Proxy type : null
java.lang.NullPointerException
        at com.sun.portal.netlet.client.applet.NL30.l(NL30)
        at com.sun.portal.netlet.client.applet.NL30.<init>(NL30)
        at com.sun.portal.netlet.client.applet.NL43.<init>(NL43)
        at com.sun.portal.netlet.client.applet.NetletApplet.b(NetletApplet)
        at com.sun.portal.netlet.client.applet.NetletApplet.h(NetletApplet)
        at com.sun.portal.netlet.client.applet.NetletApplet.start(NetletApplet)
        at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Exception: java.lang.NullPointerException

Regarding the NPE while loading the applet, this is due to the applet not been able to read proxy config.
FYI, Refer related bug 6774243
Comments
EVALUATION Per discussion with the Netlet team they have rewritten their proxy lookup code to use the ProxySelector class introduced in Java SE 5.0. This solution is working well for them with both the classic and new Java Plug-Ins, and is the best solution to the problem all around. Closing this bug as "will not fix".
13-01-2009
EVALUATION After discussion with the customer, it appears that it should be possible for the applet to be changed to call ProxySelector.getDefault() to look up the proxies for a given URL. Depending on whether the lookups are done explicitly by the Netlet code or implicitly via other code opening a URLConnection, the Netlet may decide to replace the default ProxySelector upon its initialization and restore it upon termination, and delegate lookups back to the default ProxySelector. This is the only solution that will work well within the new Java Plug-In's architecture. The previous proxy code was extremely complicated and fragile and it can not be overemphasized that we do not want to reintroduce any of it. We are in the process of specifying proxy lookups for arbitrary browser plugins in the Netscape Plugin API (NPAPI) and the form of the API is a lookup per URL, not a query of all of the proxy settings for the browser.
08-01-2009
EVALUATION During the development of the new Java Plug-In the proxy handling code was substantially rewritten. The old implementation attempted to parse the browser's proxy settings and reflect them up to Java. This code was fragile, error prone, and extremely complicated. The new implementation always delegates to the web browser's proxy settings. The Java VM running the applet does not know anything about the proxy configuration; each request to look up a proxy for a given URL is delegated back to the web browser. We do not want to reincorporate the old proxy code unless absolutely necessary. We need to know exactly why the application needs to know these proxy settings and what it does with them. All socket creation that is performed by the applet will already automatically have the correct proxy settings applied. If for some reason the application does need to know the proxy settings, perhaps there is a simpler way to provide the same or similar functionality with less complexity. Note that the javaplugin.proxy.config.* system properties are not part of the public applet specification, so the application should be robust with regard to their presence regardless. Marking this bug as incomplete pending more information on exactly how and why these settings are used.
22-12-2008
EVALUATION When the option "Enable the next-generation Java Plug-in" is enabled (by default) in the Advanced tab of Java Control Panel we're hitting this bug and using the option "s: dump system and deployment properties" is not showing any entries related to javaplugin.proxy.config.* params. However when the option "Enable the next-generation Java Plug-in" is disabled in the Advanced tab of Java Control Panel, the problem got resolved but it is not acceptable by the customer. When this option is disabled, using the option "s: dump system and deployment properties" in the Java Console dumps the contents and all the params of javaplugin.proxy.config.* is set which is as follows: ------------- : :<snip> javaplugin.proxy.config.bypass = *localhost,*127.0.0.1,*suntea.singapore.sun.com javaplugin.proxy.config.list = http=webcache.central.sun.com:8080,https=webcache.central.sun.com:8080,ftp=webcache.central.sun.com:8080,gopher=webcache.central.sun.com:8080,socks=webcache.central.sun.com:8080 javaplugin.proxy.config.type = manual : :<snip> -------------
18-12-2008