"Write once, test everywhere" - Win2K / XP

Discussion in 'Java' started by Tim Ward, May 11, 2005.

  1. Tim Ward

    Tim Ward Guest

    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?

    --
    Tim Ward
    Brett Ward Limited - www.brettward.co.uk
     
    Tim Ward, May 11, 2005
    #1
    1. Advertising

  2. Tim Ward

    Daniel Dyer Guest

    On Wed, 11 May 2005 10:30:50 +0100, Tim Ward <> wrote:

    > 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.


    --
    Daniel Dyer
    http://www.footballpredictions.net
     
    Daniel Dyer, May 11, 2005
    #2
    1. Advertising

  3. Tim Ward

    Tim Ward Guest

    "Daniel Dyer" <> wrote in
    message news:eek:...
    >
    > 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.)

    --
    Tim Ward
    Brett Ward Limited - www.brettward.co.uk
     
    Tim Ward, May 11, 2005
    #3
  4. Tim Ward

    John Guest

    Tim Ward wrote:
    > "Daniel Dyer" <> wrote in
    > message news:eek:...
    >
    >>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.)
    >
    > --
    > Tim Ward
    > Brett Ward Limited - www.brettward.co.uk
    >
    >


    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
     
    John, May 11, 2005
    #4
  5. Tim Ward

    Tim Ward Guest

    "John" <no@email> wrote in message
    news:4281e6de$0$2601$...
    >
    > 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.)

    --
    Tim Ward
    Brett Ward Limited - www.brettward.co.uk
     
    Tim Ward, May 11, 2005
    #5
  6. Tim Ward

    Roland Guest

    On 11-5-2005 14:06, Tim Ward wrote:

    > "John" <no@email> wrote in message
    > news:4281e6de$0$2601$...
    >
    >>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.)
    >
    > --
    > Tim Ward
    > Brett Ward Limited - www.brettward.co.uk
    >
    >

    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_/ /__/
    / \ /_/ / \
     
    Roland, May 11, 2005
    #6
  7. Tim Ward

    Tim Ward Guest

    "Roland" <> wrote in message
    news:4281fa1f$0$61568$4all.nl...
    > On 11-5-2005 14:06, Tim Ward wrote:
    >
    > > "John" <no@email> wrote in message
    > > news:4281e6de$0$2601$...
    > >
    > >>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.)
    > >

    > 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 ...

    --
    Tim Ward
    Brett Ward Limited - www.brettward.co.uk
     
    Tim Ward, May 11, 2005
    #7
  8. "Tim Ward" <> wrote in message
    news:...
    > "Daniel Dyer" <> wrote in
    > message news:eek:...
    > >

    > ...
    > 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)."
     
    Larry Barowski, May 12, 2005
    #8
  9. Tim Ward

    Tim Ward Guest

    "Larry Barowski" <MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote in
    message news:...
    >
    > We get this occasionally. ....


    Thanks for the info.

    --
    Tim Ward
    Brett Ward Limited - www.brettward.co.uk
     
    Tim Ward, May 13, 2005
    #9
  10. Tim Ward

    Nigel Wade Guest

    "Larry Barowski" <MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote:

    >
    > "Tim Ward" <> wrote in message
    > news:...
    >> "Daniel Dyer" <> wrote in
    >> message news:eek:...
    >> >

    >> ...
    >> 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)."


    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.

    --
    Nigel Wade, System Administrator, Space Plasma Physics Group,
    University of Leicester, Leicester, LE1 7RH, UK
    E-mail :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
     
    Nigel Wade, May 13, 2005
    #10
  11. "Nigel Wade" <> wrote in message
    news:d61vvf$fld$...
    > 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.
     
    Larry Barowski, May 13, 2005
    #11
  12. Larry Barowski wrote:

    > "Tim Ward" <> wrote in message
    > news:...
    >
    >>"Daniel Dyer" <> wrote in
    >>message news:eek:...
    >>
    >> ...
    >>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)."


    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>

    --
    John Bollinger
     
    John C. Bollinger, May 13, 2005
    #12
  13. Tim Ward

    steve Guest

    On Wed, 11 May 2005 17:30:50 +0800, Tim Ward wrote
    (in article <>):

    > 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?
    >
    > --
    > Tim Ward
    > Brett Ward Limited - www.brettward.co.uk
    >
    >



    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.
     
    steve, May 14, 2005
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Good Enchiladas

    Remote Debugging ASP.NET VS.NET Win2K?

    Good Enchiladas, Apr 13, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    510
    Good Enchiladas
    Apr 13, 2004
  2. llama
    Replies:
    0
    Views:
    969
    llama
    Jul 23, 2003
  3. GO
    Replies:
    4
    Views:
    515
  4. Cy Huckaba
    Replies:
    1
    Views:
    1,153
    Xie Xiao
    Jun 26, 2003
  5. Michael Huhn
    Replies:
    0
    Views:
    329
    Michael Huhn
    Aug 13, 2003
Loading...

Share This Page