"Write once, test everywhere" - Win2K / XP

[Tim Ward]

I've got this Swing application developed, and working in the field, on
Win2k which I'm told crashes on XP.

I've been sent a backtrace which seems to indicate that it falls over in:

com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer

so this looks like a problem to do with incompatibilities between the XP
look and feel and the Win2k one.

Have I got this right so far?

If so, then given that my development box is running Win2k, how do I find
out what parameter to pass to UIManager.setLookAndFeel() to make it run the
XP look and feel so I can debug the problem? Or is this impossible because
the XP UI code will only run on XP so I'll need to acquire an XP box?

 

[Daniel Dyer]

I've got this Swing application developed, and working in the field, on
Win2k which I'm told crashes on XP.

I've been sent a backtrace which seems to indicate that it falls over in:

com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer

so this looks like a problem to do with incompatibilities between the XP
look and feel and the Win2k one.

Have I got this right so far?

If so, then given that my development box is running Win2k, how do I find
out what parameter to pass to UIManager.setLookAndFeel() to make it run
the
XP look and feel so I can debug the problem? Or is this impossible
because
the XP UI code will only run on XP so I'll need to acquire an XP box?

You could try using System.setProperty() to change the value of "os.name"
and/or "os.version" as required before setting the look-and-feel. I seem
to remember getting the Windows look-and-feel to work under Linux this way
(although in that case it was a bit more involved than that).

Dan.

 

[Tim Ward]

You could try using System.setProperty() to change the value of "os.name"
and/or "os.version" as required before setting the look-and-feel. I seem
to remember getting the Windows look-and-feel to work under Linux this way
(although in that case it was a bit more involved than that).

Further research, searching for the last bits of the backtrace:

Exception in thread "main" java.lang.NullPointerException
at javax.swing.border.EmptyBorder.<init>(Unknown Source)
at
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTa
bleCellRendererComponent(Unknown Source)

shows that lots of people think this is a bug in the JRE but I can't find
any suggested solution or workaround.

(Other than reverting to an earlier JRE ... which has bugs in the socket
handling that would stop my application working anyway.)

 

[John]

Further research, searching for the last bits of the backtrace:

Exception in thread "main" java.lang.NullPointerException
at javax.swing.border.EmptyBorder.<init>(Unknown Source)
at
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTa
bleCellRendererComponent(Unknown Source)

shows that lots of people think this is a bug in the JRE but I can't find
any suggested solution or workaround.

(Other than reverting to an earlier JRE ... which has bugs in the socket
handling that would stop my application working anyway.)

Get an XP box and refactor the code such that it works (there is
probably something slightly quirky (though probably quite valid) in your
original code that is causing this error). Once you have it sorted in a
non-hacky fashion then there it is highly unlikely to break on the win2k
machine(s).

John

 

[Tim Ward]

Get an XP box and refactor the code such that it works (there is
probably something slightly quirky (though probably quite valid) in your
original code that is causing this error). Once you have it sorted in a
non-hacky fashion then there it is highly unlikely to break on the win2k
machine(s).

I've acquired an XP box and it works fine, so this bug in the JRE depends
on some XP setting that I haven't identified yet. (Just as well it works,
mind, because NetBeans won't install on the XP box, so I couldn't fix it
anyway.)

 

[Roland]

I've acquired an XP box and it works fine, so this bug in the JRE depends
on some XP setting that I haven't identified yet. (Just as well it works,
mind, because NetBeans won't install on the XP box, so I couldn't fix it
anyway.)

Maybe something to do with XP themes?
If you look at the source of the nested class XPDefaultRenderer in
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI and class
com.sun.java.swing.plaf.windows.XPStyle.
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Tim Ward]

Maybe something to do with XP themes?

Yes, I assume so. But I can't break it by playing around with themes on my
box, and my customer can't make it work by playing around with themes on his
....

If you look at the source of the nested class XPDefaultRenderer in
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI and class
com.sun.java.swing.plaf.windows.XPStyle.

Yes. My copies of that source code are empty (probably 1.4.1 vintage). I'm
having difficulty summoning up the energy to find and download later
versions. I think I'll do some C++ for the rest of the afternoon ...

 

[Larry Barowski]

...
Further research, searching for the last bits of the backtrace:

Exception in thread "main" java.lang.NullPointerException
at javax.swing.border.EmptyBorder.<init>(Unknown Source)
at
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTa
bleCellRendererComponent(Unknown Source)

We get this occasionally. With a few tens of thousands of users,
probably 1/3 of those using Windows L&F, and automatic uncaught
exception reporting (with user approval), we probably see one or two
per month. So for our software at least, it seems to be random and quite
rare - less than 1/100,000 runs. It always happens when the gui is first
made visible, and we haven't seen any similar bugs for other L&Fs. It
seems to happen under all Java 1.4 and 1.5 versions, and not in 1.3.

In case someone wants to try to track down the problem, here is a trace
with line numbers under Java 1.4.2_05
at javax.swing.border.EmptyBorder.<init>(EmptyBorder.java:54)
at
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTa
bleCellRendererComponent(WindowsTableHeaderUI.java:63)
at
javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderRenderer(BasicTableHeader
UI.java:394)
at
javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderHeight(BasicTableHeaderUI
..java:428)
at
javax.swing.plaf.basic.BasicTableHeaderUI.createHeaderSize(BasicTableHeaderU
I.java:454)
at
javax.swing.plaf.basic.BasicTableHeaderUI.getPreferredSize(BasicTableHeaderU
I.java:485)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1275)

