Community
Participate
Working Groups
I have the class HandlerService open. If I go to the import statement for Expression, and press F3, the class is not found and instead I get prompted to choose from classes with the same name but in the wrong packages. If I go to IHandlerService and place the caret in activateHandler(3 args) and search references, none are found. Yet there are references to this method.
BTW, If I invoke CTRL+SHIFT+T, the open type dialog has no problem finding core's version of the Expression class.
Who can name that bug in one clue? The problem with this class' visibility goes away by closing a certain project in my workspace. More symptoms of the original problem: running snippets against HandlerService fails in the variables view. It complains that Expression is indirectly required. Code assist fails in the snippets pane as well. Reproducible in 3.1.1 as well as 3.2 M4.
I can reproduce the described problem with the following test case 1) create a new workspace 2) create a new Plug-in project ('New>Project...>Plug-in Project') 3) open IHandlerService 4) select the import statement for Expression and press F3 Code select doesn't find 'org.eclipse.core.expressions.Expression' because this type isn't on the classpath. Randy - Is your problem the same as my test case ?
(In reply to comment #3) > I can reproduce the described problem with the following test case > 1) create a new workspace > 2) create a new Plug-in project ('New>Project...>Plug-in Project') > 3) open IHandlerService > 4) select the import statement for Expression and press F3 > Code select doesn't find 'org.eclipse.core.expressions.Expression' because this > type isn't on the classpath. > Randy - Is your problem the same as my test case ? No, my problem is not the same. First of all, what is the "classpath" if I am looking at a class that is not even in my workspace? Can you add a step 5), open Expression? If that works, why does 4) fail? But, to get back to my scenario, 'Expression' is on *a* classpath somewhere in my workspace, so step 4) should work for me. But, it is not on every classpath in my workspace. When I open IHandlerService.class, how do you determine the appropriate classpath for that editor? It should be the union of all classpaths.
The other thing I don't understand is that Expression IS on the classpath of HandlerService. So, when inspecting HandlerService at runtime, why can't I invoke methods on it that require visibility of the class Expression? What is the context in which I am invoking snippets? Is it not the classloader of that class?
This is now reproducible in source files. Content assist fails, F3 fails, etc., for a type that is compiling fine.
The problem in the file loaded as source might be unrelated. Jim Zhang to attach problematic source file and symptoms.
Here's the source. I suspect there's anything significant in it though. pre-release code has been masked. package com.ibm.etools.xxx.xxx; import org.eclipse.core.commands.ExecutionException; import org.eclipse.core.commands.operations.AbstractOperation; import org.eclipse.core.resources.IFile; import org.eclipse.core.runtime.IAdaptable; import org.eclipse.core.runtime.IProgressMonitor; import org.eclipse.core.runtime.IStatus; import com.ibm.etools.xxx.PortletArtifactEdit; import com.ibm.etools.xxx.xxx.IPortletJSPFileEntry; public class xxxxxx extends AbstractOperation { private IFile controllerClass; private IPortletJSPFileEntry[] jspFiles; private PortletArtifactEdit portletModel; public xxxxxx(String label, IFile controllerClass, IPortletJSPFileEntry[] jspFiles, PortletArtifactEdit portletModel) { super(label); this.controllerClass = controllerClass; this.jspFiles = jspFiles; this.portletModel = portletModel; } public IStatus execute(IProgressMonitor monitor, IAdaptable info) throws ExecutionException { return null; } public IStatus redo(IProgressMonitor monitor, IAdaptable info) throws ExecutionException { return null; } public IStatus undo(IProgressMonitor monitor, IAdaptable info) throws ExecutionException { return null; } }
it turned out that my problem was due to missing dependencies. Once I added a few more plugins to the dependency list the file is fine. But usually I get an error saying a dependent class can't be accessed. why not in this case?
I thought the file was clean without compile errors, no?
I don't see any compile errors being flagged at all. Technically there should be since a dependent class, not sure exactly which, might have been a transitively dependent one, was missing.
Jim, is there a single red X for the entire project? If so, compilation is not attempted because of a classpath problem.
I verified all the signs of a compile error, including the kind of error about not building because of unresolved dependent types, etc. Everything from the UI points to a successful java compile. No log entries either.
In that case, comment 9 is invalid?
I stress that "UI points to a successful compile". However underneathe the cover dependencies were missing so JDT should've indicated as such, but it didn't. That's the net of the problem as far as I saw it.
Jim, it sounds like a separate bug. The original bug is still valid. Funny that no one was curious about the clue in comment 2. The problem goes away by closing a project which imported the plug-in containing HandlerService, but that project did *not* import the plug-in containing Expression. But other projects imported both, so closing the first project left only the projects which imported both. The project I was forced to close was not even being used when I discovered the problem.
IKeybindingService is deprecated, so it's really annoying to be browsing its new replacement (IHandlerService) and not be able to use F3, and many other JDT functions. Will this be fixed for 3.2?
Another broken scenario: 1) Open SlaveHandlerService 2) in the method activateHandler(String,IHandler), go to the line that invoke doActivation 3) Press F3, it fails to navigate within the same file Come on, the method is inside the editor and I still can't navigate to it? This is a MAJOR FLAW in the design for classpaths of classes loaded as binary.
I think this bug (descibed in comment 0 and comment 18) is caused by bug 73957. My test case in comment 3 show that. But there is another problem that complicate the scenario. Because the missing type Expression can be seen on the classpath of another project. In this case open type can works, and code select failed. And when element that you opened with Open Type or opened in Package Explorer can come from another project than expected (see bug 142467). So the problems described in this bug report should disappear if bug 73957 is fixed. The bug 73957 would probably be fixed for 3.3 (see bug 142023 comment 8)
Need to check this bug when 73957 will be fixed. Close as LATER.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
