Community
Participate
Working Groups
Build id: 200303272130 (Platform binaries + JDT) IBM JRE 1.3.1 sr2 I tried to see the implementation of a method called by the class I had open in the editor pressing Ctrl while hovering the method identifier, but it simply didn't work. Tried selecting the identifier and opening declaration (through context menu) and did't work either. Looks like a duplicate of bug 35731. I cannot reproduce it anymore. Found dozens of pairs of entries like these in the log file. !ENTRY org.eclipse.ui 4 4 Mar 28, 2003 13:22:41.361 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Mar 28, 2003 13:22:41.361 !MESSAGE java.lang.NullPointerException !STACK 0 java.lang.NullPointerException at java.lang.String.<init>(String.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype (ClassScope.java:789) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperInterfaces (ClassScope.java:627) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy (ClassScope.java:676) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierar chy(CompilationUnitScope.java:252) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings (LookupEnvironment.java:221) at org.eclipse.jdt.internal.codeassist.SelectionEngine.select (SelectionEngine.java:483) at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:155) at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:133) at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect (CompilationUnit.java:100) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$MouseClickListener.getCurrent TextRegion(JavaEditor.java:484) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$MouseClickListener.mouseMove (JavaEditor.java:706) at org.eclipse.swt.widgets.TypedListener.handleEvent (TypedListener.java:140) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:291) at org.eclipse.core.launcher.Main.run(Main.java:747) at org.eclipse.core.launcher.Main.main(Main.java:583)
I could reproduce it with the standard SDK: 1 - open a new workspace with i200303272130 2 - open CVS repository exploring 3 - checkout projects: core.resources, core.runtime, core.resources.win32, core.boot and xerces 4 - close all perspectives 5 - exit Eclipse 6 - open Eclipse - Resources perspective will be opened 7 - using the resource navigator, open org.eclipse.core.resources/src/org/eclipse/resources/IProject.java 8 - holding ctrl while hovering, open declaration for IProgressMonitor 9 - do the same thing for other type identifiers - eventually identifiers won't be underlined anymore, and lots of NPEs will occur.
Reproduced.
Can still workaround a little more against the JIT bug: replacing ... unitScope.recordReference(currentPackage.compoundName, name); Binding binding = currentPackage.getTypeOrPackage(name); ... with the following (2 lines swapped) ... Binding binding = currentPackage.getTypeOrPackage(name); unitScope.recordReference(currentPackage.compoundName, name); ... makes it work !? Still the code is equivalent. Released change for integration.
Actually, the line swapping doesn't seem to solve it all the time (!?), but moving the variable declaration right beside the unitScope local declaration seems to do the trick. What seems to be the offending pattern is the local declaration next to its usage (JIT is likely trying to inline the local value).
Backported to 2.1 maintenance stream.
Fixed in 2.2 stream as well.
*** Bug 36497 has been marked as a duplicate of this bug. ***
*** Bug 37426 has been marked as a duplicate of this bug. ***
Vewrified.
Verified for 3.0M1.
*** Bug 42503 has been marked as a duplicate of this bug. ***