Winston Gutkowski wrote:
Mark Brunson wrote:ok, confirmed doesn't make a difference to override the remove method, same problems, doesn't catch the null in my shell class:
Hmmm. Not quite sure what to suggest then. It may be worth pointing out that there are at least two more update methods: removeAll() and retainAll(). For completeness, you should also override contains(), containsAll(), indexOf() and lastIndexOf(), since they all take element values (or collections) too.
The fact is that NPE is a very simple error: something, somewhere is null when it shouldn't be. It's tracking down the 'where' that can be an absolute sod.
Good luck.
Winston
Winston Gutkowski wrote:
Mark Brunson wrote:...and changed the variable to this class instead of ArrayList. There has been no change in the problem; nullError() is never called, but o==null still sometimes evaluates to true in the equals method while ArrayList tries to remove an element.
I don't see a remove() method. Did you write one? I thought the whole point of your test was to make sure that no List update method could be supplied a null value.
Winston
Winston Gutkowski wrote:
Mark Brunson wrote:I mostly just want to figure out why null objects are getting into the list in this particular instance, because it seems impossible and I want to understand what's going on. I don't have an intrinsic problem with nulls being there, I'm just confused that they are.
Fair enough.
Well, assuming that your code uses Lists, rather than ArrayLists (as it should), I still reckon you could use a NoNullsList as I described above(*) as a test vehicle to work out where it's happening.
You never know, you might even find it useful enough to keep around for other things.
Winston
[Edit] Actually, if you define it as I described, you should be able to substitute it for an ArrayList as well.
Jeff Verdegan wrote:Also, just as a side note, from the small bit of your code that I've seen, it looks like you're in the habit of doing a lot of null checks. I'd get out of that habit. It clutters your code for no real benefit. There are certain cases where you want to test for null and log an error and continue (such as at major architectural layer boundaries, or when you're processing a bunch of independent things in a loop and you don't want a failure in one to kill the others). Most of the time though, it's best just to let them happen and then go back and fix the bug that caused them in the first place.
Or maybe you just added them as part of your debugging process, which is fine.
Winston Gutkowski wrote:
Mark Brunson wrote:The code I posted in that last post there is from the java.util.ArrayList source, which shouldn't really have any bugs in it right? If I didn't put a null value into an ArrayList, it shouldn't be calling my equals methods with null values as parameters right?
Right, but how are you preventing that?
ArrayList certainly doesn't; as you'll discover if you look at the contains() method docs.
Also, equals() seems an odd place to be putting this sort of logic, since there's nothing intrinsically wrong with comparing an object with null.
Have you considered extending ArrayList to define a List that doesn't allow null values to be added, or a null value to be supplied to remove()?
Matthew Brown wrote:Maybe I'm not being clear, or I'm misunderstanding you. But take this case:
There are two things that could cause a comparison with null here.
- list contains null
- x is null
You appear to have ruled out the first one, unless you're missing something. But what about the second? That's what I was getting at - what about the w in your second code snippet? Have you confirmed that is not null?
Matthew Brown wrote:
Mark Brunson wrote:the problem I'm talking about here is that o==null evaluates to true. On the line in ArrayList (in the remove method) pointed to by the stacktrace, the parameter it passes is
Which could still be null - array entries are null until they are populated. Have you checked that it isn't?
Matthew Brown wrote:A null in the list isn't the only possible explanation (as you've explained it). How about the object you're trying to remove? Can that be null?
Campbell Ritchie wrote:Unzip the jar and read its manifest file. You can find out about manifest files here.
gurpeet singh wrote:to be able to run a jar file by clicking on it you require an executable jar . also the jar in question should have main method. that is but obvious. when you compile and build project in netbeans it automatically creates executable jar of your project in dist directory of your project folder. this is one way. you can also manually make executable jar file by adding manifest file with Main-class attribute. for that you need to refer some tutorial on the internet.