Re: Strange null-pointer
Daniel
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
Daniel
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
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.
<http://www.physci.org/codes/sscce.jsp>.
>..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
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane
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
>>..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?
>You almost certainly are (wrong, that is).
I was afraid thatwould be the case :)
>> 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.
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
> > 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..
/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'! ]
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
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
Daniel
<nob...@ericsson.invalid> wrote:
>Daniel wrote:
>> 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?
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
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
>
>>On Fri, 17 Jun 2005 18:21:08 +0200, Thomas Weidenfeller
>>
>>>Daniel wrote:
>>>> 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.
>>>You also did check Sun's bug parade, didn't you?
>>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.
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.
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
>>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,
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
>>>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,
>
>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
news:jfp8b1hean51fhlcj...@4ax.com:
Look at the discussion in the bug report. Several users provided
workaround methods. For example, x-root on 17 Dec 2003.
--
Ian Shef 805/F6 * These are my personal opinions
Raytheon Company * and not those of my employer.
PO Box 11337 *
Tucson, AZ 85734-1337 *
Andrew Thompson
> Daniel <daik.n...@mds.nospam.mdh.se> wrote in
(NPE in dialog due to PLAF icon)
>>>>> 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. ..
>>>Given you can catch the NPE there may be better ways to
>>>deal with the problem, including ..
..
> 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>