This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 187004

Summary: [69cat] NullPointerException: The project parameter cannot be null
Product: java Reporter: javydreamercsw <javydreamercsw>
Component: JUnitAssignee: Theofanis Oikonomou <theofanis>
Severity: normal CC: jglick, lolo_101, michbarsinai, mmirilovic
Priority: P2    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 170317
Bug Depends on: 159570    
Bug Blocks: 204486    
Attachments: stacktrace

Description javydreamercsw 2010-05-31 18:37:56 UTC
Build: NetBeans IDE Dev (Build 201005290001)
VM: Java HotSpot(TM) Client VM, 16.3-b01, Java(TM) SE Runtime Environment, 1.6.0_20-b02
OS: Windows Vista

User Comments:
javydreamercsw: Trying to run a test file after a project clean. (shift+F6 while on the file)

java.lang.NullPointerException: The project parameter cannot be null
   at org.openide.util.Parameters.notNull(
   at org.netbeans.modules.gsf.testrunner.api.TestSession.<init>(
   at org.netbeans.modules.junit.output.JUnitTestSession.<init>(
   at org.netbeans.modules.junit.output.JUnitOutputReader.<init>(
   at org.netbeans.modules.junit.output.JUnitAntLogger.getOutputReader(
   at org.netbeans.modules.junit.output.JUnitAntLogger.buildFinished(
Comment 1 javydreamercsw 2010-05-31 18:37:59 UTC
Created attachment 99685 [details]
Comment 2 Jesse Glick 2010-06-11 16:36:42 UTC
Created attachment 100027 [details]
Comment 3 Victor Vasilyev 2010-09-17 11:44:53 UTC
An assert statement is added to have more info about this bug:
Comment 4 Jesse Glick 2011-01-04 20:20:11 UTC
I recently encountered:

java.lang.AssertionError: See bug 187004:  project must not be null for projectDir="/tmp"
        at org.netbeans.modules.junit.output.JUnitAntLogger.getOutputReader(
        at org.netbeans.modules.junit.output.JUnitAntLogger.taskStarted(

I don't know how to reproduce. Perhaps /tmp/pom.xml existed at some point and was later deleted. Anyway the code in junit should be more robust.
Comment 5 tkellerer 2011-02-21 21:32:11 UTC
Created attachment 106268 [details]

I'm adding the stacktrace here, as the exception reporter in the current dev-builds does not seem to work.
Comment 6 Exceptions Reporter 2011-04-16 22:30:59 UTC
This bug already has 5 duplicates 
Comment 7 Exceptions Reporter 2011-04-16 22:33:58 UTC
Created attachment 107793 [details]
Comment 8 Antonin Nebuzelsky 2011-06-14 12:38:17 UTC
*** Bug 197606 has been marked as a duplicate of this bug. ***
Comment 9 Jesse Glick 2011-10-05 19:58:58 UTC
Reproducibly prevents "Profile Test for File" from working on from opened as an automatic project. (Test File and Debug Test File work.)
Comment 10 Theofanis Oikonomou 2011-11-11 11:39:54 UTC
This seems to happen whenever JUnitAntLogger.getOutputReader() is called. 

JUnitAntLogger.getOutputReader() tries to get the project by calling FileOwnerQuery.getOwner() and then calls JUnitOutputReader()

JUnitOutputReader() tries to get the project again by calling FileOwnerQuery.getOwner() and then calls JUnitTestSession(), which used to raise the NPE before the assert statement from comment 3 was added

In both cases the project returned by FileOwnerQuery.getOwner() is null. I do not know why this happens.

One solution would be to just consume the AntEvent in JUnitAntLogger that triggered the call to JUnitAntLogger.getOutputReader() when the project that is returned by FileOwnerQuery.getOwner() is null. 

Jesse any thoughts on that?
Comment 11 Jesse Glick 2011-11-14 17:40:46 UTC
I think the problem is the reliance on event.getProperty("basedir"). There is no clear reason why this code is there; the basedir need have nothing to do with the test being run. Nor does event.getProperty("work.dir") make much sense. I would delete both of these. But then, I do not really see that the project parameter is being used for at all. All of this code mishandles nulls all over the place, and makes all kinds of unfounded and undocumented assumptions; it needs to be rewritten, but in the meantime this NPE is critical. I am trying out some patches which I will attach for your review.
Comment 12 Jesse Glick 2011-11-14 18:41:29 UTC
Still reproducible via comment #9, unless run from ant tryme and cachedir is nbbuild/testuserdir/var/cache - in which case nbbuild is considered the "owner" of the test, because of junit-snippet.xml used for CoS test runs, which is of course nonsense. (For whatever reason, work.dir is set by Test File and Debug Test File, but not by Profile Test File, hence the bug setup.)

The org.netbeans.modules.junit.output code I see is wrong from start to finish. propsOfInterest, work.dir, basedir - these are all properties which may or may not be set to unspecified values, according to the script which ran JUnit; the logger should not be paying attention to _any_ of this because it cannot know what it means. originatingScript is also meaningless in JUnitOutputReader: who cares which script started the build? That script might have called a different script which called a third script which ran JUnit.

All this code must be rewritten to use AntEvent.taskStructure to inspect the actual call to <junit> (or <java>) which is triggering display of the result window. Use <test>, <batchtest>, <classpath>, etc. to figure out what tests are actually being run and where they are located (in binaries; use SourceForBinaryQuery to find matching sources). That also means getOutputReader may only be called inside taskStarted or taskFinished methods, or messageLogged nested inside one of these. buildFinished, if still needed, must do something different (e.g. use a custom logger state object to keep track of a set of JUnit runs encountered during the current build).

Some other mistakes: FileUtil.toFileObject(antScript) is called without checking for a null return value. TestSession should not need to be passed a Project parameter (see blocking issue). ProjectFileLocator may not look for "" in a project's evaluator since this is only sensible for certain project types; should simply inspect ClassPath.BOOT for the tests actually being processed, if it needs to know this information at all. Nor should it be calling ProjectUtils.getSources(p) (which BTW can never return null so do not check for it!), since it is irrelevant what source roots some nearby project might have - what you care about is a single binary classpath, what is being run right now.
Comment 13 Jesse Glick 2011-11-14 18:45:27 UTC
core-main #68eef6939041
Comment 14 Jesse Glick 2011-11-14 18:46:54 UTC
*** Bug 191217 has been marked as a duplicate of this bug. ***
Comment 15 Quality Engineering 2011-11-16 15:49:32 UTC
Integrated into 'main-golden'
User: Jesse Glick <>
Log: #187004: [69cat] NullPointerException: The project parameter cannot be null
Hot fix; real bug runs deeper.