<Swing Dev> Bug 6499857: JMenuItem.getRootPane() returns null

Miguel Munoz swingguy1024 at yahoo.com
Fri Sep 21 20:15:01 UTC 2007


I submitted a fix. The fix works for JMenuItems, but when I look at the documentation, I see that other components may also be added to JMenus, and the fix won't work for them. But after experimenting, I discovered that, if I add a JButton to a JMenu, the bug doesn't show up. So the bug only affects JMenuItems that are added to a JMenu.

This raises an interesting question. Is there a better fix for this? Right now, JMenuItems are added to menus through a special mechanism, and other JComponents are added through the standard mechanism, but they both work as menu items. Furthermore, getRootPane() works for items added through the standard mechanism. This raises an obvious question: Would JMenuItems work fine if added through the standard mechanism? If so, that would be a better fix, and here's why:

There are a few related bugs. For example, bug 4231737 (which has the mysterious designation of RFE) is caused by JOptionPane.getWindowForComponent(Component parentComponent), which calls itself recursively like this:

  return JOptionPane.getWindowForComponent(parentComponent.getParent())

(with other code to end this cycle cleanly.)

Looping on parent.getParent() is a common thing to do, and shows up in these four methods in SwingUtilities:

Window getWindowAncestor(Component c) 
Window windowForComponent(Component c) 
Component getRoot(Component c) 
JRootPane getRootPane(Component c)
I'm sure a few developers have also written this loop. And all of these fail for JMenuItems for the same reason getRootPane() fails.

So I am currently investigating why getRootPane() works for a JButton added to a menu, and I'm looking at how hard it will be to make JMenuItems work through the standard mechanism instead of the custom one. (I realize this is probably a long shot.) If that works, it would be a better fix, because it would fix all four of the methods above, as well as every individual developer's parent=parent.getParent() loop.

-- Miguel

Alexander Potochkin <Alexander.Potochkin at Sun.COM> wrote: Hello Miguel

> The problem is simple. The getRootPane() method calls 
> SwingUtilities.getRootPane(Component c). That method loops on a call to 
> getParent, like this:
>         for( ; c != null; c = c.getParent()) {
>             if (c instanceof JRootPane) {
>                 return (JRootPane)c;
>             }
>         }
> The trouble is that anything placed on a menu doesn't belong to the 
> standard hierarchy. JMenus use a JPopupMenu, and JPopupMenus don't have 
> a parent, they have an invoker.
> An obvious fix would be to override getParent() in JPopupMenu to call 
> getInvoker() and return that. This doesn't work. The getInvoker() method 
> returns a Component, but getParent() returns a Container. I can work 
> around this, but it breaks the menu code.
> The fix is to complicate the loop on c = c.getParent(), by checking for 
> JMenuItems and handling them differently. This slows the loop down, so I 
> don't want to do that in Swing Utilities, because there's no need for 
> the more complicated loop for most components. Instead, I plan to 
> override getRootPane() in JMenuItem.

This sounds like a good idea

>   This is complicated by the fact that not all JMenuItems are broken. 
> JMenus are subclasses of JMenuItem, and they have a valid parent (unless 
> they're a submenu). But that should be easy to work around.
> I'll have some code in a day or two. I'll include a test program. Are 
> there any constraints I should know about for the test program?

We use jtreg harness for our regression tests


It might look a bit messy,
but actually it's quite simple to write a test with jtreg

In your case, I imagine, you'd check JMenuItem.getRootPane()
and throw RuntimeException if it is null just like with JUnit


> -- Miguel Mu�oz
> On Sep 20, 2007, at 6:55 AM, Alexander Potochkin wrote:
>> Hello Miguel
>>> I plan to fix bug 6499857. There are a couple of approaches, but I 
>>> think I know the best way to fix it. Has anybody else looked at this?
>> Currently no one works on this fix
>> so you are welcome to start with it !
>> Thanks
>> alexp
>>> -- Miguel Mu�oz
>>> ___________________
>>> There are 10 kinds of people: Those who know binary and those who don't.
> ___________________
> There are 10 kinds of people: Those who know binary and those who don't.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070921/ee3469f3/attachment.html>

More information about the swing-dev mailing list