Community
Participate
Working Groups
Given a file with two classes, the findType() method is apparently unable to locate the secondary type in a source file. For example: given the following, findType() will be able to find Foo, but not Bar. // Foo.java public class Foo { } class Bar { }
This utility is defined in UI land
Ignore my previous comment (wrong PR)
We always said that we shouldn't find secondary types in Java model, but it would be interesting to support in the end. Mostly since it is inconsistent with the builder result (you get errors in editor but nothing in the task list).
This searchable environment limitation has a few duplicate PRs, need to find them (under Later).
See SearchableEnvironment#findTypes(char[] prefix, final ISearchRequestor storage)
*** Bug 37897 has been marked as a duplicate of this bug. ***
*** Bug 38088 has been marked as a duplicate of this bug. ***
*** Bug 39191 has been marked as a duplicate of this bug. ***
*** Bug 45830 has been marked as a duplicate of this bug. ***
*** Bug 51029 has been marked as a duplicate of this bug. ***
*** Bug 51943 has been marked as a duplicate of this bug. ***
*** Bug 53597 has been marked as a duplicate of this bug. ***
*** Bug 55907 has been marked as a duplicate of this bug. ***
Will reconsider post 3.0
*** Bug 58418 has been marked as a duplicate of this bug. ***
Philippe, by post 3.0 could you mean 3.0.1 or 3.1? This sounds like it could be an invasive change that would not be appropriate for 3.0.1, but it has been a while since I last rooted around deep in the Java Model so maybe I am wrong on this. I was wondering because there is a good bit of interest in this bug.
Kent indicates that this can not happen for R3.0.1. Should be considered (at least) for R3.1
*** Bug 72179 has been marked as a duplicate of this bug. ***
Bug is still in 3.1 M4, will it be fixed in 3.1?
*** Bug 86613 has been marked as a duplicate of this bug. ***
*** Bug 95396 has been marked as a duplicate of this bug. ***
*** Bug 96400 has been marked as a duplicate of this bug. ***
*** Bug 103139 has been marked as a duplicate of this bug. ***
*** Bug 105183 has been marked as a duplicate of this bug. ***
Created attachment 25662 [details] Patch to fix this issue This patch is based on HEAD stream (ie. 3.2 dvpt code). It just activates sleeping code as secondary type indexing seems to have been implemented
Created attachment 25663 [details] Test cases added to ClassNameTests I've also modified test356 in ASTConverterTest and ASTConverterAST3Test which use secondary type.
Created attachment 25676 [details] Regression tests updated
Philippe, perhaps a good candidate for 3.1.1?
Created attachment 25752 [details] Tests to verify that there's no impact on performances Unfortunately, these tests show that previous patch strongly impact findType performances when searched type is unknown. Here are result without patch: Scenario 'FullSourceWorkspaceModelTests#testProjectFindType': - CPU Time: n=10, s=1090, av=109.0, dev=7.0 - Elapsed process: n=10, s=1182, av=118.0, dev=5.422176684690384 ------------------------------------------------------------------------ Scenario 'FullSourceWorkspaceModelTests#testProjectFindUnknownType': - CPU Time: n=10, s=1440, av=144.0, dev=12.806248474865697 - Elapsed process: n=10, s=4048, av=404.0, dev=46.04128582044598 ------------------------------------------------------------------------ Scenario 'FullSourceWorkspaceModelTests#testPerfSeekPackageFragments': - CPU Time: n=10, s=660, av=66.0, dev=11.135528725660043 - Elapsed process: n=10, s=759, av=75.0, dev=3.0166206257996713 and here are those with patch: Scenario 'FullSourceWorkspaceModelTests#testProjectFindType': - CPU Time: n=10, s=1030, av=103.0, dev=11.0 - Elapsed process: n=10, s=1173, av=117.0, dev=4.347413023856832 ------------------------------------------------------------------------ Scenario 'FullSourceWorkspaceModelTests#testProjectFindUnknownType': - CPU Time: n=10, s=1970, av=197.0, dev=25.317977802344327 - Elapsed process: n=10, s=5394, av=539.0, dev=87.23302127061747 ------------------------------------------------------------------------ Scenario 'FullSourceWorkspaceModelTests#testPerfSeekPackageFragments': - CPU Time: n=10, s=720, av=72.0, dev=7.483314773547883 - Elapsed process: n=10, s=823, av=82.0, dev=4.207136793592526 I've run this test only once, but result while trying to find an unknown type in project is too bad: 33% time increase for Elapsed process time (average goes from 404s to 539s!). So, it seems we have to find another better solution to fix this issue...
*** Bug 108088 has been marked as a duplicate of this bug. ***
*** Bug 22883 has been marked as a duplicate of this bug. ***
*** Bug 115639 has been marked as a duplicate of this bug. ***
Is performance in the case of searching for _unknown_ type really such an issue? My (wild) guess is that people (or compiler) typically search for types that _are_ there.
To clarify. The change being debated here only affects the compiler behavior when performing against the source model, which occurs in operations like reconcile, search, type hierarchies, codeassist, codeselect etc... all but build. The fix is located in the pluggable environment passed to the compiler, which wrappers the JavaModel. Adam - each new type is looked in many places before being found. We have to ping in all places designated by the imports, and this for any new type. Frederic identified a perf degradation of 2% which is too much by our standards. Always the quest for the ultimate solution...
Created attachment 30620 [details] Patch to (definitely) fix this issue This is a specific eclipse patch which includes 3 projects: - org.eclipse.jdt.core - org.eclipse.jdt.core.tests.model - org.eclipse.jdt.core.tests.performance This patch should be...no, IS the bug killer... All performance tests are good with it (e.g. either equals or sometimes better than with HEAD contents). Reconcile operation is no longer downsized by this test and same as for completion tests. Solution was to use a cache on JavaModelManager per project information. Secondary types are searched the first time using a specific BasicSearchEngine request and corresponding IType stored in the cache. Then, after the consumed time is only to look in maps to retrieve the key. Cache size is currently not considered as a potential problem due to the fact that secondary types number should not be too big. Cache is reset each time a secondary type entry is added to the index and type is removed from cache each time its file is deleted.
Patch released in HEAD (commented code removed).
Verified for 3.2 M4 using build I20051213-0010
*** Bug 130926 has been marked as a duplicate of this bug. ***
*** Bug 87063 has been marked as a duplicate of this bug. ***
*** Bug 98505 has been marked as a duplicate of this bug. ***
*** Bug 81744 has been marked as a duplicate of this bug. ***
*** Bug 32505 has been marked as a duplicate of this bug. ***
I'm seeing the same problem in Eclipse SDK 3.3.1.1 (JDT 3.3.1.r331_v20070629-7o7jE72EDlXAbqAcnbmyg1rf8RIL). Curiously, it seems to only affect one particular non-public class; I have lots of other non-public classes in the same (default) package for which there are no complaints. In what version is this bug fix supposed to be released?
(In reply to comment #43) > I'm seeing the same problem in Eclipse SDK 3.3.1.1 (JDT > 3.3.1.r331_v20070629-7o7jE72EDlXAbqAcnbmyg1rf8RIL). Curiously, it seems to > only affect one particular non-public class; I have lots of other non-public > classes in the same (default) package for which there are no complaints. In > what version is this bug fix supposed to be released? > 3.2, so it should not longer occur. Please open a new bug with a small test case to reproduce your issue, thanks
Actually, I still see this bug in Eclipse Juno. Version after version of Eclipse, I hope to see it fixed, but it is still there. It seems difficult to make a small project reproducing the problem, as it might appear only in a large project: the behavior appears mostly after having started a fresh Eclipse on such project, and going for the first time to these classes. I will try and describe it (as it appears in our code base) as precisely as I can in the hope to give a hint about this issue. As I wrote, we have a rather large code base (around one million of lines of code). In the cases where we see the bug, we have a public abstract base class, and several package protected small classes extending the base class. We don't want to put each class in its own file, as it is convenient to have them grouped logically in the same file, and, well, Java allows it, the Eclipse compiler understands it, so why the editor cannot take it in account? What we see: we open a class using such small package protected class, the used type is highlighted as unknown ("XxxXxx cannot be resolved to a type"). The quick fixes include: "Import 'XxxXxx' (package.where.we.are)"... When we hit F3 on the class, it doesn't move. I can open the class marked as missing with Ctrl+Shift+T (Open Type). Back to the other class, it is still seen as unknown. I have to check out the file and edit it (just a new line is enough) to get the editor to kick in and finally remove the error mark... I made a small project (trivial, as described above, I can join it if needed) trying to reproduce the conditions of the bug. I closed the tab of the classes and restarted Juno. No problems. I closed the project and restarted Juno. No problems. I cleaned, then closed the project, and restarted Juno after marking the classes as read-only (like Perforce does when a file is versioned and not checked out). No problems either. So trivial cases are correctly handled, the problem seems to appear only in complex projects, perhaps We have this problem in at least two cases: in one, the abstract class is package protected, in the other it is public. In one, the package protected classes are final, in the other they are not. Note that I would be happy with just an interactive solution, allowing to recognize the missing class without having to edit the file where it is used...
Note that this fix was revised with bug 118789. To sum up: If you need secondary types, you have to use one of the JavaProject#findType(*, IProgressMonitor) methods. (In reply to comment #45) I'm not sure that's really this bug. Did you debug it and see that findType() returned a wrong result? Your description does sound like a bug, but I'm afraid we can't do much without steps to reproduce.
(In reply to comment #46) > (In reply to comment #45) > I'm not sure that's really this bug. Did you debug it and see that > findType() returned a wrong result? Your description does sound like a bug, > but I'm afraid we can't do much without steps to reproduce. Honestly, I am not sure either. I went straight there from bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=38088 (top result of my search) which is marked as duplicate of this one. As are many other bugs, apparently... I thought I should mention it here instead of in a sub-branch. But I have no idea of what is JavaProject.findType(), I am just a user of the IDE, not a hacker of Eclipse. Alas, I am aware that this bug is hard to reproduce, and thus even harder to fix. I just wanted to provide some additional information from our case. For what it is worth (not much), my attempt to reproduce the bug is at http://bazaar.launchpad.net/~philho/+junk/Java/files/head:/Tests/src/org/philhosoft/tests/bugs/eclipse/package_protected/ but as said, the example is too simple to trigger the issue.
I fixed the inverse problem, that is deleted types still show up in some circumstances : bug 421902
