NullPointerException is logged different in prod and local env

Check that you are really using the same Java version in local and prod. Consider this test program:

public class Main {
    public static void main(String... args) throws NoSuchAlgorithmException {
        MessageDigest.getInstance("SHA-256").update((byte[])null);
    }
}

If I launch with Java from a JDK it prints MessageDigest issue with named parameter "input":

Exception in thread "main" java.lang.NullPointerException: 
   Cannot read the array length because "input" is null
        at java.base/java.security.MessageDigest.update(MessageDigest.java:407)
        at stackoverflow.Main.main(Unknown Source)

If I launch with JRE produced by jlink --strip-debug it prints MessageDigest issue without specific named parameter, adding "" instead. This is because the debug symbols are missing from the JDK code:

Exception in thread "main" java.lang.NullPointerException:
  Cannot read the array length because "" is null
    at java.base/java.security.MessageDigest.update(Unknown Source)
    at stackoverflow.Main.main(Unknown Source)

If this issue occurs only in your own libraries, check the value of javac flags -g or -Djavac.debug with -Djavac.debuglevel.

If building with javac with -g or its equivalent -Djavac.debug=true -Djavac.debuglevel=lines,vars,source then the exceptions originating in your code would output extended information, whereas when compiled with -g:none or equivalent -Djavac.debug=false the less specific style of message is used.

This is actually a JVM optimization issue, not a compilation issue.When the same exception gets thrown over and over in production, the JVM starts reusing a cached version of that exception to save memory — and that cached version doesn't have a stack trace attached to it. Locally this usually doesn't happen because you're not hitting the same code path thousands of times. so even though both envs have the same Java version, it doesn't matter — this is a runtime behavior, not a compile-time thing.

Try adding this flag to your production JVM args:

-XX:-OmitStackTraceInFastThrow

That should bring back the full stack traces. Also worth double checking that your log4j/logback config is the same in both places — sometimes prod has a different appender config that truncates the output.