JDK-8264745 : Unify ParseLong Methods to Throw NPE
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 17
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2021-04-02
  • Updated: 2021-04-06
  • Resolved: 2021-04-06
Related Reports
Relates :  
Relates :  
Relates :  
Description
A DESCRIPTION OF THE PROBLEM :
For the Long class, in one instance of the parseLong method, a NumberFormatException is thrown for a null input value, but in another instance, a NullPointerException is thrown.

https://github.com/openjdk/jdk/blob/d0f3cc92bc97aa517d622ac57d22f820fba0684b/src/java.base/share/classes/java/lang/Long.java#L684-L686

https://github.com/openjdk/jdk/blob/d0f3cc92bc97aa517d622ac57d22f820fba0684b/src/java.base/share/classes/java/lang/Long.java#L765

Please unify these methods so that they both throw NPE on a null input value.  With JDK-8261290, the message  for NumberFormatException was improved to be more clear that this is a null value, not a string of "null" characters (thanks), but the NPE would be preferable here.

Please consider unifying all of the Number classes.  For example:

https://github.com/openjdk/jdk/blob/d0f3cc92bc97aa517d622ac57d22f820fba0684b/src/java.base/share/classes/java/lang/Integer.java#L630



Comments
The behavior of parseLong throwing a NumberFormatException on null rather than NullPointerException has been around for decades (JDK-4787924). While it is not how a method with that functionality would be written today, it is not worth the behavioral compatibility impact on existing clients to change it now. Closing as will not fix.
06-04-2021

Move to JDK to discuss the necessities of the enhancement.
06-04-2021