JDK-6178785 : Pattern.compile("xyz").matcher(null) throws NullPointerException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.regex
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-10-13
  • Updated: 2017-05-16
  • Resolved: 2006-04-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b79Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
When doing a lot of  matching using a regex, we typically create an instance of a java.util.regex.Matcher and save it as a member in the class when it is created.  In the 1.4.2 version of the jdk/jre it would allow you to use null as the parameter of java.util.regex.Pattern::matcher( String ).  In jdk/jre 1.5.0-b64 it throws a NullPointerException:

// cannot do this in jdk/jre 1.5.0-b64, but could in jdk/jre 1.4:
    private final Matcher m_mat = Pattern.compile( "xyz" ).matcher( null );

  From the error that we get it looks like this might actually be in java.util.regex.Matcher::reset( String ).


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class Junk{
    public static void main( String[] args ){
        String regex = args == null || args.length < 1 ? "xyz"    : args[ 0 ] ;
        String input = args == null || args.length < 2 ? "abcxyz" : args[ 1 ] ;
        String init  = args == null || args.length < 3 ? null     : args[ 2 ] ;
        Matcher mat = Pattern.compile( regex ).matcher( init );
        System.out.println( "    \"" + input + "\" matches \"" + regex + "\" ? " + mat.reset( input ).find() );
    }
}


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
c:> java Junk xyz abcxyz
    "abcxyz" matches "xyz" ? true

ACTUAL -
Exception in thread "main" java.lang.NullPointerException
        at java.util.regex.Matcher.getTextLength(Matcher.java:1127)
        at java.util.regex.Matcher.reset(Matcher.java:284)
        at java.util.regex.Matcher.<init>(Matcher.java:205)
        at java.util.regex.Pattern.matcher(Pattern.java:879)
        at Junk.main(Junk.java:9)

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.NullPointerException
        at java.util.regex.Matcher.getTextLength(Matcher.java:1127)
        at java.util.regex.Matcher.reset(Matcher.java:284)
        at java.util.regex.Matcher.<init>(Matcher.java:205)
        at java.util.regex.Pattern.matcher(Pattern.java:879)
        at Junk.main(Junk.java:9)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Pattern.compile( "abc" ).matcher( null );
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Must use something other than null as the parameter to java.util.regex.Pattern::matcher( String ):

Pattern.compile( "abc" ).matcher( "" );

Release Regression From : 1.4.2_05
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
###@###.### 10/13/04 21:54 GMT

Comments
EVALUATION The current API doc does not explicitly or implicitly mention whether or not a NPE will/should be thrown. But it is difficult to define a good semantics for a "null" in Matcher as a legal input text, should it be semantically equivalent to empty string ""? Obviously not. Then, what the match/find result should be expected when match null against boundary pattern like "^" and "$" (probably no match/no find for all patterns), and who will be benefited from such a semantics? The described use scenario is reasonable but should be easily achieved by use an empty string "" instead. Dont see a strong justification to "fix" the current behavior. Instead, updating the package spec to describe the NPE behavior might be a better choice.
18-04-2005