[Bug swing/24359] JPopupMenu broken due to BoxLayout/SizeRequirements changes

[hendrich at informatik dot uni-hamburg dot de]

------- Comment #6 from hendrich at informatik dot uni-hamburg dot de  
2005-10-24 17:04 -------
Hallo Roman,

> Could you please retest?

yes and no. 

No: I already converted my test-app to use invokeLater() after Mark's 
(really excellent!!) diagnosis. I tried about 200 invocations afterwards, 
but never got the NPE in BoxLayout again. (I did get a few random crashes
in other places of Swing, but could not reproduce them or track them down.
Needless to say, these errors never occur when running in gdb).

Yes: I still have two other applications that are using the build-GUI-in-main-
thread-and-then-show paradigm and create a popup-menu from the main thread.
I haven't managed to reproduce the bug with current classpath (cvs 2005.10.24
with the synchronized-blocks in BoxLayout). The bug seems fixed for now,
but more testing is probably required.

However, both menus and popup-menus seem slower with current cvs than last
weeks version (but I have no performance data as proof yet).

---

But despite Marks explanation, I still fail to see why SizeRequirements
should ever see a null child component, even when building the application 
in the main thread and calling show() from there...

... personally, I would argue for a few null-checks in SizeRequirements 
to avoid crashing there. Just for safety :-) (skipping null components 
should leave the rest of the layout intact).

Or perhaps BoxLayout.checkRequirements() could simply take a Component[]
parameter, so that SizeRequirements never sees a children[] array that
has been meddled with by different threads?!

BTW: most components in Swing report Integer.MAX_VALUE as their maximum 
size, but Box uses Short.MAX_VALUE. Is this intentional? It made looking
at component sizes in the debugger even more bewildering...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24359