Community
Participate
Working Groups
Upgraded Eclipse (eclipse.buildId=4.3.2.M20140221-1700) to: - AspectJ Development Tools 2.2.4.e43x-20140320-1000 - AspectJ Compiler 1.8.0.20140320104000 and started getting compile error messages with the following stacktrace: java.lang.NullPointerException at org.aspectj.org.eclipse.jdt.internal.compiler.ast.NullAnnotationMatching.analyse(NullAnnotationMatching.java:142) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.NullAnnotationMatching.analyse(NullAnnotationMatching.java:112) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.Statement.internalCheckAgainstNullTypeAnnotation(Statement.java:190) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.Statement.checkAgainstNullTypeAnnotation(Statement.java:186) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.ReturnStatement.checkAgainstNullAnnotation(ReturnStatement.java:186) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.ReturnStatement.analyseCode(ReturnStatement.java:85) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:48) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.TryStatement.analyseCode(TryStatement.java:165) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.analyseCode(MethodDeclaration.java:124) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:766) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:262) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:118) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:793) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:471) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1031) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:272) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:185) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:105) at org.aspectj.ajde.core.AjCompiler.buildFresh(AjCompiler.java:100) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:255) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) This is reproducible when I run Project->Clean on my AspectJ project. The -source and -target I also have the following Java 8 patch plugin installed: - Eclipse JDT (Java Development Tools) Patch with Java 8 support (for Kepler SR2) 1.0.0.v20140317-1956 The following settings are in org.eclipse.jdt.core.prefs the my AspectJ project: org.eclipse.jdt.core.compiler.compliance=1.8 org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve org.eclipse.jdt.core.compiler.debug.sourceFile=generate org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.8 org.eclipse.jdt.core.compiler.problem.enumIdentifier=error org.eclipse.jdt.core.compiler.debug.lineNumber=generate eclipse.preferences.version=1 org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.source=1.8
I think the return type for a method binding is null. What would be interesting is whether this occurs with vanilla Java8 and no AspectJ in the picture. Are the aspects tightly coupled to the code or can you comment them out temporarily and try a compile of the project using Java8 (you will have to remove the AspectJ nature, since that causes AspectJ to take over from the installed java8 patch you have in the mix). This is the code I'm wondering about: void checkAgainstNullAnnotation(BlockScope scope, FlowContext flowContext, FlowInfo flowInfo) { int nullStatus = this.expression.nullStatus(flowInfo, flowContext); long tagBits; MethodBinding methodBinding = null; boolean useTypeAnnotations = scope.compilerOptions().sourceLevel >= ClassFileConstants.JDK1_8; try { methodBinding = scope.methodScope().referenceMethodBinding(); tagBits = (useTypeAnnotations) ? methodBinding.returnType.tagBits : methodBinding.tagBits; } catch (NullPointerException npe) { // chain of references in try-block has several potential nulls; // any null means we cannot perform the following check return; } if (useTypeAnnotations) { checkAgainstNullTypeAnnotation(scope, methodBinding.returnType, this.expression, flowContext, flowInfo); } else if (nullStatus != FlowInfo.NON_NULL) { // if we can't prove non-null check against declared null-ness of the enclosing method: if ((tagBits & TagBits.AnnotationNonNull) != 0) { flowContext.recordNullityMismatch(scope, this.expression, this.expression.resolvedType, methodBinding.returnType, nullStatus); } } } There is a NPE catch which mentions 'several potential nulls' but further down it accesses 'methodBinding.returnType' again (outside of the trycatch) - is that one of the potential nulls that should be guarded?
Andy, yes the aspects are decoupled enough to compile the project without them. All of the code in this project compiles fine in both Eclipse and with Oracle JDK with source and binary compatibility set to 1.8. Let me know if there is anything else I can do to help debug this issue.
Well the quickest way for me to fix it is to reproduce it - any way you can share the project? (doesn't have to be publicly on bugzilla, could be privately). I could guard it but I'd rather get to the root of the issue. Do you have ITDs or just pointcuts and advice? I might be able to create a debug build if I can't reproduce it here.
Created attachment 241600 [details] aspectj plugin to reproduce the bug I have the same problem. AJDT shows an "Aspectj Internal Compiler Error" Dialog box with the following details. With the attachment org.aspectj.bug431541.zip you should be able to reproduce the bug java.lang.NullPointerException at org.aspectj.org.eclipse.jdt.internal.compiler.ast.NullAnnotationMatching.analyse(NullAnnotationMatching.java:142) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.NullAnnotationMatching.analyse(NullAnnotationMatching.java:112) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.NullAnnotationMatching.checkAssignment(NullAnnotationMatching.java:85) at org.aspectj.org.eclipse.jdt.internal.compiler.ast ... oBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) Compile error: NullPointerException thrown: null
Thanks for the test case! I distilled it down to this: public aspect WorkbenchStateAspect2 { Object around(String theType): call(public Object getChild(String)) && args(theType) { return proceed(theType); } } which fails with the same exception.
Fixed (at least I've fixed the variant I could reproduce). The problem was the Proceed expression was not setting the resolvedType and the new Java8 compiler we are based on is relying on it. Should be in an AJDT a couple of days.
Thanks Andy. Glad someone was able to provide a test case as I could not give out my source code. My aspect contains several "around()" advice with "return proceed()" calls that look similar to the distilled test case.
