Java: how can an impossible NullPointerException still occur?

Question

I've just received following bug report for our Software:

java.lang.NullPointerException
    at java.util.Arrays.equals(Unknown Source)
    at our.app.OurMain(OurMain.java:13)

This happens with JRE 1.7.0_45 on Windows for which the corresponding source code of Arrays.equals is:

public static boolean equals(byte[] a, byte[] a2) {
    if (a==a2)
        return true;
    if (a==null || a2==null)
        return false;

    int length = a.length;
    if (a2.length != length)
        return false;

    for (int i=0; i<length; i++)
        if (a[i] != a2[i])
            return false;

    return true;
}

Calling code is:

final byte[] b1 = ... // populate array
final byte[] b2 = ... // populate array
final boolean equal = Arrays.equals(b1, b2);

There is obviously no way for a NullPointerException to be raised here. How can it still happen? The bug report can be considered trustworthy.

Answer 1

This is not intended as an answer, but since it'll be too long as a comment...

One question that hasn't been asked yet is: When did the problem start appearing? After a specific update of your software or out of the blue? You may not be able to track down the exact date when it first occured, but if it can be correlated to time its likely that whatever you deliver as the software underwent a change (e.g. do you bundle the JRE?) causing the issue. You would then methodically disect the changes between a known pre-error release against the first error manifesting release.

If it came out of the blue, the most likely the source of the problem (as far as I can tell from what you have disclosed) is hidden somewhere in the execution environment of your software (which is possibly not under your direct control). It could be the JRE itself, related libraries or system services, possibly even specific a combination of hardware and software (believe it or not, sometimes apparently even the BIOS of a workstation can have a drastic impact: https://www.daniweb.com/hardware-and-software/microsoft-windows/windows-vista-and-windows-7-8/threads/271699).

To improve your chances of actually getting to the cause of the problem, you will need to gather information in which environment(s) the error actually surfaces, and as much as possible (at least JRE version, 32/64 bit, OS; preferably installed patches, CPU model; preferably including mask set revision, motherboard model; preferably including BIOS version and board revision). Not to forget the exact release or your software causing the issue. If your userbase has a very homogenous environment (e.g. in a large company only a few workstation models are purchased, possibly all from the same vendor) the little details are of more interest than if the user base is very heterogenous (e.g. many independent customers using wildly different configurations).

Given enough data a pattern should emerge (something all error reports have in common, like a specific JRE; or set of JRE versions, specific workstation model etc.).

If possible have your users cooperate with you (intentionally alter the environment of a machine/user experiencing the issue) to test out candidates. This can involve installing the JDK to get more error context, altering VM settings and so on.

Only a rough outline, but if no quick solution turns up, a methodical approach is most likely to produce a solution in the long run.