JDK-6863419 : MimeTable initialization is too greedy
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2009-07-23
  • Updated: 2010-10-12
  • Resolved: 2010-10-12
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
6u18Fixed 7Resolved
Related Reports
Relates :  
JDK-6797730 - Umbrella: Applet startup performance improvements
Relates :  
JDK-6991300 - MimeTable is unsafe
Description
sun.net.www.MimeTable.getDefaultTable() causes data to be actually loaded even if they are never used.

plugin code touches mime table class on the main thread to ensure class is loaded from non-applet context and takes unnecessary performance hit.

Note that if loading will be potponed then it should be done in the priveledged block as MimeTable can be used by untrusted code.
Comments
EVALUATION CR 6991300: "MimeTable is unsafe" will be used to track the jdk side issue.
12-10-2010
EVALUATION The fix for this bug requires changes in both the jdk and the deployment code. The deployment changes have already been forwardported to JDK7, from 6u18, as far of CR 6958606: "Umbrella: Port All 6u15 - 6u21 changes in Deploy workspace to JDK7". Leaving just the cleanup in the JDK code.
12-10-2010
SUGGESTED FIX diff AppletViewer.javaORIG AppletViewer.java 522,539d521 < < /* we reference this class to get it loaded < * from a class w/o a classloader. If not, < * it first gets loaded from a thread w/ an < * applet on the stack, and then it can't read < * it's own content-types.properties file. < */ < try { < DeployPerfUtil.put("START - Java - ENV - " + < "AppletViewer.initEnvironment - prep MIME types table"); < sun.net.www.MimeTable mt = < sun.net.www.MimeTable.getDefaultTable(); < DeployPerfUtil.put("END - Java - ENV - " + < "AppletViewer.initEnvironment - prep MIME types table"); < } catch (Throwable e) { < Trace.printException(e); < } < diff Applet2Environment.javaORIG Applet2Environment.java 426,438d425 < /* we reference this class to get it loaded < * from a class w/o a classloader. If not, < * it first gets loaded from a thread w/ an < * applet on the stack, and then it can't read < * it's own content-types.properties file. < */ < try { < sun.net.www.MimeTable mt = < sun.net.www.MimeTable.getDefaultTable(); < } catch (Throwable e) { < Trace.printException(e); < } <
30-07-2009
EVALUATION Invoking MimeTable.getDefaultTable in an unprivileged context should NOT be a problem. getDefaultTable executes its actual body in a privileged block, so not problem reading content-types.properties off the local file system. What if plugin is run with a previous JRE? Well, getDefaultTable has been executing its method body in a privileged block since JDK 1.2 beta. So removing the call to getDefaultTable completely from the deployment code should be fine ( unless of course the user tries to run the latest plugin with a JDK1.1 JRE! ) I've tested this, i.e. removing the invocation of getDefaultTable from the deployment code and then executing an applet that will trigger the loading of the mime table through URLConnection.getFileNameMap. It works fine, no permission issues.
23-07-2009