Community
Participate
Working Groups
(In reply to Sam Peters from bug 543765 comment #24) > @Stephan: Here is the new example, showing the false-positive error marker > in Example.java source at import declaration saying "The type > com.example.sub.b.B is not accessable." In contrast, neither in the > "Problems" tab nor in the "Package Explorer" the errors are shown, and the > code runs without errors. > > The new example contains three java-modular maven projects: testmain depends > on both testa and testb, and testa depends on testb: > > ================== > Project "testmain" > ================== > > Example.java: > ---------------- > package com.example; > import com.example.sub.a.A; > import com.example.sub.b.B; > > public class Example { > public static void main(String[] args) { > A.main(null); > B.main(null); > } > } > > module-info.java > ---------------- > open module com.example { > requires com.example.sub.a; > requires com.example.sub.b; > } > > pom.xml: > ---------------- > <project xmlns="http://maven.apache.org/POM/4.0.0" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > <modelVersion>4.0.0</modelVersion> > <groupId>com.example</groupId> > <artifactId>test-main</artifactId> > <version>0.0.1-SNAPSHOT</version> > <packaging>jar</packaging> > <dependencies> > <dependency> > <groupId>com.example</groupId> > <artifactId>testa</artifactId> > <version>0.0.1-SNAPSHOT</version> > </dependency> > <dependency> > <groupId>com.example</groupId> > <artifactId>testb</artifactId> > <version>0.0.1-SNAPSHOT</version> > </dependency> > </dependencies> > > > ================== > Project "testa" > ================== > > A.java: > ---------------- > package com.example.sub.a; > public class A { > public static void main(String[] args) { > System.out.println("A"); > } > } > > module-info.java: > ---------------- > open module com.example.sub.a { > exports com.example.sub.a; > requires com.example.sub.b; > } > > pom.xml: > ---------------- > <project xmlns="http://maven.apache.org/POM/4.0.0" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > <modelVersion>4.0.0</modelVersion> > <groupId>com.example</groupId> > <artifactId>testa</artifactId> > <version>0.0.1-SNAPSHOT</version> > <dependencies> > <dependency> > <groupId>com.example</groupId> > <artifactId>testb</artifactId> > <version>0.0.1-SNAPSHOT</version> > </dependency> > </dependencies> > > ================== > Project "testb" > ================== > > B.java: > ---------------- > package com.example.sub.b; > public class B { > public static void main(String[] args) { > System.out.println("B"); > } > } > > module-info.java: > ---------------- > open module com.example.sub.b { > exports com.example.sub.b; > } > > pom.xml: > ---------------- > <project xmlns="http://maven.apache.org/POM/4.0.0" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > <modelVersion>4.0.0</modelVersion> > <groupId>com.example</groupId> > <artifactId>testb</artifactId> > <version>0.0.1-SNAPSHOT</version> > > ...and, of course, in all three pom.xml's we need > > <build> > <plugins> > <plugin> > <artifactId>maven-compiler-plugin</artifactId> > <version>3.8.0</version> > <configuration> > <release>11</release> > </configuration> > </plugin> > </plugins> > </build> > > > Please evaluate this error too since it does hinder programming due to its > error messages. Thank you very much!!!
Created attachment 277400 [details] ready-to-test repro projects I can reproduce, attaching a complete maven-less set of projects for easier testing (note that JDT tests cannot use maven / m2e). It's good to have a test the demonstrates the difference between builder (works) and reconciler/editor (bug), but I don't see this as a show stopper for development. I'll tentatively put this on target 4.11, but no promise implied.
@Stefan, thank you very much for your fast feedback! > It's good to have a test the demonstrates the difference between builder > (works) and reconciler/editor (bug), but I don't see this as a show stopper > for development. Sorry to say that but besides displaying false-positive errors today I got permanently errors in Eclipse (NPE) as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=543441#c5 https://bugs.eclipse.org/bugs/show_bug.cgi?id=543765#c22 The error below is raised - when I hover over a variable that is contained in a class of a module *equivalent to* testb -> "Unexpected runtime error while computing a text hover in org.eclipse.jface.text" -> nothing happens - when I press the Ctrl key (auto-completion) -> "Unhandled event loop exception in org.eclipse.ui" -> nothing happens - when I try to open the sub-context menu for "Run As..." -> "Unhandled event loop exception in org.eclipse.ui" -> Context menu for "Run As..." won't show up(!) So, for me, this bug described here seems to cause not only a false display but also a misbehaviour on some of the most important IDE functions as listed above, making it impossible to work with alot of classes of our project. Thus, I wish you could give it a high priority. (I'll also try to give you a full code example showing this behaviour, but maybe you already see a problem from the attached full stack trace: eclipse.buildId=4.11.0.I20190131-0130 java.version=11.0.1 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.lambda$8(ModuleBinding.java:396) at java.base/java.util.stream.ReduceOps$4ReducingSink.accept(ReduceOps.java:220) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:589) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.lambda$6(ModuleBinding.java:393) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getAllRequiredModules(ModuleBinding.java:414) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.otherRelevantModules(ModuleBinding.java:724) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.combineWithPackagesFromOtherRelevantModules(ModuleBinding.java:700) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getVisiblePackage(ModuleBinding.java:591) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getTopLevelPackage(ModuleBinding.java:505) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getVisiblePackage(ModuleBinding.java:626) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.combineWithPackagesFromOtherRelevantModules(ModuleBinding.java:704) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getVisiblePackage(ModuleBinding.java:591) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getTopLevelPackage(ModuleBinding.java:505) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getVisiblePackage(ModuleBinding.java:626) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.combineWithPackagesFromOtherRelevantModules(ModuleBinding.java:704) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getVisiblePackage(ModuleBinding.java:591) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getTopLevelPackage(ModuleBinding.java:505) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getVisiblePackage(ModuleBinding.java:626) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getVisiblePackage(ModuleBinding.java:619) at org.eclipse.jdt.internal.compiler.ast.PackageVisibilityStatement.resolvePackageReference(PackageVisibilityStatement.java:69) at org.eclipse.jdt.internal.compiler.ast.PackageVisibilityStatement.resolve(PackageVisibilityStatement.java:45) at org.eclipse.jdt.internal.compiler.ast.ModuleDeclaration.resolvePackageDirectives(ModuleDeclaration.java:200) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:216) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:573) at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:88) at org.eclipse.jdt.internal.compiler.impl.ITypeRequestor.accept(ITypeRequestor.java:63) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModule(LookupEnvironment.java:209) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModule(LookupEnvironment.java:201) at org.eclipse.jdt.internal.compiler.lookup.BinaryModuleBinding.cachePartsFrom(BinaryModuleBinding.java:103) at org.eclipse.jdt.internal.compiler.lookup.BinaryModuleBinding.<init>(BinaryModuleBinding.java:89) at org.eclipse.jdt.internal.compiler.lookup.BinaryModuleBinding.create(BinaryModuleBinding.java:83) at org.eclipse.jdt.internal.compiler.impl.ITypeRequestor.accept(ITypeRequestor.java:70) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModule(LookupEnvironment.java:209) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModule(LookupEnvironment.java:201) at org.eclipse.jdt.internal.compiler.ast.ModuleReference.resolve(ModuleReference.java:47) at org.eclipse.jdt.internal.compiler.ast.RequiresStatement.resolve(RequiresStatement.java:51) at org.eclipse.jdt.internal.compiler.ast.ModuleDeclaration.resolveModuleDirectives(ModuleDeclaration.java:169) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:215) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:573) at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:88) at org.eclipse.jdt.internal.compiler.impl.ITypeRequestor.accept(ITypeRequestor.java:63) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModule(LookupEnvironment.java:209) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModule(LookupEnvironment.java:201) at org.eclipse.jdt.internal.compiler.ast.ModuleReference.resolve(ModuleReference.java:47) at org.eclipse.jdt.internal.compiler.ast.RequiresStatement.resolve(RequiresStatement.java:51) at org.eclipse.jdt.internal.compiler.ast.ModuleDeclaration.resolveModuleDirectives(ModuleDeclaration.java:169) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:215) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:573) at org.eclipse.jdt.internal.codeassist.impl.Engine.accept(Engine.java:88) at org.eclipse.jdt.internal.compiler.impl.ITypeRequestor.accept(ITypeRequestor.java:63) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModule(LookupEnvironment.java:209) at org.eclipse.jdt.internal.compiler.env.ICompilationUnit.module(ICompilationUnit.java:64) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.module(CompilationUnitDeclaration.java:833) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:461) at org.eclipse.jdt.internal.codeassist.SelectionEngine.select(SelectionEngine.java:1060) at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:168) at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect(CompilationUnit.java:390) at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect(CompilationUnit.java:383) at org.eclipse.jdt.internal.ui.javaeditor.JavaElementHyperlinkDetector.detectHyperlinks(JavaElementHyperlinkDetector.java:115) at org.eclipse.ui.texteditor.HyperlinkDetectorRegistry$HyperlinkDetectorDelegate.detectHyperlinks(HyperlinkDetectorRegistry.java:81) at org.eclipse.jface.text.hyperlink.HyperlinkManager.findHyperlinks(HyperlinkManager.java:289) at org.eclipse.jface.text.hyperlink.HyperlinkManager.findHyperlinks(HyperlinkManager.java:262) at org.eclipse.jface.text.hyperlink.HyperlinkManager.mouseMove(HyperlinkManager.java:457) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:216) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4131) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1055) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3944) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3547) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1173) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1062) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:636) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:563) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:151) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:155) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:595) at org.eclipse.equinox.launcher.Main.run(Main.java:1501)
Ok, here are the steps to reproduce the exception described in my last post. It seems to be related to mixing opened and closed projects in the workspace at the same time (which was, so far, not a problem): 1. open Eclipse workspace with the maven projects defined above (testmain, testa, testb) 2. ensure that all three projects are opened 2. do "mvn install testb" 3. do "mvn install testa" 4. close project testa 5. define a non-modular module "automodule" (representing one of some non-modular central maven artifacts): ==================== Project "automodule" ==================== AutoModule.java: ---------------- package com.example.automodule; public class AutoModule { public static void main(String[] args) { System.out.println("AutoModule"); } } pom.xml: ---------------- <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>automodule</artifactId> <version>0.0.1-SNAPSNOT</version> <build> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.0</version> <configuration> <release>11</release> </configuration> </plugin> </plugins> </build> </project> 5a. do "mvn install automodule" 5b. close project automodule 6. add automodule dependency in pom.xml of project testb: ... <dependency> <groupId>com.example</groupId> <artifactId>automodule</artifactId> <version>0.0.1-SNAPSNOT</version> </dependency> ... 7. go into source file Example.java and try to run the class, or hover over class "B" in import com.example.sub.b.B -> you shold see the exception of my last post in the "Error tab" 8. opening project testa -> no exception occurs 9. closing project testa again and/or removing/adding the dependency declaration in pom.xml -> exception occurs again Another effect we see in our real project is that workspace building won't stop: It builds again and again those classes with false-positive reported imports, causing the whole(!) source file(s) to flicker forever(!) All in all, without removing this bug and the cause for the exception I described (-> maybe a new bug should be created for it?) it is currently *quite* uncomfortable to work with Eclipse and I don't see any good workaround. I wish that one of the Eclipse developers can take the time to solve these bugs (having "critical" priority for us) soon. Thank you guys in advance :)
Please note that the never-ending workspace building and flickering occurs also if all relevant projects are open in the Eclipse workspace. So, open all projects is also not an option/workaround.
While organizing imports and/or opening and closing projects in workspace I also got repeatedly this stack trace at different places... Error in JDT Core during reconcile: Java Model Exception: java.lang.NullPointerException at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:324) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:346) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:193) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:103) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:736) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:802) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1322) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1281) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:138) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:113) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:93) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:90) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:157) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:92) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:107) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:76) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:210) Caused by: java.lang.NullPointerException Caused by: java.lang.NullPointerException
Analyzing the original bug further, I just recognized the following interesting behavior: If I replace requires com.example.sub.a; requires com.example.sub.b; with requires com.example.sub.b; requires com.example.sub.a; in testmain's module.info, no errors are shown anymore in Example.java. (I doubt if just changing the ordering of the requires directives in all relevant module-info could fix all problems in real-world projects ;-) My feeling is that the bug is perfectly described now and the explaination given in this bug report seems to match also the explaination gave by Stephan Herrmann: "For performance sake, each result of such lookup is cached, which caused the order dependence: which module first looked up package com.example decided what contributions to the package were known.", see https://stackoverflow.com/questions/54329075/jdk11-migration-compilation-error-shown-in-eclipse-2018-12-but-code-runs-fine. I *hope* that based on this knowledge the bogus error messages can be fixed soon and easily. (The other bugs described in Comment #2 and Comment #5 occur only occasionally or can be worked around. I'd like to separate them from the original bogus one and file two new reports if you agree, Stephan?)
Created attachment 277430 [details] maven projects (In reply to Sam Peters from comment #3) > Ok, here are the steps to reproduce the exception described in my last post. > It seems to be related to mixing opened and closed projects in the workspace > at the same time (which was, so far, not a problem): > > 1. open Eclipse workspace with the maven projects defined above (testmain, > testa, testb) Sorry, but the "above projects" are intentionally created *without* maven. So I went back to bug 543765 comment 24 tried to retrofit my projects into maven projects according to your instructions, then followed the instructions here in comment 3, to see: it all works flawlessly. So, please import the projects from the attachment and adjust them, so that the bug occurs.
Forgot to say: instructions on how to create those projects are just too fragile, please attach an archive with all projects involved.
@Stephan: Concerning the NPE issue: I downloaded and imported your attached "maven project" attachment (bug544017-mvn.zip), imported them as "Existing Maven Project(s)" into a clean workspace, installed the dependencies "automodule", "testb" and "testa", closed "automodule" and "testa" and - voila - hovering over "import com.example.sub.a.A;" in Example.java or trying to run that class results in *exactly* those errors described in Comment #2. I wonder that you are not getting these error. A short note of the test environment: I used eclipse-SDK-I20190131-0130-win32-x86_64.zip and did a "Install new Software... https://dl.bintray.com/subclipse/releases/subclipse/latest" (I wonder why no "Eclipse marketplace" wasn't visible but that's possibly another story?). Could it be a plugin problem? Nevertheless, the "com.example.sub.b.B" problem is a different one than the NPE issue. How can I support further for resolving both issues?
Created attachment 277449 [details] diffs between maven projects (In reply to Sam Peters from comment #9) Using "Import > Existing Maven Projects" produces significant changes in the project's configuration, which I'm attaching here. That's exactly why sharing exact projects with all configuration files is so important. In addition to the steps mentioned in comment 9 I had to invoke Maven > Update Project on test-main to fix a problem with dependency on *project* testa. As I now see the NPE, the configuration differences seem to be significant. You may want to double check by importing the projects as "General > Existing Projects into Workspace", which even lets you import directly from the zip archive ;p
> As I now see the NPE, the configuration differences seem to be significant. Good to know, thanks. > You may want to double check by importing the projects as > "General > Existing Projects into Workspace" Confirmed, thanks for the hint. Importing your .zip via Import > Existing Projects from Workspace, install automodule, testb and testa and close automodule and testa, I had also do a Maven > Update Project on testmain to see the NPE. Summarized, we have two errors: 1) com.example.sub.b.B is not accessable (confirmed by you in Comment #1) and 2) the NPE (confirmed by you in Comment #10), right?
NPE happens due to the following re-entrance: - module com.example -- during LE.completeTypeBindings("module-info.java") - requires com.example.sub.a * MD[com.example].resolveModuleDirectives() * BMB[com.example.sub.a].cachePartsFrom() - requires com.example.sub.b * LE.getModule(com.example.sub.b) * LE.completeTypeBindings(module-info.java) - export com.example.sub.b -- during MD.resolvePackageDirectives() triggers * SMB[com.example.sub.b].getVisiblePackage("com") * SMB.combineWithPackagesFromOtherRelevantModules() considers <unnamed> * UnNamedModule.getVisiblePackage("com") * considers *all* modules declaring package "com" including com.example.sub.a * BMB[com.example.sub.a].getVisiblePackage("com") * internally uses getAllRequiredModules() * accesses this.requires, which is only half-initialized, since MBM[com.example.sub.a] hasn't completed yet The unexpected dependency edge is when module com.example.sub.b needs to look up package "com" and considers the <unnamed> module (and transitively all modules -- the unnamed module reads all modules). This dependency is not declared. It is contributed from ModuleUpdater.addReadUnnamedForNonEmptyClasspath() This also hints at the difference between success & NPE: the above method is triggered only when a project has a test source folder (which should be able to access the classpath / unnamed module). @Till, this is an example for the relevance of bug 540248, isn't it? In the current implementation this implies that *every* lookup involving modules needs to account for cyclic dependencies, *always*. In some call paths we already have corresponding flags, but not in the above stack. For now I will look for a location that could be more lazy, to avoid the deadly re-entrance.
New Gerrit change created: https://git.eclipse.org/r/136314
(In reply to Eclipse Genie from comment #13) > New Gerrit change created: https://git.eclipse.org/r/136314 This postpones MD.resolvePackageDirectives() from checkAndSetImports() (which is invoked early from LE.completeTypeBindings()) to faultInTypes(). This relies on the fact that we already guarded getExports()/getOpens() with calls to resolvePackageDirectives() to ensure ondemand resolving. During my experiments this avoided the NPE. Additionally, I fixed a typo in BTB.cachePartsFrom() which would let the problem escalate into other locations as well. We're definitely not done here since: (1) I failed to write a test, should really not release the change without such, but I don't have the time to recreate the problem without maven. (2) This fixes just one call path of a problem that could be lurking in many more locations. Also not done: the editor-only error mentioned in comment 0 and reproduced in comment 1 (lower priority).
Gerrit change https://git.eclipse.org/r/136314 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f040c09eb77b61b62871d12824721e3d8c38bade
(In reply to Stephan Herrmann from comment #12) > @Till, this is an example for the relevance of bug 540248, isn't it? I assume it is possible to construct an example for the current bug where all code is in test scope, so I don't think work on bug 540248 would help.
(In reply to Till Brychcy from comment #16) > (In reply to Stephan Herrmann from comment #12) > > @Till, this is an example for the relevance of bug 540248, isn't it? > > I assume it is possible to construct an example for the current bug where > all code is in test scope, so I don't think work on bug 540248 would help. True, it probably won't avoid the issue in all cases. Unfortunately I have no idea if a strategy exists that would make our code safe for all kinds of re-entrance :( Is it a good or bad thing if those risky situations are triggered more frequently due to bug 540248? Let's us find this kind of bugs earlier?
@Stephan: Thank you for providing the NPE fix. I just want to test it but the latest eclipse integration build (https://download.eclipse.org/eclipse/downloads/drops4/I20190205-1800/) failed. When will the next build be triggered (MEZ)? Alternatively, is there an easy way to download and integrate https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tag/?h=I20190205-1800?
(In reply to Sam Peters from comment #18) > @Stephan: Thank you for providing the NPE fix. I just want to test it but > the latest eclipse integration build > (https://download.eclipse.org/eclipse/downloads/drops4/I20190205-1800/) > failed. When will the next build be triggered (MEZ)? Build failures, additional builds etc. are discussed on the platform-releng-dev mailing list: https://www.eclipse.org/lists/platform-releng-dev/ > Alternatively, is there an easy way to download and integrate > https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tag/?h=I20190205-1800? Depends on what's easy for you :) Since the build failed hard, I don't think we have any artifacts from it. If you have a workspace with JDT sources you can always use the export wizard to create the plugin jar, which could then be carefully substituted (same filename!) in eclipse/plugins. OTOH, the next successful build should never be far away.
> TOH, the next successful build should never be far away. Ok, I tested with today's newest version: https://download.eclipse.org/eclipse/downloads/drops4/I20190206-1800/. Results are: > During my experiments this avoided the NPE. Confirmed. The NPE bug is solved in our projects, too. Thanks a lot :) > Also not done: the editor-only error mentioned in comment 0 > and reproduced in comment 1 (lower priority). Confirmed, this original bug ("The type com.example.sub.b.B is not accessable.") remains unsolved. And, for us, it now has *high* priority since it hinders our current development much more than in the previous version: - version 20190130: We see many false-positive error markers in nearly all of our project's .java files but could resolve *all* of them by reordering the requires directives in the module-info.java files (simply said, the ones with no dependencies first, the ones with the most dependencies last). For the attached example we could solve it by simply toggling the both requires statements as shown in my Comment #6. - version 20190206: The "reordering" workaround doesn't work anymore, thus, we get permanently false-positive error markers in almost all of our project's .java files. In the first example "ready-to-test repo projects" attached in this bug report I can reproduce it by Dummy-Edit > Save > Dummy-Edit > Save the Example.java file: Sometimes the error marker is visible in the editor, sometimes not, even *with* toggled requires statements. (In contrast, in our real project, there remain *always* error markers which is *very* irritating). @Stephan: This is really a bad situation for us: On the one hand, we need the new Eclipse 20190206 update due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=544126 to go on with JDK 11 migration, on the other hand we need also this remaining bug to be fixed (or at least the "reordering" workaround working again ;-) I guess that many other developers may be concerned about this bug. I wish that it will get a high priority and will be solved soon. Thank you very much in advance.
Since this bug is critical for our further development based on JDK11 I'd like to demonstrate the negative effects: Therefore I added a few more (pure java) projects to the initially appended 'ready-to-test repro projects' example to make it more similar to our real project. I will upload the extended example as new attachment (bogus_demo_java_projects.zip). I'll also upload a screenshot (bogus_demo_screenshot.png) showing the effect that each time I enter a dummy space in Example.java, I get *different* false-positive error markers. As you see this is very irritating, especially in projects with much *more* classes. @Stephan: We'd be very glad to get this bug fixed as soon as possible. Thank you very much :)
Created attachment 277503 [details] bogus_demo_screenshot.png
Created attachment 277504 [details] bogus_demo_java_projects.zip
Bulk move out of 4.11
Moved to 4.12? Oh, thats no good news. It is really annoying to work with the latest version of Eclipse because we currently can't distingish between real errors and those many bogus errors shown in the editor. And, currently, it does affect nearly all classes of our projects and we don't see a practical workaround (except keeping with JDK8 but this is not recommended and impossible to get a jlink-compatible version!). We put a lot of effort to explain this bug (see latest examples and screenshot) so it is easily reproducable, even without maven. For us, it is hard to understand why it got moved without comment to 4.12 (which I guess won't be released before 06/2019 or even later?). So, please re-evaluate your decision, or at least, give a comment about this. Eclipse is such a great IDE that we wan't to keep going with, but this bug really makes work incredibly hard now. Thank you for your understanding.
(In reply to Manoj Palat from comment #24) > Bulk move out of 4.11 I assume this was done as part of a large bulk change and this bug accidentally got through. Considering that Stephan commented on this bug as late as last week, there perhaps is still a chance we might consider this for 4.11. I will let Stephan respond to comment #25.
@Jay Arthanareeswaran, this would be really great. Thank you for your fast feedback!
(In reply to Jay Arthanareeswaran from comment #26) > (In reply to Manoj Palat from comment #24) > > Bulk move out of 4.11 > > I assume this was done as part of a large bulk change and this bug > accidentally got through. > Yep - my bad - this was moved out accidentally as part of "panic bulk move" - missed out that the last comment was as late as last week. Will be kept on the radar for 4.11
Ok, thanks. Should it then be reassigned to target milestone 4.11?
(In reply to Manoj Palat from comment #28) > (In reply to Jay Arthanareeswaran from comment #26) > > (In reply to Manoj Palat from comment #24) > > > Bulk move out of 4.11 > > > > I assume this was done as part of a large bulk change and this bug > > accidentally got through. > > > [...] "panic bulk move" [..] Concerning [9] bugs against 4.11 the panic is mine ;)
New Gerrit change created: https://git.eclipse.org/r/136812
(In reply to Eclipse Genie from comment #31) > New Gerrit change created: https://git.eclipse.org/r/136812 Wow, a tiny change after a long day of debugging. This package lookup has a lot of non-determinism, assumably due to iterating over hashed collections. This made debugging quite painful (blaming myself for the complexity of the implementation). Anyway, I found two simple sources for corruption of the structure of ModuleBinding & (Split)PackageBinding: (1) when ModuleBinding#getVisiblePackage() was called with 'considerRequiredModules=false' it was wrong to call ModuleBinding#addPackage(), because this caused clients requesting the package later to work with incomplete information as to which modules define the package. Fixed by guarding the call to ModuleBinding#addPackage() (2) before ModuleBinding#getVisiblePackage() calls PackageBinding#addPackage() and during combineWithPackagesFromOtherRelevantModules() we could not see a freshly created PackageBinding, causing us to create duplicates of the same binding, which is of course can lead to all kinds of confusion. Fixed by a preliminary call to PackageBinding#addPackage() right before combineWithPackagesFromOtherRelevantModules() to ensure the new package is already visible via its parent. The change includes attachment 277400 [details] converted into a JUnit. Additionally I imported attachment 277504 [details] into a runtime workbench, opened Example.java, made some whitespace changes & saves and saw no errors. Let's keep fingers crossed!
Gerrit change https://git.eclipse.org/r/136812 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7411c5d64b4f841347cb94c0ae326a6cb0df5581
(In reply to Eclipse Genie from comment #33) > Gerrit change https://git.eclipse.org/r/136812 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=7411c5d64b4f841347cb94c0ae326a6cb0df5581 Released for 4.11 M3
@Stephan: Being curious I realized that according to https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/log/ the latest fix seems not yet being included in the newest build https://download.eclipse.org/eclipse/downloads/drops4/I20190212-1800/. Thus, I downloaded the latest build (20190212) and followed the instructions in Comment #19, checked the JDT-core project out from https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/, exported the plugin jar and replaced the existing jar (/eclipse/plugins/org.eclipse.jdt.core_3.17.0.v20190210-1155.jar) of the latest build with the exported one. Indeed, the example bogus_demo_java_projects.zip doesn’t show any warnings anymore, that’s great! But the fix seems to introduce a new bug with equivalent error messages ("type com.a.A is not accessible") in another situation hindering us to go on with the new version. I tracked it down to the following example (I’m going to upload a new example as well as a screenshot). It’s actually quite easy to reproduce. Assume two pure-java projects A and B (depends A via modulepath), each containing a java-module: === Project A === package com.a; public class A {} open module com.a { exports com.a; } === Project B === // The type com.a.A is not accessible, DOESN’T compile and run package com.a.b; import com.a.A; public class B { public static void main(String[] args) { A a = new A(); System.out.println(a); } } // No errors package com.c; import com.a.A; public class C { public static void main(String[] args) { A a = new A(); System.out.println(a); } } open module com.a.b { requires com.a; } The problem here is that classes in package com.a.b of module com.a.b don’t have access to package com.a of module com.a (which might be obviously wrong), whereas classes in another package com.c of module com.a.b DOES have. As a result, class B shows again errors like "type com.a.A is not accessible", and besides, it doesn't compile anymore whereas it did with the new original plugin jar, see also the screenshot appended. (The new behaviour might be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=544126 due to the fact that package names seem to have impact on the building process.) Can you confirm this errorneous behavior with the new example (bogus_demo_java_projects_2.zip and bogus_demo_java_projects_2.png)? If yes, we'd be glad if you could re-open this bug and fix it as well. Thank you very much for your work :)
Created attachment 277560 [details] bogus_demo_java_projects_2.png
Created attachment 277561 [details] bogus_demo_java_projects_2.zip
@Stephan Herrmann: Since I'm not sure if comments in resolved bugs still get attention and the error desribed in comment #35 is obviously a new (compiler, not only editor) bug, this time I gave it a new home: bug #544432 So, we can let this one resolved and (for me) verified fixed :), see comment #35.
(In reply to Sam Peters from comment #38) > So, we can let this one resolved and (for me) verified fixed :), see comment > #35. Marking as verified using self-compiled jdt.core on 2019-02-13.
Per comment #39, moving to verified.
*** Bug 544607 has been marked as a duplicate of this bug. ***
