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.
I got NullPointerException when removing two folders from Java Sources component, but I cannot reproduce it. Exc is attached.
Created attachment 6467 [details] exc stack trace
Target Milestone -> 4.0
Happened to me also when adding existing folders to Java Sources component. Exceptions are attached.
Created attachment 6728 [details] exc stack trace
I suspec this is the same root cause as 25350. Removing the folder does not happen immediately, and after the removal the AWT event thread decides to refresh the UI, so it eventually calls getDisplayName. But getDisplayName eventually calls Project.find(obj) - which eventually returns null (because the object has been removed from the project). However, from a cursory look at CPRootLook.java it seems the code assumes Project.find() will never return null.
Well, there's another way to reproduce this problem too (actually, it may not be the same problem, but it has nearly identical stacktrace). I simply opened two projects which have a "conflict" in the sense that the same source directory is used in both projects. Simply drilling down and attempting to open the "Java Sources" node causes the exception to be thrown. It should also be noted that you get the CLASH!!! warning which is printed by Project.java before it returns null for Project.find. Thus, the end result is the same (null in getDisplayName which is then dereferenced) yet the cause here is different; we're not removing anything. The solution is for CPRootLook to check the result of Project.find. --- CPRootLook.java 26 Jun 2002 19:11:49 -0000 1.1.2.3 +++ CPRootLook.java 16 Jul 2002 14:51:49 -0000 @@ -66,7 +66,11 @@ name = e.getMessage (); } } else { - DataObject homes [] = Project.find (root.getFolder ()).getBaseDirs ().getChildren (); + Project p = Project.find (root.getFolder ()); + if (p == null) { + return ""; // Fixes exception, but what to use instead??? + } + DataObject homes [] = p.getBaseDirs ().getChildren (); for (int i = 0; i < homes.length; i++) {
By the way, let me point out that I didn't intend to imply that the above was a complete fix; we (projects) need to finish our dataobject->project data object lookup such that we compute the right project context to be used by Project.find() since it shouldn't return null in the case it currently is. CPRootLook still needs to check for null in the case of deferred removal of nodes, but for the case where a project is included in multiple projects, Project.find should not return null, it should return a project (and preferably the RIGHT project. Since this is from a look which has an associated node, we can probably find the correct project.)
I've changed it such that Project.find() returns the first found project rather than null when there are multiple eligible projects. Transferring to the java module for the rest of the work to get done.
It seems to be fixed. I cannot reproduce it.
Verified.
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. Marking issue as CLOSED.