Community
Participate
Working Groups
I had a pointcut with a fully qualified name. When I selected the type name and hit Control-M, it added the import but retained an incorrect leading space. E.g. pointcut bar() : execution(com.Foo); [I hit Control-M with com.Foo selected] import com.Foo; ... pointcut bar() : execution(.Foo);
Firstly, a minor correction to the above - it should be "retained an incorrect leading dot". I've reproduced the problem, and investigated it a little. We have our own implementation of "organise imports", which wrappers the JDT one, but we don't have our own version of "add import", so we can't control the behaviour here. The fix will therefore require this to be implemented, but that is quite a bit of work for a minor problem, so I'm putting it back on the queue for now.
Another problem I see sometimes is that using add import causes the import to jump up ABOVE the package line. This is a bit more of a nuisance. E.g., import java.net.URLClassLoader; <-- added package org.codehaus.ajlib.util.classloader; I use add import a lot probably because I have had organize imports fail on AspectJ code (maybe that's just a historical relic)...
I have the same problem with adding imports, but for me it seems it has something to do with multi line comments (copyright header) at the top of an aspectJ file. If I leave the header comment and the package line is the first one the problem occurs in rare circumstances. I vote for this bug and I would kindly ask for increasing the severity to major, because it's boring that almost ever ctrl+space breaks the file. I can't understand that there aren't more people commenting and voting on this. Or is there a simple workaround I don't know? If so, please tell me. My workaround is to stay as long as possible with the annotation syntax, because here I have no such problems with imports and ctrl+space.
I've run into a similar, and perhaps even more serious problem with Add Import. This problem is new in Eclipse 3.3 (3.2 and earlier are fine). The problem is that 'Add Import' imports only a partial (i.e. corrupted) FQ name in the import e.g.: Given a class: com.my.foo.bar.MyClass In the source editor, select MyClass, and do Add Import (my shortcut key is Ctrl-Shift-I). The import section of the file then shows: import o.bar.MyClass; This of course creates 2 compile errors: 1) that it cannot resolve MyClass, and 2) that the import o.bar.MyClass could not be found (because of course it does not exist). I use Add Import quite a bit, and I've found it to be one of the really useful features of Eclipse. I was hoping the 3.3.1 update release would have addressed this, but alas, the problem is still there. I may now need to roll back to 3.2 to get this functionality back. Could this problem please be escalated to MAJOR, as it corrupts source files.
bumping severity
Some additional information concerning this bug: If the import is to a class within the same project, or the java runtime, the import is ok. If the import is for a class in another project, the corruption occurs. In 3.3, this import corruption occurs always. In 3.2 it never happened. Scenario: I have several projects: e.g.: 1) Back-office service and 2) User Interface The service project holds a number of utility classes used by other projects. If, from the UI project, I try to 'Add Import' a class in the other project, the corrupted import problem occurs. If I try to 'Add Import' to a class within the same project, it works. Hope this helps!
A quick note to mention that this behaviour wasn't a present nor a problem in 3.2 - it's new for 3.3. Does 3.3 use a new JDT lib or similar that precludes regression to the 3.2 code base for the offending code area?
A simple fix to comment out a line in AJCompilationUnitProbemFinder. I am attaching a patch.
Created attachment 101837 [details] Commented out 2 lines of AJCompilationUnitProblemFinder before commenting out, the method would always return null. Now it parses the compilation unit properly.
Created attachment 101838 [details] mylyn/context/zip
patch committed. iplog
