Comment 1 Michael Rennie 2009-03-30 09:25:43 EDT

looks like something is happening when JUnit4TestFinder is trying to resolve a compilation unit, sending to JDT for comment.

Comment 2 Dani Megert 2009-03-30 09:29:47 EDT

Do you have steps to reproduce?

Comment 3 Pavel Sklenak 2009-03-30 09:49:36 EDT

(In reply to comment #2)
> Do you have steps to reproduce?
> 


After restart of eclipse it is not reproducible. I was able to reproduce it by
clicking to package explorer then activating editor and shift mouse over one of
run/debug/external tools toolbar items. I have 5 eclipse applications and one
java application in my run history.

Actually I got it again ... I activated eclipse window (cursor was in editor)
and shifted mouse over button. Anyway it is happening only first time after
activating editor. (I can't get this error again without re-activating editor)

I had activated "Launch the selected resource or active editor". Active editor
was plain java file.

Seems it is not easy reproducible. I hope my description will help.

Comment 4 Markus Keller 2009-03-30 12:39:44 EDT

The labels of these buttons are calculated depending on the *.java file in the active editor. It would be helpful if you could attach the file you have open in the editor when this happens.

If you can't attach the whole file, please try to remove all members of the type except for constructor declarations. If you can reproduce then, please attach just the stripped-down file with only the constructors.

Comment 5 Pavel Sklenak 2009-03-31 05:28:00 EDT

(In reply to comment #4)
> The labels of these buttons are calculated depending on the *.java file in the
> active editor. It would be helpful if you could attach the file you have open
> in the editor when this happens.
> 
> If you can't attach the whole file, please try to remove all members of the
> type except for constructor declarations. If you can reproduce then, please
> attach just the stripped-down file with only the constructors.
> 

I am sorry I can't share file but I created snippet where this bug works too.

public class CSVImporter2 extends AbstractImporter2 {

	public CSVImporter2(String param1, String param2) {
		super(param1, param2);
	}
	
	
	private class ImportData {

		public ImportData(String fileName) {
		}
	}


}

class AbstractImporter2 {
	public AbstractImporter2(String param1, String param2) {
		// TODO Auto-generated constructor stub
	}
}

I tried to debug it and I found there are two jars with same classes (jasper and jdt.core). Debug steps into jdt.core.

		// https://bugs.eclipse.org/bugs/show_bug.cgi?id=264991, Don't complain about this
		// constructor being unused if the base class doesn't have a no-arg constructor.
		// See that a seemingly unused constructor that chains to another constructor with a
		// this(...) can be flagged as being unused without hesitation.
		// https://bugs.eclipse.org/bugs/show_bug.cgi?id=265142
		if (this.constructorCall.accessMode != ExplicitConstructorCall.This) {

Note: this.constructorCall == null (constructorCall is public field so I can't debug it easily) I can't reproduce it in 3.5M5 so I suppose it has something to do with above mentioned bugs.

Comment 6 Srikanth Sankaran 2009-03-31 05:35:20 EDT

(In reply to comment #5)
> (In reply to comment #4)

[...]

> I am sorry I can't share file but I created snippet where this bug works too.
> public class CSVImporter2 extends AbstractImporter2 {
>         public CSVImporter2(String param1, String param2) {
>                 super(param1, param2);
>         }
>         private class ImportData {
>                 public ImportData(String fileName) {
>                 }
>         }
> }
> class AbstractImporter2 {
>         public AbstractImporter2(String param1, String param2) {
>                 // TODO Auto-generated constructor stub
>         }
> }

[...]

> Note: this.constructorCall == null (constructorCall is public field so I can't
> debug it easily) I can't reproduce it in 3.5M5 so I suppose it has something to
> do with above mentioned bugs.

I believe it is. I could reproduce an NPE in the same leading call stack
by writing a program that builds an abridged call stack:

---------------------------
	ICompilationUnit workingCopy =
		getWorkingCopy(
				"/Converter/src/X.java",
				"public class X {\n" +
				"	  private class B {\n" +
				"	    public B() {\n" +
				"	    }\n" +
				"	  }\n" +
				"	  public X() {\n" +
				"	  }\n" +
				"	}\n"
			);
			
			// Create parser
			ASTParser parser = ASTParser.newParser(AST.JLS3);
			parser.setSource(workingCopy);
			parser.setFocalPosition(0);
			parser.setResolveBindings(true);

			ASTNode result = parser.createAST(null);

-----------------------------------------------------------------
java.lang.NullPointerException

	at org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration.analyseCode(ConstructorDeclaration.java:70)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:684)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:218)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:666)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:253)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:111)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:868)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:518)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:908)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:657)
-------------------------

Patch will follow shortly.

Comment 7 Srikanth Sankaran 2009-03-31 05:42:27 EDT

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> [...]

> I believe it is. I could reproduce an NPE in the same leading call stack
> by writing a program that builds an abridged call stack:

Sorry. I meant to say abridged AST. 

Could the JUnit4TestFinder call of createAST be building
an abridged version of AST (via ASTParser#setFocalPosition(0)) ? 

Comment 8 Markus Keller 2009-03-31 06:08:35 EDT

> Could the JUnit4TestFinder call of createAST be building
> an abridged version of AST (via ASTParser#setFocalPosition(0)) ? 

Yes, it's:
	parser.setFocalPosition(0);
	parser.setResolveBindings(true);
	CompilationUnit root= (CompilationUnit) parser.createAST(monitor);

Comment 9 Srikanth Sankaran 2009-03-31 08:00:07 EDT

Created attachment 130380 [details]
Proposed patch + tests

(In reply to comment #8)
> > Could the JUnit4TestFinder call of createAST be building
> > an abridged version of AST (via ASTParser#setFocalPosition(0)) ? 
> Yes, it's:
>         parser.setFocalPosition(0);
>         parser.setResolveBindings(true);
>         CompilationUnit root= (CompilationUnit) parser.createAST(monitor);

Thanks for confirming, the problem was that the abridged AST was missing
in some of the nodes that would have normally been present and the
(recently added) code in ConstructorDeclaration was not prepared to
handle this case.

Comment 10 Chris West (Faux) 2009-03-31 17:10:07 EDT

For anyone who's caught on this (it won't run the tests at all when this is present), it can be fixed by changing all inner classes in the file (including static ones) from private to default access.

Comment 11 Srikanth Sankaran 2009-04-01 01:41:21 EDT

Released in HEAD for 3.5 M7

Comment 12 Olivier Thomann 2009-04-01 12:04:12 EDT

*** Bug 270799 has been marked as a duplicate of this bug. ***

Comment 13 David Audel 2009-04-27 09:40:09 EDT

Verified for 3.5M7 using I20090426-2000