Community
Participate
Working Groups
N20080904-2000 API request: - ITypeParameter#getBoundsSignatures() // returns type signatures of the bounds - or ITypeParameter#getSignature() // returns type variable signature ITypeParameter currently only offers getBounds(), which returns only the name of a bound. For correctly rendering the type parameter in Java editor hovers, I need the complete signatures of the bounds, e.g. for: class MyList<Element extends Map<String, Integer>> { .. }, ... I'd like to display: 'Element extends Map<String, Integer> - pack.MyList' ... when you hover over 'Element'. The type parameter signatures are already available via ITypeParameter#getDeclaringMember() and then IMethod#getTypeParameterSignatures() or IType#getTypeParameterSignatures(), but this is inelegant, and IMethod#getTypeParameterSignatures() is even deprecated.
As a workaround, we currently have to rely on the deprecated org.eclipse.jdt.core.IMethod#getTypeParameterSignatures(), since the signatures of ITypeParameters on methods are otherwise not available.
Srikanth, this is important for UI rendering.
Jay, can you investigate this ? Thanks.
Let's try to get this in place for M6.
Created attachment 159088 [details] Proposed API Markus, Do you only want the API that returns the whole type parameter or also the API that returns signatures for individual bounds? The patch has both the APIs. Please let me know this satisfies your requirement.
I have no clear preference. For consistency with existing APIs, both are OK, since we already have precedents for both styles, e.g. IMethod#getSignature() and IType#getSuperInterfaceTypeSignatures(). We should only add one of the methods, though. Both methods would need some polish in the Javadocs, and getBoundsSignatures() needs to be plural.
Created attachment 159530 [details] Updated patch Updated the documentation and retained only org.eclipse.jdt.core.ITypeParameter#getBoundsSignatures() A note about the implementation: The current implementation takes the signature from the .class file directly for the binary members (type and method). But it uses org.eclipse.jdt.core.Signature to construct the signature from the individual bounds for the source members. While it makes sense to keep it consistent (and use org.eclipse.jdt.core.Signature to construct the signature) for both binary and source members, the bug 303270 does not allow us. Currently the bug 303270 manifests only for the source types and if we use Signature for binary members as well, it will break the existing behavior. Hence, two different codes for extracting the signature depending on whether it's binary or source.
(In reply to comment #7) > Created an attachment (id=159530) [details] [diff] > Updated patch The API looks good now.
Srikanth, would you have some time to review this patch, please?
Olivier, the bug 303270 was already existing with the older API that Markus mentioned in comment 1. Since I didn't want the API changes to be delayed, I captured it in another bug. I think this we can go ahead with this bug.
(In reply to comment #9) > Srikanth, would you have some time to review this patch, please? Patch looks good. Some comments: javadoc on org.eclipse.jdt.core.ITypeParameter.getBoundsSignatures(): - @return the signature for this formal type parameter should be @return the signatures for the bounds of this formal type parameter ?? - For consistency's sake we should say "if this element does not exist" (instead of "if this element doesn't exist") (compare javadoc on org.eclipse.jdt.core.ITypeParameter.getBounds()) - In org.eclipse.jdt.core.tests.model.CompilationUnitTests.testBug246594*() the assert messages are not appropriate (cut & paste ?) and need fixing.
(In reply to comment #10) > Olivier, the bug 303270 was already existing with the older API that Markus > mentioned in comment 1. Since I didn't want the API changes to be delayed, I > captured it in another bug. I think this we can go ahead with this bug. Yes, I don't think bug#303270 should be considered to be blocking the current enhancement.
Created attachment 160033 [details] Updated patch Incorporated the suggestions mentioned in comment # 11.
Released in HEAD for 3.6M6
Verified in HEAD and updated JDT UI to use the new API.
