Eclipse Community Forums: Java Development Tools (JDT) » Java search (was Re: jEdit/Eclipse Interface Tools)

Home » Language IDEs » Java Development Tools (JDT) » Java search (was Re: jEdit/Eclipse Interface Tools)(Java search)

Show: Today's Messages :: Show Polls :: Message Navigator

Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749014]

Thu, 01 December 2016 07:42

Ed Willink

Messages: 7674
Registered: July 2009

Senior Member

Hi

A search that I trust and understand would be good. I'm afraid that I use Java search very sparingly since I do not understand it. It variously returns far too much or far too little. I raised a Bugzilla a while back about the scope of Project search and just got a response that I should use Hierarchy. But I remain confused. I often resort to File search.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=440203#c3

For instance, if I select a use of the org.eclipse.ocl.pivot.TypedElement.getType() operation, and then Find References, I want all references to my getType(). I am not interested in references from org.eclipse.jdt.internal.corext.dom.ASTFlattener to org.eclipse.jdt.core.dom.AnnotationTypeMemberDeclaration.getType(), which obviously cannot reference the selected getType(). JDT is actually doing a File Search. But I do not see references to org.eclipse.uml2.uml.TypedElement.getType(), so it is an incomplete File Search. Useful when you get the hit that you want but not to be trusted for definitive results.

The only search that I find really reliable is to corrupt the spelling/signature of the search target and then look for the compilation errors that result.

Regards

Ed Willink

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749250 is a reply to message #1749014]

Sun, 04 December 2016 11:52

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

If correctness of search results is the issue (rather than usability of search functionality), then my guess is: we should put our money on the integration of the new JDT index, which also promises better detection/recovery of corrupt indices.

Regarding bug 440203: is it clearer given the updated documentation from http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=4797736bbc9ca71fb795ccd49dda3217e53e9476 ?

Good to know, that at least the compiler works reliably Wink

Stephan

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749269 is a reply to message #1749014]

Mon, 05 December 2016 00:58

David Wegener

Messages: 1445
Registered: July 2009

Senior Member

If you are interested in finding all the callers of your method, then you might want to try the Open Call Hierarchy option from the context menu. Highlight the method, right click and select Open Call Hierarchy from the menu. This will provide a list of all callers of your method. It shouldn't include calls to any like named method in a different class.

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749304 is a reply to message #1749269]

Mon, 05 December 2016 09:41

Ed Willink

Messages: 7674
Registered: July 2009

Senior Member

Hi

@David: Thanks. IIRC , I tried Open Call Hierarchy many years go and didn't like it. Tried again it's slow, but provides a much more comprehensive list than Java Search. Unfortunately the hits are not sorted by package making it very difficult to triage the hits by their 'component'.

@Stephan. The documentation may be more accurate and so helpful in some sense, but not to me. If anything it helps explain why field searches are useless.

My expectation is that when I search for references to some declaration I get all the references to that declaration.

Since there may be too many references, I expect Workspace to do no filtering. Project to select only hits in the same project as the declaration. Similarly WorkingSet only hits in the Working Set.

To me 'hierarchy' is cleverer, so it searches up the class hierarchy to find the base declaration of the selected declaration, and then return hits on the base declaration. This is orthogonal to Project/Workspace/WorkingSet so for consistency we would actually need

Find Base References->Project/WorkingSet/Workspace
Find Declared References->Project/WorkingSet/Workspace

But what use is "Find Declared References". It just filters out polymorphic calls that may occur via base classes giving deceptive results. Hence my expectation that

Find References->Project/WorkingSet/Workspace

is all that I need.

On no account is the class of the declaration ignored. If you want to do that it should be

Find Synonym References->Project/WorkingSet/Workspace

Regards

Ed Willink

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749343 is a reply to message #1749304]

Mon, 05 December 2016 17:06

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Ed Willink wrote on Mon, 05 December 2016 10:41

My expectation is that when I search for references to some declaration I get all the references to that declaration.

Wait, the bug you referenced talks about find declarations, not find references. Are we on the same page?

Stephan

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749384 is a reply to message #1749343]

Tue, 06 December 2016 07:11

Ed Willink

Messages: 7674
Registered: July 2009

Senior Member

Hi Stephan

I've raised Bugzillas against both Find References [1] and Find Declarations [2] in the hope that they might behave in what I perceive to be a much more predictable fashion. Since both seem to suffer from missing and excess results, I may sometimes confuse my responses. Apologies if I have confused you, but I suspect that much of the problem is common to both searches.

Regards

Ed Willink

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=430515
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=440203

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749630 is a reply to message #1749384]

Thu, 08 December 2016 18:10

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Ed Willink wrote on Tue, 06 December 2016 08:11

... I suspect that much of the problem is common to both searches.

So far I see no indication for that. In particular, in one case I saw you complaining about too many search hits, which I understood to be a usability issue (the one to be clarified via documentation update). That's a different animal from search *not* finding some references. The former is about match logic, the latter more likely about an incomplete index.

Stephan

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1749719 is a reply to message #1749630]

Sat, 10 December 2016 06:15

David Wegener

Messages: 1445
Registered: July 2009

Senior Member

You might want to check out this thread in the Newcomers forum:
https://www.eclipse.org/forums/index.php?t=msg&th=1083021&goto=1749569&#msg_1749569

It references the filters entries in the Search View's menu. There is a filter to show potential matches. Is this causing the excess search results to be shown in your workspace?

Report message to a moderator

Re: Java search (was Re: jEdit/Eclipse Interface Tools) [message #1750156 is a reply to message #1749719]

Fri, 16 December 2016 14:12

Ed Willink

Messages: 7674
Registered: July 2009

Senior Member

Hi

Just revisited this using M4.

@David: I just discovered the "Potential Matches" option. No it was not selected.

@Stephan: I tried menu finds on a method in an EMF base class and one of its derived classes

void ShadowExpCS::setValue(String value);

Declarations in Workspace: 94 (3 correct, 91 spurious)
Declarations in Project: 57 (3 correct, 54 spurious)
Declarations in Hierarchy: 3 (3 correct)
References in Workspace: 13 (5 correct, 8 spurious)
References in Project: 8 (5 correct, 3 spurious)
References in Hierarchy: 5 (5 correct)

void ShadowExpCSImpl::setValue(String value);

Declarations in Workspace: 94 (3 correct, 91 spurious)
Declarations in Project: 57 (3 correct, 54 spurious)
Declarations in Hierarchy: 2 (2 correct, 1 missing)
References in Workspace: 10 (2 correct, 3 missing, 8 spurious)
References in Project: 5 (2 correct, 3 missing, 3 spurious)
References in Hierarchy: 2 (2 correct, 3 missing)

Regards

Ed Willink

Report message to a moderator

Previous Topic:	Pattern for annotation based null analysis and GUI programming
Next Topic:	Null annotation with generated code

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Oct 05 03:45:23 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter