Community
Participate
Working Groups
After upgrading from 2.1 M3 to RC1, the "organise imports" feature has stopped adding required imports like it used to. I now have to use the explicit "add import" feature. I'm not sure if this is a bug or a deliberate change.
hmm, works sometimes, but not at others.... closing bug until I can reproduce predictably.
There's definately a problem here. I'm finding this very hard to reproduce in a test case, but the "organise imports" function is behaving unpredictably ever since going from M3 to RC1. If I take one of my classes and delete all the imports, then hit CTRL-O, then some imports get added OK, some type names which occur in more than one package get the wrong import added, and some don't get added at all - I have to add them explicitly with CTRL-A. I can't see any pattern as to why some work and some don't, nor can I reproduce it in a standalone test case.
Kenny, we had some problems with the indexer which lead to missing types when upgrading the workspace. This can result in the described behaviour since organize imports can't find out that the identifier is a type. Can you please do the following: - shut down eclipse - go to your workspace into .metadata\.plugins\org.eclipse.jdt.core - delete all *.index files and the savedIndexNames.txt - restart eclipse. This will take a while since the indexes are regenerated. Let me know if this works
That seems to have made some difference, but it hasn't fixed the problem completely. For example, it now picks up some imports which were not being found before, but it's still missing some others. Also, in one case, it's picking up one type but not another, even though those two types are in the same package and same JAR file. Those index files sure are big.... 10MB of them :-/
Kenny, best would be to have a reproducable case, since we don't see the problem. Is it possible to get your workspace ?
Martin, any comments ?
I have not observed any problems with organize import. But as sayd, it is highly dependend on the index, so I suspect some issues there. If you find again a problematic case, please open the 'all types' dialog to see if the missing type is there. If not, file against jdt.core
Sorry, which "all types" dialog is this? I've been trying to narrow this problem down further, by creating new files in the problematic project, but it only seems to occur under a combination of factors, the pattern of which I can't nail down. The same types will be imported fine in one java file, while not being imported in another. It's very frustrating, but I'm not sure what yo do about it. I'd be happy to let this bug lapse for now, and I'll re-open it at a later date if I have more info.
All types dialog is the Open Type dialog. It contains all types visible in the worksapce.
Kenny, any help that you provide to nail this down is appreciated. Although it seems to be a "rare" case we should try to fix it.
OK, according to the "open types" dialog, the types ARE there. They're just not being imported. What I'm doing is getting an existing class from my project which has about 2 dozen imports. Some of these are imported from the project code, some from JAR files, and some from the JRE. I delete those imports, hit CTRL-O, and some are successfully re-added, but about a third of them aren't. Also, I've just noticed that some of the error messages that have appeared in this file make no sense. For example, I have a method call which is taking an Object argument, but the compiler's saying that the argument is a char - which is isn't. Could this be further corruption of the sumbol tables? Are there any other index files, in addition to the index files mentioned earlier? I deleted those ones earlier, but to no real effect. I'll try doing a fresh grab of the code from CVS into a new project and see if the problem persists.
No joy :-( I built a new project from the CVS sources, took the same class as before, deleted the imports, did CTRL-O, and I get a similar problem, except it's having problems with different types this time. As an example, my project has four different classes all called Policy. 3 of them are from various JAR files, one is in the project source (and is the one I want in this case). CTRL-O throws up a dialog, which contains only 2 of the Policy types, neither of which is the one I want. If I put the cursor over the reference and hit CTRL-M, I get offered all four. Similarly, if I hit CTRL-1, I get all four again. But CTRL-O gives me only two. I'm afraid I can't give you access to the project, but it does seem to be a pretty clear fault. If CTRL-O, CTRL-M and CTRL-1 all gave me the same answer, I'd be inclined to to think it was something I'd done, but this inconsistency is concerning.
Martin, as far as I know the types returns from Ctrl+1 are resolve by JDT/Core whereas Ctrl+O uses the AST. What technique is used for Ctrl+M ? May be the problem is the name look-up environment. AST and compiler uses different name lookup environments.
Kenny, do you have CVS decorators on ? If so can you turn them off and restart your workspace.
CTRL + 1 uses code assist CTRL + M uses code resolve CTRL + O uses when the code can resolve: the ast bindings when the coe can not resolve the all types cache (same cache that the open type uses, but only for types in the scope of the current project) The inconsistency is really concerning. It seems to be a JCore bug. Are you using advanced features like - exclusion filters on classpath entries - nested source folders ?
Nope, not using anything like that. I have a single src folder and a basic list of JARs and ZIPs in the classpath. You said that CTRL-O uses the all types cache if it can't resolve. But the all types cache DOES list the correct types. So does this imply that it's using the AST (whatever that is), but resolving incorrectly? As for the suggestion about the label decorations, that'll have to wait until Monday.
There are two mode of organize import: a.) When the file can resolve completly (no imports missing) and you activate organize imports: The bindings in the AST are used. b.) If you first remove the imports by hand and then do organize import: The type cache is used. Do you have several projects? How are the JAR's added to the classpath. As external JAR, as Variables?
Yes, I have three projects, all different CVS branches of the same thing. The JARs are all under the lib directory of the project tree, so they're added using the "Add JAR" button of the Java Build Path dialog. No external JARs are used, and no variables are used (or, at least, none that I've added or changed from the default)
Dirk, I turned CVS label decorations off, restarted, but the problem persists. However, it does seem to be having trouble with different types than before, although that may be coincidental.
Can I just add that I have just found some incosistant behaviour. There was a java file with reference to a Class which is defined in a different project. When I pressed Ctrl+1 the import did show up. However when I pressed Ctrl+Shift+O that import didn't show up in the pop up.
we found a major bug in the alltypes cache that I think explains what you have seen. The fix is in RC3a. Can you please check if this fix eliminated your problem? If not please reopen. related bug is bug 35291
Excellent, that seems to have fixed the problem for me. Thanks, Martin & co.