This also shows up in Sun bug 5027059 for netbeans, but it is closed
as "not reproducible" with note "Not a problem on later versions of
JDK 1.4.2 (bug reported on b28)."

 

[Tim Ward]

We get this occasionally. ....

Thanks for the info.

 

[Nigel Wade]

com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTa

We get this occasionally. With a few tens of thousands of users,
probably 1/3 of those using Windows L&F, and automatic uncaught
exception reporting (with user approval), we probably see one or two
per month. So for our software at least, it seems to be random and quite
rare - less than 1/100,000 runs. It always happens when the gui is first
made visible, and we haven't seen any similar bugs for other L&Fs. It
seems to happen under all Java 1.4 and 1.5 versions, and not in 1.3.

In case someone wants to try to track down the problem, here is a trace
with line numbers under Java 1.4.2_05
at javax.swing.border.EmptyBorder.<init>(EmptyBorder.java:54)
at
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTa
javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderRenderer(BasicTableHeader
javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderHeight(BasicTableHeaderUI
javax.swing.plaf.basic.BasicTableHeaderUI.createHeaderSize(BasicTableHeaderU
javax.swing.plaf.basic.BasicTableHeaderUI.getPreferredSize(BasicTableHeaderU
I.java:485)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1275)

This also shows up in Sun bug 5027059 for netbeans, but it is closed
as "not reproducible" with note "Not a problem on later versions of
JDK 1.4.2 (bug reported on b28)."

Is there any chance that this is a GUI initialization thread (EDT vs. main)
race condition? Do you at any stage initialize or modify any part of the
GUI in the main thread? The fact that it only occurs when the GUI is first
made visible might be a clue.

I've been hit by this GUI initialization thread race condition, but since I
changed to initializing everything in the EDT via
SwingUtilities.invoke_later() it's never recurred.

 

[Larry Barowski]

Is there any chance that this is a GUI initialization thread (EDT vs. main)
race condition? Do you at any stage initialize or modify any part of the
GUI in the main thread? The fact that it only occurs when the GUI is first
made visible might be a clue.

No, we start everything on the EDT. Also, I must correct myself -
this can also happen when the L&F is changed after the gui is up,
but only immediately after it is changed to Windows L&F.

 

[John C. Bollinger]

We get this occasionally. With a few tens of thousands of users,
probably 1/3 of those using Windows L&F, and automatic uncaught
exception reporting (with user approval), we probably see one or two
per month. So for our software at least, it seems to be random and quite
rare - less than 1/100,000 runs. It always happens when the gui is first
made visible, and we haven't seen any similar bugs for other L&Fs. It
seems to happen under all Java 1.4 and 1.5 versions, and not in 1.3.

In case someone wants to try to track down the problem, here is a trace
with line numbers under Java 1.4.2_05
at javax.swing.border.EmptyBorder.<init>(EmptyBorder.java:54)
at
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTa
bleCellRendererComponent(WindowsTableHeaderUI.java:63)
at
javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderRenderer(BasicTableHeader
UI.java:394)
at
javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderHeight(BasicTableHeaderUI
.java:428)
at
javax.swing.plaf.basic.BasicTableHeaderUI.createHeaderSize(BasicTableHeaderU
I.java:454)
at
javax.swing.plaf.basic.BasicTableHeaderUI.getPreferredSize(BasicTableHeaderU
I.java:485)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1275)

This also shows up in Sun bug 5027059 for netbeans, but it is closed
as "not reproducible" with note "Not a problem on later versions of
JDK 1.4.2 (bug reported on b28)."

So I was looking for a productive way to avoid the work I *really* ought
to be doing, and this looked promising. I haven't fully characterized
the problem, and I am doing this strictly from the source code, but it
appears to arise because the unique
com.sun.java.swing.plaf.windows.XPStyle instance fails to correctly or
fully initialize itself. This results in
XPStyle.getXP().getSkin("header.headeritem") returning null, and it is
the dereference of this null that produces the NPE.

It looks like it would be pretty easy for the XPStyle class to fail in
this way if some of its expectations about the desktop properties were
not met (see lines 648 to 683 in its source in 1.4.2). It is not clear
to me, however, whether the class is making unreasonable assumptions
about the desktop properties, or whether the client's desktop is just
screwed up. It looks likely, however, that if the client got his
desktop configuration to conform with the L&F's expectations (in the
sense of exposing all the expected properties) then the problem would go
away. Don't ask me how he would do that.

<guess type="wild">
Is there any chance that the client has twiddled an OS-level security
setting that now prevents the app from being able to read the desktop
properties?
</guess>

 

[steve]

I've got this Swing application developed, and working in the field, on
Win2k which I'm told crashes on XP.

I've been sent a backtrace which seems to indicate that it falls over in:

com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer

so this looks like a problem to do with incompatibilities between the XP
look and feel and the Win2k one.

Have I got this right so far?

If so, then given that my development box is running Win2k, how do I find
out what parameter to pass to UIManager.setLookAndFeel() to make it run the
XP look and feel so I can debug the problem? Or is this impossible because
the XP UI code will only run on XP so I'll need to acquire an XP box?

you buy a mac G4 , and a copy of virtual pc. then you can run any flavour of
windows from a disk image.
95/98/me/2000/xp


come join us , don't be afraid.