Community
Participate
Working Groups
M6 With 5.0 rendering Java elements in the UI which have type arguments (types and methods) requires "opening" the element to access the type argument information. JDT/UI first tries to use the information provided by the resolved binding key (e.g. method getKey()) to render this information. However, the elements are most of the time unresolved. Especially in type hieraries and search where a lot of Java elements are created providing this information will speed-up rendering these elements in the UI.
"Opening" the Java element is even required to find out if a element has type parameters.
Changed HierarchyResolver to create resolved handles from the reference bindings. Changed TypeHierarchyTests and HierarchyOnWorkingCopiesTests to show resolved handles in the hierarchies.
Jerome, does this already include that we transparently get the information through the get methods on IJavaElement.
Not yet. See bug 90778.
Changed search to create resolved elements too. Search tests remain unchanged as they use a custom print of the returned Java elements.
Reopening. Due to element handle lifecycles, it may be dangereous to cache this information inside the handles directly. Handles could become obsoleted along type hierarchie existence, or search match; and clients would be fooled by obsolete information cached onto stale element handles. Cached information should go directly into type hierarchy and/or search match objects, since the cached information is intimately tied with the lifecycle of these entities.
This requires PMC approval to proceed to changes within M7
We want to add the following API on ITypeHierarchy: /** * Returns the type parameters associated with the given type * (would be equivalent to <code>IType#getTypeParameters()</code>), * or <code>null</code> if this information wasn't cached on the hierarchy * during its computation. * * @param type the given type * @return the cached type parameters for this type * @see ITypeParameter * @since 3.1 */ ITypeParameter[] getCachedTypeParameters(IType type);
Ideally we would add the same kind of information on SearchMatch. However since the default for the search view is the hierarchical mode, it is unclear if the performance gain would be worth it.
Another approach is to ignore the binding key in JDT Core (i.e. we behave as if it was an unresolved handle), and let the client use the binding key. This means that we need to store the flags inside the binding key, and add a new API on BindingKey to retrieve the flags. Note this would be useful for search only (as the type hierarchy already caches these flags).
Invastigating how to speed up search result rendering, it looks like it is going to be more work than adding the flags in the binding key and adding a new API on BindingKey. When a search result is displayed, at least the following APIs are called (which causes opening of Java elements): - IMethod#getFlags() - IMethod#exists() - IMethod#isConstructor() - IType#getTypeParameters() - IMethod#getDeclaringType()#isEnum() (this one is problematic as the declaring type of a resolved method is not resolved for now).
Jerome, thanks for the info. I will look into why we call IMethod#getDeclaringType()#isEnum().
We call IMethod#getDeclaringType()#isEnum() to render a private icon for the constrcutor if flags say that it has default visibility. First we can change the && to first check if it has default visibility and then ask for isEnum. Jerome, the flags in the bindings are these preceise (e.g. compiler flags) or source flags. So for enum EE { EE() { } } will the flags tell us that foo has default visibility or is private.
wanted to say that EE has default visibility or is private
The flags will be the compiler binding flags, so it will tell you if EE has default visibility or is private.
OK. If the flags are preceise then we don't have to reach to the declaring type of a method or field to decide on its icon. We simply use the flags. I looked into bet implementing this an instead of mangling it into the current Label provide I will create a new one that works on the binding key (like we have one for IBinding).
Jerome, can you imagine how the new API would look like on binding key. Then I can start looking at what it means to implement the label provider.
I think it would be BindingKey#getFlags() and would return an int (that you can decode using the Flags class).
Internal support released, but it is currently turned off. To turn it on, change Binding#USE_ACCESS_FLAGS_IN_BINDING_KEY to true.
To summarize, the folling new APIs would be needed by JDT UI: - BindingKey#getFlags() - BindingKey#isConstructor()
Still waiting on PMC approval on this API addition.
apologies, but this looked like work in progress the last time I've looked. To summarize you are looking for approval for: Additions to BindingKey: - BindingKey#getFlags() - BindingKey#isConstructor() Additions to ITypeHierarchy: ITypeParameter[] getCachedTypeParameters(IType type);
The additions from comment #22 are approved
Sorry for the confusion Erich. We actually only need: - BindingKey#getFlags() - BindingKey#isConstructor() I'm adding these APIs right now.
Added the 2 APIs. Added corresponding tests BindingKeyTests#test034() to test037().
After more discussions with JDT/UI, we came to conclusion that these additions are not suitable; since it may cache element structural information into keys, leaving clients with difficult decisions as to whether to trust the key or the element. The only interest for having it on the key is to cache some information avoiding populating the model, and is not mandated by the normal binding key contract, i.e. identify uniquely a type binding. Therefore, it should not be added. If such information was requested again, it should end up in a different spot. Something we could imagine post 3.1 is to precache this information directly into Java elements (pre/partially initialized element infos), and hiding the complexity to clients who could blindly trust the elements to reflect reality.
Removed the 2 APIs and corresponding tests.
