Strange null-pointer

[Daniel]

Hello,
Sometimes (not very frequent thank god) I get the following
NullPointerException when i start my application. If I just restart
the application (i.e no change in the code) it starts fine. As you
can see it is constructors that cause this. What is strange is that on
the line in EventLog that causes this is this line:
private JFileChooser filec= new JFileChooser();
(and in MainWindow I have
private EventLog eventLog = new EventLog();
)

So what can be the issue here? Is it something I do that I should not,
or is it something I don't do that I should?
I kind of feel I am actually innocent of causing this, but I may be
wrong of course

any thoughts are welcome.


java.lang.NullPointerException
at javax.swing.ImageIcon.<init>(ImageIcon.java:161)
at javax.swing.ImageIcon.<init>(ImageIcon.java:147)
at
com.sun.java.swing.plaf.windows.WindowsFileChooserUI$ShortCutPanel.<init>(WindowsFileChooserUI.java:603)
at
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponents(WindowsFileChooserUI.java:361)
at
javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:130)
at
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installUI(WindowsFileChooserUI.java:176)
at javax.swing.JComponent.setUI(JComponent.java:449)
at javax.swing.JFileChooser.updateUI(JFileChooser.java:1701)
at javax.swing.JFileChooser.setup(JFileChooser.java:345)
at javax.swing.JFileChooser.<init>(JFileChooser.java:320)
at javax.swing.JFileChooser.<init>(JFileChooser.java:273)
at se.wexiodisk.service.EventLog.<init>(EventLog.java:69)
at se.wexiodisk.service.MainWindow.<init>(MainWindow.java:72)
at
se.wexiodisk.service.Diagnosetool.<init>(Diagnosetool.java:37)
at
se.wexiodisk.service.Diagnosetool.main(Diagnosetool.java:53)

regards
Daniel

 

[Daniel]

I realize, I should probably post my java version as well. so here is
the output from java -version

java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)
Running on windows 2000

/daniel

 

[Andrew Thompson]

Hello,
Sometimes (not very frequent thank god)

God does not lower Himself to bit twiddling, but I
see you believe in an interprogamist God.

...I get the following
NullPointerException when i start my application.

It is almost impossible to interpret a stacktrace when
you cannot match the line numbers in the trace back to
the code snippet. Insread I suggest an SSCCE.

..If I just restart
the application (i.e no change in the code) it starts fine. As you
can see it is constructors that cause this.
Really?

...What is strange is that on
the line in EventLog that causes this is this line:
private JFileChooser filec= new JFileChooser();
(and in MainWindow I have
private EventLog eventLog = new EventLog();
)

So what can be the issue here? Is it something I do that I should not,
or is it something I don't do that I should?
Yes.

I kind of feel I am actually innocent of causing this, but I may be
wrong of course

You almost certainly are (wrong, that is).

any thoughts are welcome.

Supply an SSCCE.
But then, looking at your stack trace..

java.lang.NullPointerException
at javax.swing.ImageIcon.<init>(ImageIcon.java:161)

...images often load asynchronously in Java. You possibly
need to add a MediaTracker to the image loading.

 

[Andrew Thompson]

java version "1.4.2_01"

Java versions of 1.4.2 had a security flaw that was
fixed in version 1.4.2_06. You should upgrade, though
upgading to 1.5.0_03 makes more sense.

 

[Daniel]

Really?

yes, just a restart and all works fine.

You almost certainly are (wrong, that is).

I was afraid thatwould be the case

Supply an SSCCE.
But then, looking at your stack trace..


..images often load asynchronously in Java. You possibly
need to add a MediaTracker to the image loading.

but also, looking in the stacktrace. it is in the JFileChooser this
happens. I.e out of my control. Neither of the classes that figures in
this stacktrace loads any images. (classes I have written)
So I can not add a MediaTracker.
I will try to see if I can reproduce the problem with an SSCCE, I have
not run into this problem before.
Tracing back to code lines only gives you what I wrote. i.e two calls
to constructors.

As I said, my feeling is that it is something going wrong when the
JFileChooser loads one of it's images.. But I can of course not be
sure.


I will probably upgrade fairly soon though, hopefully this problem
will go away then.

 

[Tor Iver Wilhelmsen]

java.lang.NullPointerException
at javax.swing.ImageIcon.<init>(ImageIcon.java:161)
at javax.swing.ImageIcon.<init>(ImageIcon.java:147)
at
com.sun.java.swing.plaf.windows.WindowsFileChooserUI$ShortCutPanel.<init>(WindowsFileChooserUI.java:603)
at
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponents(WindowsFileChooserUI.java:361)

It would seem your JRE install is broken; the Windows L&F cannot find
the icon images it needs for JFileChooser.

Try setting a different L&F and see how it behaves then.

 

[Andrew Thompson]

It would seem your JRE install is broken; the Windows L&F cannot find
the icon images it needs for JFileChooser.

The OP mentioned it would work the second time. I cannot see
how the JRE install could be broken the first time but not the
second..

 

[Chris Uppal]

The OP mentioned it would work the second time. I cannot see
how the JRE install could be broken the first time but not the
second..

/Maybe/ that could happen with a network installation. If there's some Sun
code somewhere that assumes that the icon image will be available instantly,
but that assumption fails when the icon has to be fetched across a network. In
the subsequent attempt the OS might have the file data cached, so this time it
suppled the data faster and /presto/ it works !

Pure speculation, of course...

-- chris

 

[Andrew Thompson]

Pure speculation, of course...

'An SSCCE is worth a thousand speculations.' ;-)

[ Having said that, you'll probably turn out to have
'hit the nail on the head'! ]

 

[Daniel]

