Consider

---%<---
import java.util.Collections;
import java.util.Map;
public class UnhelpfulNPEs {
    public static void main(String[] args) {
        try {
            System.err.println(UnhelpfulNPEs.class.getProtectionDomain().getCodeSource().getCodeSigners()[0]); // NPE
        } catch (Exception e) {
            e.printStackTrace();
        }
        try {
            Map<String,Integer> numbers = Collections.singletonMap("X", 5);
            int x = numbers.get("x"); // NPE
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
---%<---

producing just

---%<---
java.lang.NullPointerException
        at UnhelpfulNPEs.main(UnhelpfulNPEs.java:6)
java.lang.NullPointerException
        at UnhelpfulNPEs.main(UnhelpfulNPEs.java:12)
---%<---

For the first case it is not obvious which method actually returned null. -g:lines does not help you much here, especially if you have a complex, multiline expression in a single statement. In a realistic program it is not so unusual for there to be multiple methods in the statement which might return null under some conceivable conditions. (It is especially hard to know this in the absence of a standard @NotNull annotation.)

For the second case, most Java developers will stare long and hard at the expression trying to imagine how Collections.singletonMap could return null, thus leaving 'numbers' null - the only apparent member access in the statement. Of course the problem is not the call to numbers.get("x") at all, but the resulting auto-unboxing.

In any program with long, complicated methods, it is quite common to receive bug reports from the field showing a NullPointerException. Usually you can figure out what the proximate cause of the NPE was from the line number in the stack traces, except

1. in the cases above

2. when the code was compiled without debugging information

3. when there have been changes in the class since the last public release and you are not sure which exact version of the class the end user was running

Sometimes developers even fix "the NPE" that was apparently reported, when in fact the user encountered a different nearby NPE.

What is frustrating is that the JVM knows some useful things about the cause of the exception but is refusing to tell you in the detail message.