Community
Participate
Working Groups
Build Identifier: 20100506-2000 In general call hierarchy results differs from Galileo's (build id: 20100218-1602) and seems to be broken. It looks like search scope 'workspace' works like 'project'. Example: there are 3 projects in workspace 'common', 'client', 'server'. In 'common' there is interface named 'Repo' that contains method 'find'. Both 'client' and 'server' projects include 'common' in classpath and contain accordingly implementations 'ClientRepo' and 'ServerRepo'. Also there are some classes in both client and server projects that calls method 'find' of interface 'Repo' , let's name theses classes them 'ClientCaller' and 'ServerCaller'. Now call hierarchy for method 'find' in any of 'Repo' implementation classes with search scope 'workspace' shows only callers from the same module (as if search scope was 'project'), but it's expected to show both calls in client and server projects. Galileo shows both calls as expected. Reproducible: Always Steps to Reproduce: 1. Import example projects from attached archived workspace. 2. Get call hierarchy of method ClientRepo.find() 3. Check that only 1 of 2 calls found in workspace.
Created attachment 169286 [details] example projects
Created attachment 169287 [details] call hierarchy in 3.5
Created attachment 169288 [details] call hierarchy in 3.6
Created attachment 169289 [details] example projects layout
In 3.6, only the dependent projects/jars are being searched when the particular Java element is specified. In your workspace, the ServerRepo's find() cannot be called by the client because there is no dependency between them. However, search on common's find returns both the client and server.
Are you sure that your projects have been built correctly? Could you reproduce if you clean these 3 projects? Note that since bug 102279 has been fixed, when the General>Workspace preference 'Build automatically' is checked, search engine uses the build state to look only at possible dependencies to reduce the number of projects and libraries injected in the scope. Hence if, for an unknown reason, your build state is not up-to-date, then the search results might be affected the way you're currently describing...
(In reply to comment #6) Frederic, I've just tried to turn off 'Build Automatically' option and call hierarchy started to work as expected - it showed 2 calls. When I turned on auto build again - it showed 1 call. I tried to turn on/off autobuild several times and it is always reproducible.
Satyam, please investigate.
Created attachment 169357 [details] patch to demonstrate the problem Subtypes also should probably be taken care of. This patch takes care of that and I have added just to demonstrate the problem. I will submit a proper patch.
Created attachment 169472 [details] Proposed patch In this patch, projects even referring to any super types declaring the searched method are also being include for the search.
Frederic, Can you review the proposed patch? Do you think we should put this in 3.6RC3? Thanks, Satyam.
I tried searching (ListEditor#getShell()) as mentioned in 102279 and don't see any noticeable performance degradation.
(In reply to comment #11) > Frederic, > Can you review the proposed patch? Do you think we should put this in 3.6RC3? > > Thanks, > Satyam. Patch looks good, but I want you to optimize a little bit the new method getQualifiedNames(ObjectVector) added to IndexSelector: 1) Take the good inhabit not to use a qualified field in the for loop test, instead create a local variable for types.size and use it. Note also that you already use this field to initialize the focusesQualifiedNames, hence it would be also good for this access. 2) I think we can avoid to create an array of a single char[][] while calling ReferenceCollection.internQualifiedNames. Instead I would prefer to call this method only once with the whole qualified names. I know there would be a problem with WellKnownNames, but I think we can modify ReferenceCollection to avoid this issue. Otherwise, I do not think this is a candidate for RC3. There's a possible workaround by unchecking the automatic build, hence I'd rather prefer to see this fixed for 3.6.1. Olivier, do you agree?
Created attachment 169492 [details] Proposed patch Incorporated Frederic's review comments - Frederic, Please look at these changes and let me know if this is what you were telling.
(In reply to comment #13) > Otherwise, I do not think this is a candidate for RC3. There's a possible > workaround by unchecking the automatic build, hence I'd rather prefer to see > this fixed for 3.6.1. I agree with this. We can fix this in 3.6.1
Guys, I strongly believe that this fix is vital for Eclipse/JDT usability. This bug makes JDT unusable in any real-world project where concrete implementation of some API is defined not at compile time, but explicitly at runtime (e.g. dependency injection). An example I've provided was synthetic one, a real-world example is the project where database access API is isolated and exposed by project like "db-api" and there are several implementation like "db-impl-mysql", "db-impl-oracle", etc. The main project "app-core" depends only on API exposed by "db-api". Thus there is no compile-time dependency between "app-core" and any of db API implementation modules. Concrete implementation of API that is used at runtime may be defined via dependency injection, e.g. Spring, or any other configuration approach, e.g. while building several distributions of the application - "app-mysql", "app-oracle", etc. "Workaround" is only a name - it forces you to give up one of the most useful features - continuous automatic build. I hope you will revise your decision to postpone this fix. Many thanks.
(In reply to comment #16) > Guys, > > I strongly believe that this fix is vital for Eclipse/JDT usability. This bug > makes JDT unusable in any real-world project where concrete implementation of > some API is defined not at compile time, but explicitly at runtime (e.g. > dependency injection). > > An example I've provided was synthetic one, a real-world example is the project > where database access API is isolated and exposed by project like "db-api" and > there are several implementation like "db-impl-mysql", "db-impl-oracle", etc. > The main project "app-core" depends only on API exposed by "db-api". Thus there > is no compile-time dependency between "app-core" and any of db API > implementation modules. Concrete implementation of API that is used at runtime > may be defined via dependency injection, e.g. Spring, or any other > configuration approach, e.g. while building several distributions of the > application - "app-mysql", "app-oracle", etc. > Sorry, but I do not think this is related or I have not really understand your point here. Search Engine only knows the compile time dependencies. It has no way to find matches when a dependency is set at runtime and fixing this bug will not change this point. > "Workaround" is only a name - it forces you to give up one of the most useful > features - continuous automatic build. > I agree this is annoying. Workaround just says that there's a way to avoid the problem. I had never pretended this was the best solution. > I hope you will revise your decision to postpone this fix. > I'm definitely sorry, but your answer comes 6 days after my proposal to put this in 3.6.1 and unfortunately RC3 is now closed for us. That means now only blocking bugs could be fixed for 3.6.0 which is not the case of this one. We just ask you to uncheck the automatic build preference when doing this search, not all the time. Again, I agree it may be a little bit painful, but from JDT/Core perspective, it's definitely more acceptable than taking the risk to break the entire Search Engine with an uncontrolled side effect if we introduced such a change 5 days before the final release delivery. Note that 3.6.1 maintenance builds should start at the beginning of July and I can ensure you that the fix will be in the first one. So, it's just a matter of a couple of weeks to use the proposed workaround. > Many thanks. Thanks for your understanding
(In reply to comment #17) [...] > I'm definitely sorry, but your answer comes 6 days after my proposal to put > this in 3.6.1 and unfortunately RC3 is now closed for us. Olivier, I think this is a regression relative to 3.5 and should be fixed in 3.6.1, do you agree ?
(In reply to comment #18) > Olivier, I think this is a regression relative to 3.5 and should be fixed > in 3.6.1, do you agree ? If this is a regression, then yes, it has to be fixed for 3.6.1.
(In reply to comment #14) > Created an attachment (id=169492) [details] > Proposed patch > > Incorporated Frederic's review comments - Frederic, Please look at these > changes and let me know if this is what you were telling. Patch looks good, however, some remarks about it: 1) In ReferenceCollection: a) I'd rather prefer to change the signature instead of adding a new method. This would avoid to have an additional method call for existing callers. b) I'd rather prefer to have a positive boolean in the loop, hence the signature would be: internQualifiedNames(char[][][] qualifiedNames, boolean keepWellKnown) and the test would become: if (CharOperation.equals(qualifiedName, wellKnownName)) { if (keepWellKnown) { keepers[index++] = wellKnownName; } continue next; 2) IndexSelector: } I think getQualifiedNames(ObjectVector types) should return null when no focus qualified names are found. Then, it's clear that the builder state cannot be used and a "normal" indexes selection will occur...
Created attachment 172869 [details] Patch for 3.6 Maintenance Incorporated Frederic's comments.
Released to HEAD and 3.6 Maintenance branch
Released the test JavaSearchBugsTests#testBug313668()
The whiteboard status is necessary only when different than the target. Hence, in this case, it's necessary for the 3.7M1 verification process...
Frédéric, please update the review flag.
Verified for 3.7M1 using build I20100802-1800.
*** Bug 318885 has been marked as a duplicate of this bug. ***