Pure speculation, of course...

'An SSCCE is worth a thousand speculations.' ;-)

[ Having said that, you'll probably turn out to have
'hit the nail on the head'! ]

fraid that's not the case. it is a local installation. running from a
local device. I just find it really strange. Usually re-running the
code gives the same kind of problem. especially in cases like this.

But this time re-running the application will cause it to work. Most
strange.
I guess it may be an issue with the 1.4.2 version of java.
But I've done quite a bit of programming with this installation and it
has never caused any problems before.
As I said I will try to reproduce the problem with a SSCCE, but I
highly doubt it is possible, since I have problems reproducing it as
it is!
(which indicates a threading issue I think. so I think the idea that
java loads images asynconisly is probably what it boils down to.
*most* of the time it is not a problem, but every once in a while it
causes some problems.)

regads Daniel

 

[Thomas Weidenfeller]

But this time re-running the application will cause it to work. Most
strange.
I guess it may be an issue with the 1.4.2 version of java.

It is likely an issue with messing up threading in your code. You did
follow the single-tread rule for Swing, didn't you?

You also did check Sun's bug parade, didn't you?

/Thomas

 

[Daniel]

It is likely an issue with messing up threading in your code. You did
follow the single-tread rule for Swing, didn't you?

this I did. but as the problems occur in the constructors, so unless
I've missunderstood the single-thread rule, it is okay to create the
components in any thread, and then just make sure I show them via EDT,
or must they be constrcuted in EDT as well?

You also did check Sun's bug parade, didn't you?

that I have not done, but I wil have a look there now.

regards Daniel

 

[Daniel]

this I did. but as the problems occur in the constructors, so unless
I've missunderstood the single-thread rule, it is okay to create the
components in any thread, and then just make sure I show them via EDT,
or must they be constrcuted in EDT as well?


that I have not done, but I wil have a look there now.

I have now looked in the bug reports and yes it is there. Bug ID
4711700 The exact problem I have, so that means it is not a problem
with my code, just the version of jvm I run.
Thanks for all your input.


regards Daniel

 

[Andrew Thompson]

On Sat, 18 Jun 2005 09:15:58 +0200, Daniel

I have now looked in the bug reports and yes it is there. Bug ID
4711700 The exact problem I have, so that means it is not a problem
with my code, just the version of jvm I run.

OK - I notice it is fixed in 1.5
<http://java.sun.com/j2se/1.5.0/fixedbugs/fixedbugs.html>

Here are two strategies you might try.

1) Use WebStart (or is it an applet? ..also <object>/<embed>
or the JaveVersionApplet) to ensure users have a minimum
version of Java 1.5.

2) Change the code to either avoid that situation or account
for it's possible behaviour in 1.4.

 

[Daniel]

OK - I notice it is fixed in 1.5
<http://java.sun.com/j2se/1.5.0/fixedbugs/fixedbugs.html>

Here are two strategies you might try.

1) Use WebStart (or is it an applet? ..also <object>/<embed>
or the JaveVersionApplet) to ensure users have a minimum
version of Java 1.5.

2) Change the code to either avoid that situation or account
for it's possible behaviour in 1.4.

yeah, my thoughts go along option 2 there. Although I think most of my
users will have 1.5. My idea is to catch the nullpointer and if it
happenes (it happens so rarely) pop up a JOptionPane telling the user
that "something bad happened, please restart the application, this
problem is fixed in java 1.5"

Kind of like the ostrich algortihm

 

[Andrew Thompson]

yeah, my thoughts go along option 2 there. Although I think most of my
users will have 1.5. My idea is to catch the nullpointer and if it
happenes (it happens so rarely) pop up a JOptionPane telling the user
that "something bad happened, please restart the application,

Given you can catch the NPE there may be better ways to
deal with the problem, including starting a thread that waits
a few moments before creating the chooser. That way the
user never needs to hear 'something bad happened'..

 

[Daniel]

Given you can catch the NPE there may be better ways to
deal with the problem, including starting a thread that waits
a few moments before creating the chooser. That way the
user never needs to hear 'something bad happened'..

hmm, true. I'll talk to the project manager and see what they think on
the subject. But since it is such unusual thing, I hardly doubt it's
really worth the effort. But I'll talk to him nonetheless and see what
he thinks about it.
Thanks for your input

regards
Daniel

 

[Ian Shef]

hmm, true. I'll talk to the project manager and see what they think on
the subject. But since it is such unusual thing, I hardly doubt it's
really worth the effort. But I'll talk to him nonetheless and see what
he thinks about it.
Thanks for your input

regards
Daniel

Look at the discussion in the bug report. Several users provided
workaround methods. For example, x-root on 17 Dec 2003.

 

[Andrew Thompson]

Daniel <[email protected]> wrote in

(NPE in dialog due to PLAF icon)

...
Look at the discussion in the bug report.

Well.. that is a very good point Ian.
Wish I'd had the sense to do that, some (checks watch)
3 and a half days before you first mentioned it!

..Several users provided
workaround methods. For example, x-root on 17 Dec 2003.

Yeah. I notice a couple of strategies - besides the
'wait and retry', Larry (Barowski) proposed a solution
as well, though he mentions the worrying
'(..fix) most of the time'.

But ultimately, there are a number of things that can be done
to correct this problem - including 'if all else fails - use a
PLAF that works ..or the AWT!' this last on the basis that the
user would probably prefer to see an 'ugly' dialog than either
a) nothing or
b) a dialog telling them 'their' Java is defective and they
need to upgrade (sometimes it is necessary - but not here)

<my recommendation>
This is definitely not a 'tell the user something bad happened'
situation. Just *make* it work!
</my recommendation>