krakatoa
asked on
How is this variable (vec) suddenly not being seen? (NPE). The code has not been altered since the calls last functioned properly.
vec = new Vector<String>(fArr.length); // Vector<String> vec declared earlier.
for(File fi : fArr){vec.add(fi.getName());}
for(Object s : vec.toArray()){System.out.println((String)s);} // this prints the filenames to the console
System.out.println("Files length is "+fArr.length);// prints whatever length the array is
System.out.print("vec is ");
System.out.println(vec==null); // prints TRUE !!
If what you are passing in fArr contains a file that is returing null for its filename, you could get a null pointer exception. Must likely that is what has changed, the input that is being passed in.
ASKER
But Jeff, all the files I pass in provide a valid name as you see in the code, those names all get printed.
ASKER
Output to the console as follows :
Files length is 4
vec is false
java.lang.NullPointerExcep tion
at Mistral$FileSender.sendFil es(Mistral .java:638)
at Mistral$FileSender.access$ 000(Mistra l.java:595 )
at Mistral.actionPerformed(Mi stral.java :182)
at javax.swing.AbstractButton .fireActio nPerformed (Unknown Source)
at javax.swing.AbstractButton $Handler.a ctionPerfo rmed(Unkno wn Source)
at javax.swing.DefaultButtonM odel.fireA ctionPerfo rmed(Unkno wn Source)
at javax.swing.DefaultButtonM odel.setPr essed(Unkn own Source)
at javax.swing.plaf.basic.Bas icButtonLi stener.mou seReleased (Unknown Sour
ce)
at java.awt.Component.process MouseEvent (Unknown Source)
at javax.swing.JComponent.pro cessMouseE vent(Unkno wn Source)
at java.awt.Component.process Event(Unkn own Source)
at java.awt.Container.process Event(Unkn own Source)
at java.awt.Component.dispatc hEventImpl (Unknown Source)
at java.awt.Container.dispatc hEventImpl (Unknown Source)
at java.awt.Component.dispatc hEvent(Unk nown Source)
at java.awt.LightweightDispat cher.retar getMouseEv ent(Unknow n Source)
at java.awt.LightweightDispat cher.proce ssMouseEve nt(Unknown Source)
at java.awt.LightweightDispat cher.dispa tchEvent(U nknown Source)
at java.awt.Container.dispatc hEventImpl (Unknown Source)
at java.awt.Window.dispatchEv entImpl(Un known Source)
at java.awt.Component.dispatc hEvent(Unk nown Source)
at java.awt.EventQueue.dispat chEventImp l(Unknown Source)
at java.awt.EventQueue.access $500(Unkno wn Source)
at java.awt.EventQueue$3.run( Unknown Source)
at java.awt.EventQueue$3.run( Unknown Source)
at java.security.AccessContro ller.doPri vileged(Na tive Method)
at java.security.ProtectionDo main$JavaS ecurityAcc essImpl.do Intersecti onP
rivilege(Unknown Source)
at java.security.ProtectionDo main$JavaS ecurityAcc essImpl.do Intersecti onP
rivilege(Unknown Source)
at java.awt.EventQueue$4.run( Unknown Source)
at java.awt.EventQueue$4.run( Unknown Source)
at java.security.AccessContro ller.doPri vileged(Na tive Method)
at java.security.ProtectionDo main$JavaS ecurityAcc essImpl.do Intersecti onP
rivilege(Unknown Source)
at java.awt.EventQueue.dispat chEvent(Un known Source)
at java.awt.EventDispatchThre ad.pumpOne EventForFi lters(Unkn own Source)
at java.awt.EventDispatchThre ad.pumpEve ntsForFilt er(Unknown Source)
at java.awt.EventDispatchThre ad.pumpEve ntsForHier archy(Unkn own Source)
at java.awt.EventDispatchThre ad.pumpEve nts(Unknow n Source)
at java.awt.EventDispatchThre ad.pumpEve nts(Unknow n Source)
at java.awt.EventDispatchThre ad.run(Unk nown Source)
------------------------
Line 638 is one one in the catch block here :
Files length is 4
vec is false
java.lang.NullPointerExcep
at Mistral$FileSender.sendFil
at Mistral$FileSender.access$
at Mistral.actionPerformed(Mi
at javax.swing.AbstractButton
at javax.swing.AbstractButton
at javax.swing.DefaultButtonM
at javax.swing.DefaultButtonM
at javax.swing.plaf.basic.Bas
ce)
at java.awt.Component.process
at javax.swing.JComponent.pro
at java.awt.Component.process
at java.awt.Container.process
at java.awt.Component.dispatc
at java.awt.Container.dispatc
at java.awt.Component.dispatc
at java.awt.LightweightDispat
at java.awt.LightweightDispat
at java.awt.LightweightDispat
at java.awt.Container.dispatc
at java.awt.Window.dispatchEv
at java.awt.Component.dispatc
at java.awt.EventQueue.dispat
at java.awt.EventQueue.access
at java.awt.EventQueue$3.run(
at java.awt.EventQueue$3.run(
at java.security.AccessContro
at java.security.ProtectionDo
rivilege(Unknown Source)
at java.security.ProtectionDo
rivilege(Unknown Source)
at java.awt.EventQueue$4.run(
at java.awt.EventQueue$4.run(
at java.security.AccessContro
at java.security.ProtectionDo
rivilege(Unknown Source)
at java.awt.EventQueue.dispat
at java.awt.EventDispatchThre
at java.awt.EventDispatchThre
at java.awt.EventDispatchThre
at java.awt.EventDispatchThre
at java.awt.EventDispatchThre
at java.awt.EventDispatchThre
------------------------
Line 638 is one one in the catch block here :
try{
if(!(vec == null)){oos.writeObject(vec);} //send the filenames
}catch(IOException oosexception){oosexception.printStackTrace();}
Based on what you pasted in it seems like the null pointer is coming after the block of code that you posted in the question. Is there more code executed after that we are missing?
ASKER
after the block of code that you posted . . .
Well yes it is, but it's literally the next statement after the first code . . . there's no call to anything or anywhere else. Here's how it looks in situ :
private void sendFiles(File[] fArr){
vec = new Vector<String>(fArr.length);
for(File fi : fArr){vec.add(fi.getName());}
for(Object s : vec.toArray()){System.out.println((String)s);} // this prints out the names as they should be - no glitches.
System.out.println("Files length is "+fArr.length);
System.out.print("vec is ");
System.out.println(vec==null);/*
System.out.print(" oos = ");
System.out.println(oos==null);
*/
try{
if(!(vec == null)){oos.writeObject(vec);} //send the filenames
}catch(IOException oosexception){oosexception.printStackTrace();}
Looking at the exception it looks like it is coming from a java swing library. The block of code you are sharing doesn't appear to be using any. Is there code that is running the interface that is calling this function? There might be something going on there instead.
Which is line 638 of the last code you posted?at Mistral$FileSender.sendFiles(Mistral.java:638)
Line 638 is one one in the catch block here :I missed that.
That's not possible. Do you mean the try block?
These are contradictory:
System.out.println(vec==null); // prints TRUE !!
Output to the console as follows :
Files length is 4
vec is false
ASKER
Yes, I meant thr try block.
I made a typo earlier too - so to be clear, line 638 is the issue- where oos (ObjectOutputStream), writes vec.
When, CEHJ, you say contradictory, I assume you mean that vec can’t be null if the filenames it contains get printed - is that what you mean?
Yes, the code is called from elsewhere - a swing context, whereby a FileChooser Open Files button sends the selected file(s) to this method. As I said, the exercise worked faultlessly until now, and I haven’t changed any of the codr. All I did change were some access qualifiers, but since both oos and vec can be seen in the method scope, how can line 638 complain NPE on vec?
I made a typo earlier too - so to be clear, line 638 is the issue- where oos (ObjectOutputStream), writes vec.
When, CEHJ, you say contradictory, I assume you mean that vec can’t be null if the filenames it contains get printed - is that what you mean?
Yes, the code is called from elsewhere - a swing context, whereby a FileChooser Open Files button sends the selected file(s) to this method. As I said, the exercise worked faultlessly until now, and I haven’t changed any of the codr. All I did change were some access qualifiers, but since both oos and vec can be seen in the method scope, how can line 638 complain NPE on vec?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'v really shot myself in the foot here - schoolboy error - yes, of course you're right, my simplistic hasty 'debug' is returning the polar opposite boolean. Doh.
So, back in reality . . . your declaration suggestion <<Vector<String> vec = new Vector<String>(fArr.length );>> - I've had that too, and I'll change it anyway, but it made no difference in terms of this particular side of the issue.
So it looks like oos must be null. That's odd if true, as it hasn't been touched since being written. Could the access modifiers' changes be at fault?
So, back in reality . . . your declaration suggestion <<Vector<String> vec = new Vector<String>(fArr.length
So it looks like oos must be null. That's odd if true, as it hasn't been touched since being written. Could the access modifiers' changes be at fault?
ASKER
Oh I think I know what 'must' be happening - the SSL handshake isn't being done correctly and the oos is derived from what should be the ssl socket. So I think I have to redo the params.
ASKER
The synergy did it; the synergy did it. Thanks to you both.
Still got to get it working fully, but btls this points to the direction.
Still got to get it working fully, but btls this points to the direction.
for(Object s : vec.toArray()){System.out.println((String)s);}
can be just
for(String s : vec) {System.out.println(s);}
. your declaration suggestion <<Vector<String> vec = new Vector<String>(fArr.lengthNo, i didn't think it would necessarily. But you should code defensively);>> - I've had that too, and I'll change it anyway, but it made no difference in terms of this particular side of the issue.
ASKER
Ok. Strange though - I thought I had that code you've posted as my first port of call, and it failed until it was cast. Perhaps my concentration dipped again, because it would be much better than the cast obviously. Thanks again anyway. ;)
:)
ASKER
Yes, the no cast worked of course. I suppose my superannuation means partly that 'I only trust myself' when it came to dealing with the returned Object[], which I knew to be one of String. Generics, y'know, they can addle one's formerly fixed notions. ;)
Yes. Of course, the principal point of generics is the provision of type-safety, so this of course means casting isn't necessary
ASKER
Yes.
I guess you read my earlier about the sslsocket rôle ? Groan. Another grind.
I guess you read my earlier about the sslsocket rôle ? Groan. Another grind.