(snip)
Well, this problem is specific to Swing on the Mac, so it’s not relevant to Eclipse, but it shows up in other programs “in the wild,” especially if they automatically have sub-menus that show your projects in a directory or something like that (so the number of items is unbounded).
Here’s a very basic example, which, while totally unrealistic, runs fine (a second or two delay in response) using Java 1.4.2 on OS X, but practically grinds to a halt when you click the File menu on 1.5 or above (again, OS X only):
import javax.swing.JFrame;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
public class SwingMenuSlowdown {
private static final int largeNumberOfMenuItems = 1000;
public static void main(String[] args) {
System.setProperty("apple.laf.useScreenMenuBar", "true");
JFrame frame = new JFrame();
frame.setTitle("On OS X this menu is really slow in Java 1.5+, but works fine in 1.4");
frame.setSize(640,480);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JMenuBar myMenuBar = new JMenuBar();
JMenu myFile = new JMenu("File");
JMenu mySub = new JMenu("A lotta stuff");
for (int i=0; i<largeNumberOfMenuItems; ++i) {
mySub.add(new JMenuItem("MyStuff "+i));
}
myFile.add(mySub);
myMenuBar.add(myFile);
frame.setJMenuBar(myMenuBar);
frame.setVisible(true);
}
}
1000 items is unrealistic, but even in real apps the problem shows up to varying degrees. I don’t know of any workarounds at the moment if you’re using Swing…you can set the 'useScreenMenuBar" to false and that “fixes” it (hence the problem is something to do with the way Apple binds to the screen menu in Swing - AWT is also fine), but that’s very against Mac UI standards, so…
Then again, I don’t do much Swing, so there might be something else going on here, too.
There are some things that are annoying from time to time (task/project/classpath scanning), but overall Netbeans gives a good and productive user experience.
