if (lineTotal ==null)
lineTotal =new Money(tot);
elseif (Math.abs(lineTotal.longValue() - tot) > 0){// < null pointer
overrides |= 1;
wildTotal = Math.abs(lineTotal.longValue() - tot) > 2;
}
No doubt I'll kick myself. Note - no mutli-threading going on here and this is 1.4 so no autoboxing.
Nothing very interesting
long tot = (vatAmount != null) ? (net + vatAmount.longValue())
: (long) Math.round((float) net * (1f +
vatRate.getMultiplier()));
Nothing jumps out at me immediately. I'd recommend refactoring a bit so you can isolate what's going on. Liberally sprinkle in some logging and/or use a debugger.
That, or post an SSCCE* that duplicates the problem.
[EDIT] No more links allowed, apparently. Not necessarily a bad thing at this point.
* http://mindprod.com/jgloss/sscce.html
~
> Same objection - the top stack frame of the exception
> is right here, not in the Money class (which has been
> arround, unchanged, for a couple of years now, by the
> way).
Can you post an SSCCE that duplicates the problem?
> Anyway, stupid question: can you use a debugger?
I don't think that's a stupid question. At least I hope not, since I mentioned it previously. :o)
~
> > Money class (which has been
> > arround, unchanged, for a couple of years now, by
> the
> > way).
>
> Your money must be different from my money... :p
>
> Anyway, stupid question: can you use a debugger?
Yes, but it doesn't seem to happen under the debugger.
>And
> did you do a re-build, just for the sake of it?
I did a make, but you're right, a rebuild might be worth a try.
That was my first thought, too. But I've made changes in this class today, which have altered behaviour (i.e. it can't be an obsolete .class file). And even JDeveloper should be reliable enough to report the right line number in the source editor.
To confirm, I've just reformatted my source code, so that the offending line has moved to a new line number; still the exception stack frame indicates the same line (different line number).
Message was edited by:
malcolmmc
Tricky, since I'd have to know what's causing the problem. In fact, I'm running the code under the debugger at the moment, with a breakpoint on the line giving me the error. Under the debugger the line isn't even executed (and, from what the program is doing I wouldn't expect it to be).
I'm starting to wonder if the JIT compiler is producing a wrong line number for the exception.
> To confirm, I've just reformatted my source code, so
> that the offending line has moved to a new line
> number; still the exception stack frame indicates the
> same line (different line number).
One approach would be to use javap to dump the bytecode -- it could be that there's a typo that's unnoticeable looking at the Java code, but would appear in bytecode (ie, you see that the first "if" statement creates the new object and does astore_1, while the second "if" does an aload_2).
have you tried blocking your code into a couple of chucks and surrounding each chunck with a null pointer exception, each reporting a different error message until you get down to the offending line ? I know I have used that technique in the past when I didn't have a clue how something was getting a null pointer exception.
> It's a long shot, but lineTotal isn't static by any
> chance is it? I remember DrLaszlo posting something
> about static variables not being recompiled unless
> you clean and rebuild? Or something? Maybe it was
> static final variables. Does anyone know what I'm
> talking about?
I suppose I should ;-)
It was this:
public class C {
public static final String FOO = "bar";
}
public class Main {
public static void main(String[] args) {
System.out.println(C.FOO);
}
}
In this code, the value of C.FOO is folded into Main.class. So that if you edit C.java and make FOO = "hoppity", and rerun Main without recompiling it,
you will still see "bar" because of the folded-in constant.
I have no idea if that is relevant to this bug, but the way around this (apart from being smarter about compiling) is to write:
public class C {
public static final String FOO;
static {
FOO = "bar";
}
}
Yeah, that's it!
Note: If a primitive type or a string is defined as a constant and the value is known at compile time, the compiler replaces the constant name everywhere in the code with its value. This is called a compile-time constant. If the value of the constant in the outside world changes (for example, if it is legislated that pi actually should be 3.975), you will need to recompile any classes that use this constant to get the current value.
Looks like it only applies to primitives and Strings through :(
Why did you change your username anyway Dr. Jamz?
>Why did you change your username anyway Dr. Jamz?
Too many newbies missed the literary reference and thought I
was some august Hungarian professor. I also cracked 10K posts
and hauled a platinum star. Those, too, added gravitas that I don't look for.
I'd rather be the guy with the starchy French nom de guerre.
> >Why did you change your username anyway Dr. Jamz?
>
> Too many newbies missed the literary reference and
> thought I
> was some august Hungarian professor. I also cracked
> 10K posts
> and hauled a platinum star. Those, too, added
> gravitas that I don't look for.
> I'd rather be the guy with the starchy French nom
> de guerre.
I always pictured you as a nerdy dj, mainly because I always read it as Jamz. It was quite entertaining.
> >I always pictured you as a nerdy dj, mainly because
> I always read it as Jamz. It was quite entertaining.
>
> it's hard to convey what a ringer you are for Arnold
> Schwarzenegger in his prime, using just a user name.
You don't feel that hippo does enough justice ? ;-P
> > You don't feel that hippo does enough justice ?
> ;-P
>
> Hippolyte was an Amazon queen whose girdle is the
> object of one of the labours of Heracles. That's
> ber-macho, right?
Oh, indeed. Nothing says tough-guy like the words "queen" and "girdle" in close proximity.
>
> No doubt I'll kick myself. Note - no mutli-threading
> going on here and this is 1.4 so no autoboxing.
So was this resolved?
If not..
- Threading issue. Something is changing it to null
- Hotspot compiler issue. In this case you have to reformat the code.
Just a shot in the dark, but,
wrapping the line executed after the (==null) check in brackets?
if (lineTotal == null)
{
System.out.println("lineTotal==null, creating new one");
lineTotal = new Money(tot);
}
else if (Math.abs(lineTotal.longValue() - tot) > 0) { // < null pointer
overrides |= 1;
wildTotal = Math.abs(lineTotal.longValue() - tot) > 2;
ALSO... As written, if lineTotal==null, it will create a new one, but not execute the "else if" part on it...is that what you intended?
> > Anyway, stupid question: can you use a debugger?
>
> Yes, but it doesn't seem to happen under the
> debugger.
The last time that happend to me, there were some old class files lying around that got loaded instead of the newly compiled ones, which messed up step-by-step debugging.
> >And
> > did you do a re-build, just for the sake of it?
>
> I did a make, but you're right, a rebuild might be
> worth a try.
Which did fix the issue for me, so my money's on the clean rebuild.
I tried the rebuild. Still happening (and getting beyond a joke). I'll probably try decompiling, but it's a fair sized class to wade through (and this is one of the larger methods).
No, it's not a static field or anything (though it's in an inner class). I'm reading invoice lines in using a template, so that various fields may, or may not, be explicitly given. Some fields (line the line total) can be calculated if not supplied, but must be accepted "as is" if supplied.
This processing is a straight, IO bound scan. No threading.
> What does your Money.longValue() method look like? Is
> it derived?
Couldn't be much simpler:
public long longValue()
{
return pence;
}
(Money extends Number, by the way).
> It's a long shot, but lineTotal isn't static by any
> chance is it? I remember DrLaszlo posting something
> about static variables not being recompiled unless
> you clean and rebuild? Or something? Maybe it was
> static final variables. Does anyone know what I'm
> talking about?
Static imports?
Oh No! It's gone away! I hate it when that happens.
Unfortunately this is an ADF based web-app, so nothing but Oracle environments will touch it with a barge pole.
I noticed that the JVM option was set to -ojvm so, on the basis that it's usually Oracle's fault, I changed the jvm option to -server. The problem didn't happen. "Aha!" I thought, until I switched it back to -ojvm to confirm and guess what? It still doesn't happen.
Bangs head on desk
Of course, this problem will come back as soon as I make my changes live.
