Community
Participate
Working Groups
Open class ZipFile from JRE 9, in any of its delegating ctors, select the this() call and press F3, and observe this: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding$UnNamedModule.canAccess(ModuleBinding.java:71) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:230) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:534) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:593) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:806) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:3250) at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2982) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveLeafType(ParameterizedSingleTypeReference.java:191) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveType(ParameterizedSingleTypeReference.java:165) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.resolveType(ParameterizedSingleTypeReference.java:383) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:590) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:564) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1330) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperInterfaces(ClassScope.java:1062) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1124) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectMemberTypes(ClassScope.java:930) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1132) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:363) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:570) at org.eclipse.jdt.internal.codeassist.SelectionEngine.select(SelectionEngine.java:1044) Happens, because we check access to the null package of a ProblemReferenceBinding. Type in question enters the picture as URB("Iterator"). During URB.resolve() the same type if found via java.base and <unnamed> (because java.util is split between several packages including those two). Could be fixed by letting LE.combine() recognize identical bindings and avoid ProblemReferenceBinding(Ambiguous) in that case. Before doing so, I'd, however, like to understand why we get the duplicate in the first place. It's got s.t. to do with inability to specifically request a type from the unnamed module: - LE.fromSplitPackageOrOracle() (bogusly?) passes nameForLookup() - SearchableEnvironment.findType(char[], char[][], char[]) is not able to specifically look in the unnamed module But why is <unnamed> in the declaring modules of java.util??
New Gerrit change created: https://git.eclipse.org/r/104348
Turned out the root cause is in codeSelect, where we create a BasicCompilationUnit with insufficient context. As a result, ZipFile entered the picture as belonging to the unnamed module, which told the compiler that also java.util.zip and java.util and java are present in the unnamed module, which is incorrect. Looking at usage of BasicCompilationUnit, I fixed most clients, and deprecated one (insufficient) constructor, of which we have exactly one client in CompletionEngine.parseSnippeInitializer(). So the next one working on that area will be alerted of pending cleanup, if possible. With this the initial use case is fixed. I still need to check two more levels of the problem, which could still be triggered by slightly modified setup: - is lookup of types specifically in the unnamed module possible? From SearchableEnvironment? - LE#combine() can silently ignore if the same type is mentioned more than once.
Gerrit change https://git.eclipse.org/r/104348 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ea3d3a1bd602d8d8c1f8acd5930dd39d45436e6c
New Gerrit change created: https://git.eclipse.org/r/104386
Gerrit change https://git.eclipse.org/r/104386 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5868e44fb4163075f677d883e30f1db88724fc89
(In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/104386 was merged to [BETA_JAVA9]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5868e44fb4163075f677d883e30f1db88724fc89 > Additional safety released: - when combining identical package, don't create a SplitPackageBinding - don't check access for a ProblemReferenceBinding (has no fPackage) I also added a test to assert that codeSelect can handle situations of a package split between named & unnamed module (conflicting).
*** Bug 522388 has been marked as a duplicate of this bug. ***
Installed from that update site and looks like things are working better. However... not out of the woods yet. There's still one error being logged in the error log, and it seems to abort the build somewhere in the middle (whole bunch of project don't get built because its "prerequisites" need to be built). This is the remaining NPE: eclipse.buildId=4.7.1.M20170906-1700 java.version=1.8.0_144 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_CA Command-line arguments: -data /tmp/boot-workspace -os linux -ws gtk -arch x86_64 -clean org.eclipse.jdt.core Error Mon Sep 18 11:27:27 PDT 2017 Errors running builder 'Java Builder' on project 'spring-boot'. java.lang.NullPointerException at jdk.internal.jrtfs.JrtFileSystem.getPath(JrtFileSystem.java:134) at jdk.internal.jrtfs.JrtFileSystem.getPath(JrtFileSystem.java:78) at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.hasClassFile(JRTUtil.java:263) at org.eclipse.jdt.internal.compiler.util.JRTUtil.hasCompilationUnit(JRTUtil.java:169) at org.eclipse.jdt.internal.core.builder.ClasspathJrt.hasCompilationUnit(ClasspathJrt.java:227) at org.eclipse.jdt.internal.core.builder.NameEnvironment.hasCompilationUnit(NameEnvironment.java:541) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.hasCompilationUnit(PackageBinding.java:401) at org.eclipse.jdt.internal.compiler.lookup.SplitPackageBinding.getVisibleFor(SplitPackageBinding.java:271) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:464) at org.eclipse.jdt.internal.compiler.lookup.Scope.getBinding(Scope.java:2147) at org.eclipse.jdt.internal.compiler.lookup.BlockScope.getBinding(BlockScope.java:489) at org.eclipse.jdt.internal.compiler.ast.QualifiedNameReference.resolveType(QualifiedNameReference.java:999) at org.eclipse.jdt.internal.compiler.ast.MemberValuePair.resolveTypeExpecting(MemberValuePair.java:92) at org.eclipse.jdt.internal.compiler.ast.Annotation.resolveType(Annotation.java:856) at org.eclipse.jdt.internal.compiler.ast.ASTNode.resolveAnnotations(ASTNode.java:857) at org.eclipse.jdt.internal.compiler.ast.ASTNode.resolveAnnotations(ASTNode.java:720) at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.getAnnotationTagBits(MethodBinding.java:651) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypesWithSuspendedTempErrorHandlingPolicy(SourceTypeBinding.java:1855) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypesFor(SourceTypeBinding.java:1835) at org.eclipse.jdt.internal.compiler.apt.dispatch.AnnotationDiscoveryVisitor.visit(AnnotationDiscoveryVisitor.java:168) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.traverse(MethodDeclaration.java:329) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:1478) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:1351) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.traverse(CompilationUnitDeclaration.java:782) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.traverse(CompilationUnitDeclaration.java:743) at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundEnvImpl.<init>(RoundEnvImpl.java:60) at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:148) at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:135) at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:937) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:447) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:423) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:376) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:187) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:309) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:61) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:256) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:175) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735) 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:301) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Thanks for continued testing! (In reply to Kris De Volder from comment #8) > Installed from that update site and looks like things are working better. > However... not out of the woods yet. > > There's still one error being logged in the error log, and it seems to abort > the build somewhere in the middle (whole bunch of project don't get built > because its "prerequisites" need to be built). > > This is the remaining NPE: > > eclipse.buildId=4.7.1.M20170906-1700 > java.version=1.8.0_144 > java.vendor=Oracle Corporation > BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_CA > Command-line arguments: -data /tmp/boot-workspace -os linux -ws gtk -arch > x86_64 -clean > > org.eclipse.jdt.core > Error > Mon Sep 18 11:27:27 PDT 2017 > Errors running builder 'Java Builder' on project 'spring-boot'. > > java.lang.NullPointerException > at jdk.internal.jrtfs.JrtFileSystem.getPath(JrtFileSystem.java:134) > at jdk.internal.jrtfs.JrtFileSystem.getPath(JrtFileSystem.java:78) > at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.hasClassFile(JRTUtil.java:263) > at org.eclipse.jdt.internal.compiler.util.JRTUtil.hasCompilationUnit(JRTUtil.java:169) > at org.eclipse.jdt.internal.core.builder.ClasspathJrt.hasCompilationUnit(ClasspathJrt.java:227) > at org.eclipse.jdt.internal.core.builder.NameEnvironment.hasCompilationUnit(NameEnvironment.java:541) > at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.hasCompilationUnit(PackageBinding.java:401) > at org.eclipse.jdt.internal.compiler.lookup.SplitPackageBinding.getVisibleFor(SplitPackageBinding.java:271) This strongly reminds me of bug 522398, which Till fixed just the other day. Re-closing, not as duplicate because we already have a real fix here, too.
Cool. I can test again, if there's a update site with that fix. Let me know.
