This has bothered me enough to go rummaging through the Java Language Spec (third edition) and find section 12.7, Unloading of Classes and Interfaces[*]. But I can’t tell if it’s attempting a “must not” or a “should not” or what.

So, my best guess is that, assuming there are no actual instances of DBAsset floating around, the runtime thinks no-one cares about the class, unloads it, and then reloads it later when someone else refers to it — and the spec feels that this Really Shouldn’t Happen, but is unable to entirely forbid it, and why would a decent Java program have an uninstantiated class with actual state?

(Which could explain why I can’t reproduce it: my little test program with an int counter isn’t generating any memory pressure, or my JRE is different, or both.)

[*] http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.7 (and hopefully the URL won’t be a problem)

I put a System.out.println in the code where insertStmt was initialized, and where it was used, and somewhere between being initialized (and it was printing out as non-null) and it being used, it just spontaneously changed to null. The only other culprit was the “private static PreparedStatement insertStmt = null;”. I took out the “= null”, and it worked perfectly.