Community
Participate
Working Groups
I20040506 I noticed that JavaSearchResult.isShownInEditor(...) populates the Java model because it uses getUnderlyingResource(). In this particular case, it should use getRessource() which is a handle-only method. In general, the SearchRequestor should not call anything than handle-only methods (see Java doc of these methods: if it doesn't say it is a handle-only method, it will populate the Java model). If you need to call non-handle-only methods (like IType.isClass()), JDT Core can surely provide an API on SearchMatch that will return the right answer.
how about getAncestor(COMPILATION_UNIT).getResource())? I need to know whether a java element is in a certain file.
As specified in the Java doc, both of these methods are handle-only, so they are ok to use.
fixed. Jerome, could you verify?
Nope, this is not what I want. What I need is the file that corresponds (i.e. if it's in a jar, I want null) to the CU or class file that contains the java element. I was thinking of getCorrespondingResource(), but that's not handle-only either. Any ideas?
I'm not sure I understand: you were using getUnderlyingResource() that returns null only for an external jar. Why do you need to have it return null for an internal jar now? Also getCorrespondingResource() and getUnderlyingResource() are equivalent for an ICompilationUnit.
Just trust me....No, it's because of bug 57036
If you need to handle the internal jar separately, then use getAncestor (IJavaElement.PACKAGE_FRAGMENT_ROOT), cast it to IPackageFragmentRoot, and use isArchive().
That's not handle only either, is it?
Actually it is. I'm fixing the spec (and I told you to read the spec :-)
now checking isArchive & otherwise using getResource().
So you never ask for IType.isClass() (to show the class icon) ?
Only in the label provider. If you're using the tree view, the java model doensn't get populated (and that's the scalable way to search). Otherwise, I don't see what I can do.
That's why I offered to add new APIs on the SearchMatch classes so that the label provider can ask the SearchMatch instead of the IJavaElement. I just need to know which ones. The rational is: we knew the answer to these questions when the SearchEngine found the matches. If we keep them on the search matches, it avoids to re- parse all matches.
I'm using the regular AppearanceAwareLabelProvider. As far as I'm concerned, they're using all kinds of non-handle info.
The problem I see is that we render the enclosing element not the search match itself. So putting this info onto the search match seems strange to me. So we would provide methods on search match that belong to an IJavaElement. Wouldn't it make more sense to have something like a IJavaElementInfo which contains this information. But as Thomas said this isn't an issue with the tree since we only populate the search model for those elements we render in the UI.
Instead of passing around an IJavaElementInfo, you could pass a SearchMatch. This is one level of indirection less. In the case of the flat hierarchy view, if you have 10,000 matches my concern was that you would render 10,000 elements. If you render only 5 (assuming that my list is 5 items high), then I'm happy.
JavaSearchResult.getFile(Object) still uses getUnderlyingResource()
No, if you have matches in 100000 elements, 100000 elements will be rendered (and therefore the java model populated). The workaround is to switch to the tree layout for large result sets. Changing that is way beyond a simple bug report (it will result in a loss of function). I changed the file adapter to not use getUnderlyingResource() anymore.
The original problem isn't fixed, you should *not* populate the JavaModel for free. This is a serious performance issue.
I cannot fix this PR without serious loss of function. Dirk, please advise.
To clarify, the problem isn't fixed because there is a workaround.
Switching to a non Java element based implementation requires: - full new rendering support for Java elements which aren't Java elements - unclear what happens to decorators (CVS, binary, ...) - action and action contributions via XML. If we don't have Java elements although we render them in the UI, actions contributed to Java elements will not show up in the search result view. A solution for this problem could be special IJavaElement. We could call them value elements. Those elements have enough information to be rendered in the UI but still implement IJavaElement. This is basically the same JDT/UI would have to do but would not require to double the whole rendering and action support story in the UI. Regarding 3.0: no further action is planned. We recommend using the tree view anyway and 2.1 had the same behaviour.
Fake elements would be highly dangerous to provide, as they could be used to feed subsequent APIs, and we'd have to add support wherever this could occur. Furthermore, this could be troublesome when dealing with true handle elements as well. This is a no go from our standpoint.
But you are requesting that we are going to implement those "fake" elements in the UI world which is harder for use to do than for you.
All I am asking is that you render search matches directly, and not elements. We could add more info to the search matches themselves, and/or some notion of groups. But we wouldn't go and reimplement true Java element variations which wouldn't be handle based. We don't want to deal with interactions between fake and true Java elements.
I don't think people will be happy if we remove the function from search and only render matches whithout relation to its container.
Search matches could carry all the information you need to perform the grouping. This information would however not be in the form of IJavaElement due to the reasons mentionned before.
If this elements are Java element then UI has to double all the code for rendering, label decoration and action management. Philippe, I don't think that doubling all that code is the right thing to do.
Right, but doubling the JavaModel just to deal with an implementation detail in search result view isn't an option either.
Another idea is to use the new virutal table support from SWT. That would mean that we only populate the Java Model with those elements that are visible. Unfortunatelly, JFace doesn't support SWT virtual tables yet. Following the path would avoid code doubling in both Java/Core and Java/UI.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
Fixing bug 90392 would also solve the issues in search since we would use the binding key to render the element in the UI instead of going for the Java element itself.
Bug 90392 is now fixed, but I believe you still need bug 90621 (storing the binding key in mementos) to be fixed.
Also note that some questions like isClass() will still have the cost of opening the Java element (the binding key in the resolved element doesn't have this information). Do you still need to answer such questions ? If you do, please enter a feature request to have this information returned in the SearchMatch.
Bug 90621 is necessary when we switch between search result sets and only for the element to be searched for. For rendering a single set, this is not necessary.
Jerome, we are not directly asking isClass. We are going through the flags. We need this information to render the correct icon (class, interface, enum or annotation) However I guess that this will open the element as well. Adding this information to the SearchMatch will currently not help. The reason is that the search view doesn't render matches, it renders Java elements as gouping elements. We do this since plug-ins wanted to add entries to the context menu and we don't have search match object for the grouping element. Before we add this information to the search match I first have to investigate if we can leverage this information and what this would mean for the overall architecture. Is the same true for the ITypes in a type hierarchy. There we access the flags as well to render the right icon. And we are
Yes, asking for the flags of the IType will open the Java element. For the hierarchy, ITypeHierarchy#getCachedFlags(IType) was added in 2.0 to handle the rendering of icon.
Martin enlighted this to me as well.
Martin I am handing this over to you. To basically be able to not resolve the Jave model we need more resolved information on the handles. I will leave it up to you to either close this one or to leave it open as a reminder.
I think the virtual table is the solution. Bug 84210.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
