Why Eclipse null pointer analysis failed to recognize assertion utilities?

I am asking the question more from a compiler theory point of view. Why null pointer analysis failed to consider the effect of Assert.notNull()?

The Assert method is from Spring and it is implemented as:

public static void notNull(Object object, String message) {
    if (object == null) {
        throw new IllegalArgumentException(message);
    }
}

public static void notNull(Object object) {
    notNull(object, "[Assertion failed] - this argument is required; it must not be null");
}

(This becomes quite annoying because if I use this kind of assertion utilities, the first access to that variable after the assertion causes a warning, which prevents me from achieving warning-free code.)

If I inline the assertion routine completely, the access to a will not be marked as null pointer access (in this trivial case, it will become dead code). However, a static method cannot be overridden (not without bytecode fiddling), so what would be the rationale from a compiler designer's POV to not go inside the method call for null pointer analysis?

Is it just performance concern or is there something that prevents this from being done in general? Or to make it consistent with other compiler checks (dead code analysis did not consider that method either)?

This is of course more a discussion than a question.

1. The jar's you compile with is not necessarily the jar you run with. Especially Assert would be a candidate to have a different implementation in production environment.

2. A null pointer error would be better than a dead code error (here).

3. The eclipse compiler continuously compiles in the background. So as intelligence is paid with speed loss, this check might be more for a tool like findbugs. (Think of all library calls, that via a runtime exception might disrupt the control flow.)