JDK-6594219 : Plugin loads Swing classes
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6,6u10,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-08-17
  • Updated: 2011-01-19
  • Resolved: 2010-07-06
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
6u10Fixed 7 b64Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Java plugin loads many Swing classes even if the applet does not use Swing, and Java console is off.

I configured plugin to run hprof (-Xrunhprof:heap=dump), and set 'Do not start console' in Advanced/Java console. Though my applet was AWT-only, 66 Swing classes were loaded - see attached hprof.txt.

I used Firefox2 and JDK 7 b17 on Linux, and the following applet:

import java.applet.Applet;
import java.awt.*;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

public class T extends Applet {
    public void start() {
        final Frame f = new Frame("100% AWT");
        f.add(new Button("Hit me if you can!"));
        f.addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent ev) {
                System.out.println("Exiting!");
                f.setVisible(false);
                f.dispose();
            }
        });
        
        f.pack();
        f.setVisible(true);
    }
}

Comments
EVALUATION There are several places where Swing classes are loaded. They were identified by running ArcTest applet - pure AWT - inside plugin on Windows. The first problem is described above: DeployUIManager.setLookAndFeel(). This method can be rewritten to set system property "swing.defaultlaf" instead of setting LAF directly. Code that guesses system LAF should be copied from UIManager. This method also puts current Metal theme name into themeMap. This map now seems unused. It was previously accessed from the restoreLookAndFeel() method, which was removed by Rita in version 1.21. I believe this code is now dead, so i suggest removing it. The second problem is SwingUtilities.invokeLater() in sun.plugin.util.PluginSysUtil - needs to be replaced with EventQueue. The third one is sun.plugin.AppletViewer which explicitly loads javax.swing.ImageIcon to work around a memory leak in Swing. The memory leak is hopefully fixed on the Swing side - see bug 6482575, fixed in 6u10b05. So hopefully the workaround can now be safely removed, but this needs to be verified.
13-12-2007

EVALUATION There's a way to specify the default LAF Swing will use, without having to load Swing classes. It is, to set the "swing.defaultlaf" property: System.setProperty("swing.defaultlaf", "com.sun.java.swing.plaf.motif.MotifLookAndFeel"); Unfortunately getting system LAF name from Swing would need UIManager to be loaded :( You may want to borrow some logic from UIManager.getSystemLookAndFeelClassName().
19-09-2007

EVALUATION This is the thread that most likely triggers loading Swing classes (JDK7 b17): com.sun.deploy.util.DeployUIManager.setLookAndFeel(DeployUIManager.java:84) sun.plugin.util.PluginSysUtil$1.run(PluginSysUtil.java:66) java.lang.Thread.run(Thread.java:644)
29-08-2007