JDK-6557966 : Multiple upper bounds of the TypeVariable
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.lang.model
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-05-16
  • Updated: 2017-05-16
  • Resolved: 2013-11-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b119Fixed
Related Reports
Relates :  
JDK-8027730 - Fix release-8 type visitors to support intersection types
Description
From: 	Jan Lahoda <###@###.###>

I have a question regarding 
javax.lang.model.type.TypeVariable.getUpperBound(): it says that if 
there are multiple upper bounds specified, the result is DeclaredType 
which Types.directSupertypes are the specified bounds. But, is there is 
way to detect if the returned DeclaredType is such a compound type (so 
that I should call directSupertypes to find out the correct bounds)?
I think we need a Types.isCompound method.
Comments
Release team: Approved for fixing
19-11-2013
8-critical-request justification: This fix adjusts the javax.lang.model.** API with regard to IntersectionType introduced in 8. As an API change, it should be included in 8. The fix has two parts: 1. javadoc adjustment 2. change in behavior of IntersectionType.accept: currently, IntersectionType.accept calls TypeVisitor.visitDeclared for intersection types returned by TypeVariable.getUpperBound, and calls TypeVisitor.visitIntersection for other intersection types. This is inconsistent with the type hierarchy (IntersectionType does not extend DeclaredType) and with the general behavior of the TypeVisitor. After the proposed patch, IntersectionType.accept always calls TypeVisitor.visitIntersection. Risk Assessment: Low risk. The javadoc part of the fix basically documents the current state. The IntersectionType.accept part affects only types returned from TypeVariable.getUpperBound for a type variable with multiple bounds. The relevant usages of TypeVariable.getUpperBound are believed to be relatively uncommon. Level of testing coverage: Bootcycle JDK build, JCK tests, langtools jtreg tests ran. Looked at relevant NetBeans usages (as NetBeans is a significant user of javax.lang.model.** API), and in the qualitas corpus. Size of fix: ~200 LOC (including test), 3 files with updated javadoc, 2 files with code changes, 1 test changed. Patch: http://cr.openjdk.java.net/~jlahoda/6557966/webrev.00/
18-11-2013
Jon, I'm giving this one to you - I submitted a review in Crucible - but never had a chance to sit with Joe and go through that one. If you like the work, you could discuss with Joe about how it can be refined; but feel free to defer if you feel it's too fuzzy (it's a P5 after all)
23-08-2013
WORK AROUND Look for empty name in the element associated with the returned bound.
02-03-2011
EVALUATION This seems to point at the lack of support for intersection types in 199 API. Javac internally uses class types in order to represent intersection types, and it seems like in this case, the javac choice is spilling out in the API. Since an intersection type is 'just' a standard class type, the user has no way to tell as to whether the returned bound type is an intersection type or not (perhaps the only way to tell is to check as to whether the name of the classtype is empty - but this is an hack). We could easily add Types/DeclaredType.isCompound - or, another, better solution would be to add another subtype of ReferenceType called IntersectionType with a method to get all the bounds. This would mean that TypeVariable.getUpperBound would return a TypeMirror (no change needed in the API) - and not a DeclaredType as stated in the javadoc. Note that the latter solution might be harder to implement due to the fact that javac's ClassType implements DeclaredType - and also that javac's TypeVar.getUpperBound is used extensively throughout javac (so that it will be hard to change the behavior of this method i.e. by making it to return a custom subclass of type - unrelated to ClassType - w/o breaking javac itself).
02-03-2011
EVALUATION Will consider.
16-05-2007