Community
Participate
Working Groups
Steps to reproduce 1. create new plugin project that depends on org.eclipse.jdt.launching, org.eclipse.debug.core, org.eclipse.core.runtime 2. in this project create new java class test.MyLauncher that extends org.eclipse.jdt.launching.JavaLaunchDelegate 3. inside MyLauncher press Ctrl-Space to invoke code assist and select to implement getVMArguments(ILaunchConfiguration) method Problem: code assist inserts different mothod! I've tested this with 3.1M6 in two fresh workspaces. Another "interesting" thing to note: Java editor does not show overrides marker when I manually define getVMArguments(ILaunchConfiguration).
This caused by the fact that not all dependent projects are in your workspace and hence the AST can't be correctly built. You can workaround this by importing all relevant projects. See also bug 79966. *** This bug has been marked as a duplicate of 73957 ***
This problem exists even with all relevant projects imported into the workspace as binary projects with or without sources attached. It goes away only if I import org.eclipse.jdt.launching and org.eclipse.debug.core as projects with source folders (which is not an option as my product depends on closedsourced thirdparty code). Reading discussions of bugs 79966 and 73957 I think this is a different problem as in my case both org.eclipse.jdt.launching and org.eclipse.debug.core are in the workspace, explicitly refenced as dependecies of my plugin and are on classpath of my plugin via "Plugin dependencies" classpath container. It is also possible to reproduce the problem without PDE involed: 1. create java project debug.core with org.eclipse.debug.core_3.1.0.jar, add org.eclipse.debug.core_3.1.0.jar to the project build path and export it. 2. likewise, create jdt.launching java project with org.eclipse.jdt.launching_3.1.0.jar exported library 3. likewise, create core.runtime java project with org.eclipse.core.runtime_3.1.0.jar exported library 4. create java project bug90234jdt that requires debug.core and jdt.launching projects 5. in bug90234jdt, create new java class test.MyLauncher that extends org.eclipse.jdt.launching.JavaLaunchDelegate 6. inside MyLauncher press Ctrl-Space to invoke code assist and select to implement getVMArguments(ILaunchConfiguration) method As with original PDE-based scenario, code assist inserts different method and outline does not show overrides marker if I create the method manually Tried with 3.1 final and partially with 3.2 I20050830-0800.
Your example results in a compile error in MyLauncher which tells you that some types are missing. If I add org.eclipse.core.runtime and org.eclipse.core.resource that error goes away and I can then reproduce the problem: if I enter getVM<code assist> a different method is inserted (handleDebugEvent). This should not happen i.e. if code assist offers me method X then it should insert X. The problem seems to be the build path. I guess J Core cannot build the AST bindings in this case. This can be seen by using Source > Override/Implement Methods on MyLauncher: all methods from AbstractJavaLaunchConfigurationDelegate are missing but they appear when looking at the type hierarchy of MyLauncher. Note that importing org.eclipse.jdt.launching with all required plug-ins does not fix the problem either. Only when I added all (didn't try which one was missing) those imported projects to project bug90234jdt it started to work.
Note that JDT Core's code assist probably returns the correct signature but we then fail to compute the code in JDT UI due to the missing bindings.
The question is: why does the code compile but we don't get the AST?
To clarify my setup: bug90234jdt "requires" core.runtime, debug.core and jdt.launching. I apologize for the confusion. By the way, I can reproduce the problem without core.runtime by trying to override getBreakpoints(ILaunchConfiguration) or other methods from AbstractJavaLaunchConfigurationDelegate. I guess, getVMArgs has classes from core.runtime in its signature and it gets filtered out.
*** Bug 109630 has been marked as a duplicate of this 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
