Community
Participate
Working Groups
Several projects cannot be started with right click -> Debug As/Run As -> Java Application any more. Error is "Editor does not contain a main type Eclipse" Reverted back to 4.10 and everything works fine.
Which Java version are you using ? There can be many reasons behind this - http://zenverse.net/editor-does-not-contain-a-main-type-error-in-eclipse/ https://stackoverflow.com/questions/24117713/editor-does-not-contain-a-main-type-in-eclipse Can you attach a sample project and excact steps to reproduce the problem and the Java version used.
I'm using Java 11. I don't think this is a problem due to a false configuration as the issue is gone when I revert back to 4.10. I don't have a sample project that I can share and I don't know how to reproduce the issue. I created this so others can share additional information. I'm sure I'm not the only one with this problem.
(In reply to T3rm1 from comment #2) > I'm using Java 11. I don't think this is a problem due to a false > configuration as the issue is gone when I revert back to 4.10. > I don't have a sample project that I can share and I don't know how to > reproduce the issue. OK, but this means we won't spend time on this unless more information is provided.
Is there anything in the .log?
Did you use Oomph for installation? If yes, can you try without it and see if it solves the problem ?
Created attachment 277977 [details] Log file from workspace This is the log file created by Eclipse 4.11 after importing the project it fails to find main() method for.
Hi. Facing the same problem here: "Editor does not contain a main type". I installed the new eclipse 4.11 for Java Developers twice, the first time I downloaded the .exe installer, the second time from Genuitec mirror the x86_64.zip archive. The problem exists in both cases (as a tryout of the suggestion in comment 5). When using the 4.10 again the problem does not appear. The project is huge and couldn't not attach it here in any case. When creating a new project to try to reproduce the problem (to paste it here), the problem does not come up. An example main class with a simple system.out.println("hello") runs fine (both when creating a project with and without modules). It is a Java project, with dependency management by Gradle 5.0, so most suggestions in the links provided in comment 1 that suggest putting the .java sources inside the src problem don't seem to apply here. The problem exists both when I used the existing workspace created by Eclipse 4.10 and when creating a new one and importing the project. Furthermore, when I Right click inside the class containing the main method --> Run as ---> Run Configurations --> Java application --> (double click for new configuration) --> Selecting the current project the "Search" for main classes does not yield any results. The system is set on a Win10 x64 laptop with the Oracle JDK 11.0.1. I attached the log of a new workspace created by Eclipse 4.11 after importing the project and failing to find a main method to run it.
Logs says - org.osgi.framework.BundleException: Could not resolve module: org.eclipse.mylyn.bugzilla.core [270] Unresolved requirement: Require-Bundle: org.apache.xmlrpc -> Bundle-SymbolicName: org.apache.xmlrpc; bundle-version="3.0.0.v20100427-1100" org.apache.xmlrpc [57] Unresolved requirement: Import-Package: javax.xml.bind Unresolved requirement: Require-Bundle: org.eclipse.mylyn.commons.xmlrpc; bundle-version="[3.8.0,4.0.0)" -> Bundle-SymbolicName: org.eclipse.mylyn.commons.xmlrpc; bundle-version="3.24.2.v20180904-2231"; singleton:="true" org.eclipse.mylyn.commons.xmlrpc [287] Unresolved requirement: Require-Bundle: org.apache.xmlrpc; bundle-version="[3.0.0,4.0.0)" -> Bundle-SymbolicName: org.apache.xmlrpc; bundle-version=" Moving to Mylyn for comments.
To provide further info, When uninstalling all components with "Mylyn" in their name from 'Help-->Install new software-->what is already installed?', after an Eclipse restart the problem continues.
Hello, same problem (and others) here. Eclipse SDK - Version: 2019-03 (4.11), Build id: I20190307-0500 Java: openJDK 11 and Oracle JDK 1.8.0 I don't think it is special to Mylyn - looks more like JDT. Here my history/findings: I changed from Eclipse 4.10 to 4.11 when the problems started (migrated and new workspace). The problems (up to now) are: * right-click -> run as java app does not work anymore * call hierarchies are broken / empty * builds are not reliable any more: after a clean/full-build some projects have 'strange' errors on some projects errors vanish when doing a clean for the project only others stay in error state - example reason: classes from other projects are not found - although the referenced project compiles ok All the projects use the workspace settings - which are: Compiler compilance level 11 default JRE: openJDK 11 (with --add-modules=ALL-SYSTEM set as default-parameter, which worked fine up to Eclipse 4.10) Now the clue: changing from Java 11 back to 8 (level 8, default JRE: Oracle 1.8.0) solves all the problems. Switching back to Java 11 also shows the above mentioned problems again PLUS (maybe a hint to the source of the problems (modul-system ?)) leaves some (2 at the moment) projects in error-state which can be cleared by a clean build of that projects: The main errors are: firs project: * DataHandler cannot be resolved to a type * The package javax.activation is accessible from more than one module: <unnamed>, rt second project: * JAXBContext cannot be resolved * The package javax.xml.bind is accessible from more than one module: <unnamed>, resources, rt The outcome of the switching of the java-targets (8 to 11 and back) is reproduceable: 8 is error-free, 11 is troubles What I tried also is to start Eclipse with Java 8 and 11 and more initial memory (8GB) - but that did not change any of the symptoms. Hope that helps. Greetings Kurt
Eclipse Platform and JDT supports Java 11 since 4.10. Definitely issues will be there moving from Java 8 to Java 9, 10 11 or 12 as they have breaking changes with respect to encapsulation but same project working with Java 11 in 4.10 should not stop working in 4.11. If you could reproduce for a simple java project with steps we can proceed else we need to find a right place for this bug to be worked on.
Hello, I could find a (more or less) simple constellation: you got to have 3 projects: P1, P2 and P3 * create class C1 in project 1: package anypkg1; public class C1 { public static void main(final String[] args) { System.out.println("C1"); } } * create class C2 in project 2: package anypkg2; import anypkg1.C1; public class C2 { public static void main(final String[] args) { C1.main(args); System.out.println("C2"); } } * add log4j-libraries log4j-api-2.11.0.jar log4j-core-2.11.0.jar in project 3: * create class C3 in project 3: package anypkg3; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import anypkg2.C2; public class C3 { public static void main(final String[] args) { final Logger log = LogManager.getLogger(C3.class); C2.main(args); System.out.println("C3"); } } now right-click in editor of C3 and choose Run As Java Application - should give the error. delete or comment out import and call of C2 - now Run As Java Application works or delete or comment out logger-lines - again should run ok I'm not sure, but I don't think log4j is the source of the problem (see delete import and call of C2).
(In reply to kurt ablinger from comment #12) > > * add log4j-libraries > log4j-api-2.11.0.jar > log4j-core-2.11.0.jar > in project 3: Did you add these jars to Modulepath or Classpath ? https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 You can see in this post - Moving on to Log4j 2: Log4j 1.2 is broken on Java 9
to the classpath also the projects are no java-11-modul-projects (don't create modul-info.java) also P2 adds P1 and P3 adds P2 to its added projects the log4j used is 2.11 - so shouldn't be a problem
hello, just to show it has nothing to do with log4j I created another class (java 8 compiled) which I packed into a jar which I added to project 3 instead of the log4j-jars: package anypkg4; public class C4 { public C4() { super(); } public void run() { System.out.println("C4 running"); } public static void main(final String[] args) { System.out.println("C4"); } } the modified C3 class then looks like this: package anypkg3; import anypkg2.C2; import anypkg4.C4; public class C3 { public static void main(final String[] args) { C2.main(args); System.out.println("C3"); final C4 c4 = new C4(); c4.run(); } } the same as before applies: * unmodified - error * commented c4 (import also!) -> ok * unmodified - but java 8 -> ok
another 2 cents: whatever the cause is - the error message is wrong anyway - there is a main-method
(In reply to kurt ablinger from comment #15) > hello, > > just to show it has nothing to do with log4j I created another class (java 8 > compiled) which I packed into a jar which I added to project 3 instead of > the log4j-jars: > > package anypkg4; > public class C4 { > public C4() { > super(); > } > public void run() { > System.out.println("C4 running"); > } > public static void main(final String[] args) { > System.out.println("C4"); > } > } > > the modified C3 class then looks like this: > > package anypkg3; > import anypkg2.C2; > import anypkg4.C4; > public class C3 { > public static void main(final String[] args) { > C2.main(args); > System.out.println("C3"); > final C4 c4 = new C4(); > c4.run(); > } > } > > the same as before applies: > * unmodified - error > * commented c4 (import also!) -> ok > * unmodified - but java 8 -> ok Works perfectly well for me with Java 11 and Eclipse 4.11 SDK Project. I am attaching the Projects used.
Created attachment 278134 [details] Projects1_4
that way it works for me too. my setup is: all of the projects use the workspace default as described earlier (opend jdk 11, compilance 11). and important: do not add project 4 to project 3 ! instead create a jar from class C4 and add the jar to the buildpath of project 3 (I exported the jar to project 3/libs and used add to buildpath). to be able to switch betweend java 8 and 11 without re-exporting the jar, I set the workspace-default to java/compilance 8 before creating the jar - then back to 11. now you should be able to reproduce the problem.
I have several project which already have running setups that I can't run by right click-> run as-> java application. However I still can run them by launching the already present configuration. Among those project I just created an empty one that does nothing in its main. None of them use some kind of mylin, I did not install any more thing than what was installed with the oomph to that regard. No log4j (I use slf4j). I have a lot of plugin though, especially maven. I tried creating a new java project with an empty main class and I can start it.
The report is still assigned to Mylyn - IMHO it should be (re-)assigned to JDT (I am not allowed to change that). Yes, it is possible to start it via the run-configuration. But that does not solve/fix the problem - it is a workaround. And there is another problem (maybe related) - as mentioned before - and reproduceable with my setup: get the call-hierarchy of C2.main() (by right-click or shortcut - no diff) - it should show that it is called by C3.main() - but it does not
Just found: workspace reference of C2.main() also incorrect no ref to C3, instead it marks the call to C1.main in C2.main. problem with index-builder ? That's it for today.
Thanks a lot Kurl for digging out. I was able to reproduce the problem, and this seems to work fine with 4.12 latest I build. Also the problem does not surface if I change the compliance to 1.8 for Project 3. Somewhat related bug is Bug 546004.
An update on this: If through the outline view I right click on main-> run as-> Java Application it runs normally every time. A collaborator of mine on the same project mentioned that if the Java application was launched through the outline view, then the subsequent runs for that specific file could be launched normally through the editor. For other files he had to do the same first launch through the outline. Sadly I couldn't reproduce that in my machine. Although I can launch successfully through the outline view the subsequent attempts to launch through the editor are unsuccessful.
*** Bug 546573 has been marked as a duplicate of this bug. ***
Hello, I have the same problem on my project: - I am using Eclipse 2019-03 (RCP) (I'll attach my plugin after if needed) with Open JDK 11.0.2 on Windows 10. Also tested with Java 8 (it fail). - The project is a m2e based project and use Java 11. There are no dependencies beside modules found in the JDK (a single transitive java.desktop). - Manually configuring the Launch, that is selecting the main type directly, is working. - Exporting as executable JAR produce an error telling me the configuration (manually edited) is invalid - There are no error in the log. I don't know how to change them (there is a tracing in the Preferences, but I don't know which one to enable). - I can run main method from the Outline. - Workspace compliance level was Java 8, switched to Java 11 without any change. The project is in Java 11. This was working before... but I switched from Java 8 to Java 11. Note: I can execute the JAR using command line: /e/apps/portable/java/openjdk-11.0.2/bin/java --module-path 'myjar-1.0.0-SNAPSHOT.jar' --module mod1/mod1.Main By the way, not related (?), but my module-info.java have this error: Failed to resolve selection in ‘=mod1/src\/main\/java<{module-info.java’ at offset 7. java.lang.NullPointerException at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:192) at com.google.common.base.Optional.of(Optional.java:86) at org.eclipse.recommenders.internal.rcp.JavaElementSelections.resolveJavaElementFromTypeRootInEditor(JavaElementSelections.java:141) at org.eclipse.recommenders.internal.rcp.JavaElementSelections.resolveJavaElementFromEditor(JavaElementSelections.java:119) at org.eclipse.recommenders.internal.rcp.JavaElementSelections.resolveJavaElementFromEditor(JavaElementSelections.java:102) at org.eclipse.recommenders.internal.rcp.JavaElementSelectionService.handleSelectionInEditor(JavaElementSelectionService.java:108) at org.eclipse.recommenders.internal.rcp.JavaElementSelectionService.access$1(JavaElementSelectionService.java:105) at org.eclipse.recommenders.internal.rcp.JavaElementSelectionService$1.run(JavaElementSelectionService.java:82) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834)
(In reply to NoDataFound - from comment #26) > Hello, > > I have the same problem on my project: > > - I am using Eclipse 2019-03 (RCP) (I'll attach my plugin after if needed) > with Open JDK 11.0.2 on Windows 10. Also tested with Java 8 (it fail). > - The project is a m2e based project and use Java 11. There are no > dependencies beside modules found in the JDK (a single transitive > java.desktop). > - Manually configuring the Launch, that is selecting the main type directly, > is working. > - Exporting as executable JAR produce an error telling me the configuration > (manually edited) is invalid > - There are no error in the log. I don't know how to change them (there is a > tracing in the Preferences, but I don't know which one to enable). > - I can run main method from the Outline. > - Workspace compliance level was Java 8, switched to Java 11 without any > change. The project is in Java 11. > > This was working before... but I switched from Java 8 to Java 11. > > Note: I can execute the JAR using command line: > > /e/apps/portable/java/openjdk-11.0.2/bin/java --module-path > 'myjar-1.0.0-SNAPSHOT.jar' --module mod1/mod1.Main > > By the way, not related (?), but my module-info.java have this error: > > Failed to resolve selection in ‘=mod1/src\/main\/java<{module-info.java’ at > offset 7. > java.lang.NullPointerException > at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:192) > at com.google.common.base.Optional.of(Optional.java:86) > at > org.eclipse.recommenders.internal.rcp.JavaElementSelections. > resolveJavaElementFromTypeRootInEditor(JavaElementSelections.java:141) > at > org.eclipse.recommenders.internal.rcp.JavaElementSelections. > resolveJavaElementFromEditor(JavaElementSelections.java:119) > at > org.eclipse.recommenders.internal.rcp.JavaElementSelections. > resolveJavaElementFromEditor(JavaElementSelections.java:102) > at > org.eclipse.recommenders.internal.rcp.JavaElementSelectionService. > handleSelectionInEditor(JavaElementSelectionService.java:108) > at > org.eclipse.recommenders.internal.rcp.JavaElementSelectionService. > access$1(JavaElementSelectionService.java:105) > at > org.eclipse.recommenders.internal.rcp.JavaElementSelectionService$1. > run(JavaElementSelectionService.java:82) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java: > 515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent. > ScheduledThreadPoolExecutor$ScheduledFutureTask. > run(ScheduledThreadPoolExecutor.java:304) > at > java.base/java.util.concurrent.ThreadPoolExecutor. > runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker. > run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) This looks a little different case. Can you try if your project works with 4.10 or 4.12 latest I build ? If you are able to reproduce with 4.10 and 41.2 then please create a new bug ( somewhat similar to Bug 525711). If it is reproducible in only 4.11 then please attach a workspace or Project to this bug with all the dependencies so that we can reproduce and understand the problem.
With the project I can't share: - (1) Eclipse RCP 2018-12 without any plugins/updates: "Run as" works. - (2) Eclipse RCP 2019-09 without any plugins/updates: "Run as" fails. - (3) Eclipse RCP 2019-09 with attached plugins (see file): "Run as" fails. Note: when "Run as" works, export as Runnable JAR works although you need to have a "Launcher" to create it (that's why I could not test case 2 and runnable jar). I don't classify this as another bug (the Exception trace are unrelated and spawn when I select some text). With a sample project (see below): - Eclipse RCP 2019-09 with attached plugins (see file): "Run as" works The sample project is a simple Main: it compile with Maven and Java 11. package testing.nodatafound.eclipse; public class Main { public static void main(final String[] args) { System.out.println("Hello World"); } } I played with my main a bit: - The initial main is the following: public static void main(final String[] args) throws IOException { initializeLookAndFeel(); final Path currentDirectory = Paths.get("").toRealPath(); final SortedSet<FS> files = findFiles(args); final FileTableModel fileTableModel = initializeTableModel(files); files.clear(); new DirectoryFlattenerFrame(currentDirectory, fileTableModel).setVisible(true); } - I removed all stuff beside the main method, like this: this works and I assume something in my code is making Eclipse fails. public class Main { public static void main(final String[] args) { initializeLookAndFeel(); } private static void initializeLookAndFeel() { try { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); } catch (@SuppressWarnings("unused") final Exception e) {} } } - I could reduce my main to this: public static void main(final String[] args) { initializeLookAndFeel(); final Path currentDirectory = Paths.get(""); final SortedSet<FS> files = findFiles(args); final FileTableModel fileTableModel = new FileTableModel (); files.clear(); new DirectoryFlattenerFrame(currentDirectory, fileTableModel).setVisible(true); } This was not working. However, I removed the now unused (findFiles, initializeTableModel) and it worked **ONLY** after I cleaned the imports: Initial: package my.awesome.pkg; import static java.util.stream.Collectors.toSet; import java.io.IOException; import java.nio.file.FileVisitResult; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.file.SimpleFileVisitor; import java.nio.file.attribute.BasicFileAttributes; import java.util.HashSet; import java.util.Objects; import java.util.Set; import java.util.SortedSet; import java.util.TreeSet; import javax.swing.UIManager; import my.awesome.pkg.model.FileItem; import my.awesome.pkg.model.FileTableModel; Working case: package my.awesome.pkg; import java.io.IOException; import java.nio.file.Path; import java.nio.file.Paths; import javax.swing.UIManager; import my.awesome.pkg.model..model.FileTableModel; I then looked at the import, and found the one posing problem (but I don't know the specific): I replaced my calls to Objects.toString(Object, "") to java.util.Objects.toString(Object, "") and organized imports to remove the "import java.util.Objects;" => Eclipse could find the main (and it could export as runnable jar as well). I could not reproduce on a simpler project (copying the imports does not change). Since I downloaded a RCP enabled Eclipse, I used the debugger to find what it does... but that's pretty brain whacking. I do understand that it is using the search engine to find the main method, but I did not find the class/resource bundle containing the error message ("Editor does not contain a main type"). I'll retry with the source code, since Eclipse is pretty limited with only JAR.
Created attachment 278603 [details] Set of plugins used when it failed the first time
(In reply to NoDataFound - from comment #28) > With the project I can't share: > > - (1) Eclipse RCP 2018-12 without any plugins/updates: "Run as" works. > - (2) Eclipse RCP 2019-09 without any plugins/updates: "Run as" fails. > - (3) Eclipse RCP 2019-09 with attached plugins (see file): "Run as" fails. > What do you mean by Eclipse RCP 2019-09 ? Do you mean Eclipse RCP 2019-03 ? Eclipse 2019-09 will be released in September 2019.
(In reply to Sarika Sinha from comment #30) > (In reply to NoDataFound - from comment #28) > > With the project I can't share: > > > > - (1) Eclipse RCP 2018-12 without any plugins/updates: "Run as" works. > > - (2) Eclipse RCP 2019-09 without any plugins/updates: "Run as" fails. > > - (3) Eclipse RCP 2019-09 with attached plugins (see file): "Run as" fails. > > > > What do you mean by Eclipse RCP 2019-09 ? > Do you mean Eclipse RCP 2019-03 ? > > Eclipse 2019-09 will be released in September 2019. I'm back from the future with the Eclipse from that time. I did not take the source code, sorry :) Joke aside, it is 2019-03 - it was a typo. Also see https://bugs.eclipse.org/bugs/attachment.cgi?id=278603 for details, that the list of plugin I use if that help. As said, I also tried with a fresh Eclipse without plugins/updates: https://www.eclipse.org/downloads/packages/release/2019-03/r/eclipse-ide-rcp-and-rap-developers
Created attachment 278607 [details] Reproducible scenario Try launching C3.java or ctrl+Shift+G for C4 in C3.java
Created attachment 278608 [details] Reproducible scenario
This looks like a regression from Bug 544860. This scenario works fine till 4.11 M3 build and stops working in RC1 , RC3 and final build. 4.11 build works fine with Java 12 , issue is the combination of 4.11 and Java 11.
I have the same problem (Eclipse-2019-03 and JDK11). However, the program can be started by executing "Run As -> Java Application" invoked from the context menu on the main method from the outline view.
I think the best I can do is put it in 4.11 maintenance for anyone interested in consuming from there. And for the rest, the fix is in 4.12 stream already.
*** Bug 546827 has been marked as a duplicate of this bug. ***
For a couple days now I am using 4.12 (2019-06). Confirming that the problem is fixed for me.
The problem with "Call hierarchy" not showing any results persists in 2019-06 (4.12), Build I20190522-1800. "Call hierarchy" works fine when using the same workspace with Eclipse 2018-12 (4.10.0), Build 20181214-0600.
(In reply to Frederic Schelling from comment #39) > The problem with "Call hierarchy" not showing any results persists in > 2019-06 (4.12), Build I20190522-1800. > > "Call hierarchy" works fine when using the same workspace with Eclipse > 2018-12 (4.10.0), Build 20181214-0600. Can you provide a small reproducible example with steps where call hierarchy is broken?
Created attachment 279247 [details] Eclipse workspace to reproduce broken call hierarchy in Eclipse 2019-06
Created attachment 279248 [details] Screenshot showing reproduction of broken call hierarchy bug in Eclipse 2019-06
(In reply to Sarika Sinha from comment #40) > (In reply to Frederic Schelling from comment #39) > > The problem with "Call hierarchy" not showing any results persists in > > 2019-06 (4.12), Build I20190522-1800. > > > > "Call hierarchy" works fine when using the same workspace with Eclipse > > 2018-12 (4.10.0), Build 20181214-0600. > > Can you provide a small reproducible example with steps where call hierarchy > is broken? Here you go. Attached a screenshot and a zipped Eclipse workspace with cleaned, closed projects. In the workspace there are two projects with just one Java class each. One with a method calling the method of the other class in the other project. PLEASE NOTE that the workspace was "reduced" from my real working workspace which originally contained a lot of other projects, therefore it still has a lot of metadata and the archive is quite big for just these two classes. I threw out the parts one by one and always checked if the bug still persists. I am not sure if I would succeed in reproducing the bug starting off with a clean, empty workspace from scratch. But then, at work with my big normal workspace I already tried many times to setup my workspace again from a clean state, even with a freshly cloned git repo, in the hope that the bug would disappear, but sadly it did not go away. To reproduce, please - Use Eclipse 2019-06, 4.12, build id I20190522-1800 (see screenshot also) - Open the provided Eclipse workspace - In Eclipse prefs, set current JDK to an OpenJDK 11.0.2 - In Eclipse prefs, set compiler compliance level to 11 (This is IMPORTANT, see below.) - Open the two projects and let Eclipse build them - To be sure, just verify that in project idos-util in method ListenerCollection.method1() the other method foo() of class C1 in the other project is called (for example, by pressing F3 while the cursor is on the call c.foo() ). - Now verify the BUG HIMSELF: open class ListenerContainer, position cursor on definition of method foo() and "Open call hierarchy". You should now see that in the call hierarchy view the method foo() apparently has no callers (see screenshot also). IMPORTANT NOTE and probably a clue leading to the cause: After switching the compiler compliance level to 8 the bug has disappeared and the call hierarchy is displayed correctly! Switching back to 11 again makes the bug reappear (call hierarchy not showing the caller).
(In reply to Frederic Schelling from comment #42) > Created attachment 279248 [details] > Screenshot showing reproduction of broken call hierarchy bug in Eclipse > 2019-06 Sorry, But I could not reproduce this issue with the attached project or a similar Project hierarchy created with Java 11 compliance.
(In reply to Sarika Sinha from comment #44) > (In reply to Frederic Schelling from comment #42) > > Created attachment 279248 [details] > > Screenshot showing reproduction of broken call hierarchy bug in Eclipse > > 2019-06 > > Sorry, But I could not reproduce this issue with the attached project or a > similar Project hierarchy created with Java 11 compliance. What about the following reasons why you cannot reproduce the bug: - You used a somewhat different JDK? (mine is OpenJDK 11.0.2 for Windows) - Your Eclipse installation is somewhat different? - Something in your Eclipse preferences is set differently To work around this, I could attach Archives with the corresponding items (Eclipse Installation and JDK). Would you like to try again with those?
(In reply to Frederic Schelling from comment #45) I tried with Open JDK 11 GA (build 11+28) Can you try with it to see if it works?
(In reply to Sarika Sinha from comment #46) > (In reply to Frederic Schelling from comment #45) > I tried with Open JDK 11 GA (build 11+28) > > Can you try with it to see if it works? I tried running Eclipse with build 11+28, but nothing changed, the problem is still persisting. Sarika, did you import the two projects into a workspace of your own or did you launch Eclipse with the workspace I provided?
(In reply to Frederic Schelling from comment #47) > I tried running Eclipse with build 11+28, but nothing changed, the problem > is still persisting. > > Sarika, did you import the two projects into a workspace of your own or did > you launch Eclipse with the workspace I provided? I launched Eclipse in a new workspace ad then imported the attached projects.
(In reply to Sarika Sinha from comment #48) > (In reply to Frederic Schelling from comment #47) > > I tried running Eclipse with build 11+28, but nothing changed, the problem > > is still persisting. > > > > Sarika, did you import the two projects into a workspace of your own or did > > you launch Eclipse with the workspace I provided? > > I launched Eclipse in a new workspace ad then imported the attached projects. That's the reason why the bug doesn't show up. Please launch eclipse and open the provided workspace.
(In reply to Frederic Schelling from comment #49) > > That's the reason why the bug doesn't show up. > Please launch eclipse and open the provided workspace. Can not reproduce with that also.
(In reply to Sarika Sinha from comment #50) > (In reply to Frederic Schelling from comment #49) > > > > That's the reason why the bug doesn't show up. > > Please launch eclipse and open the provided workspace. > > Can not reproduce with that also. I just downloaded the newest Eclipse 2019-06 for Java Developers, Build 20190614-1200. With that build the bug with the broken call hierarchy seems to be fixed! I switched back and forth several times between this one and the build I20190522-1800 of 2019-06, using the same workspace. With the older build the call hierarchy bug is still there, with the newer build it is gone. I don't know with which Eclipse build you tested, but probably the fix of the broken call hierarchy should be documented elsewhere and not here. Don't know if the fixes are really related to each other. Thanks a lot for you time.
Jay, what's the status of this open bug?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
For me it is solved.
