-
Bug
-
Resolution: Fixed
-
P2
-
5.0
-
b51
-
generic
-
generic
The standard doclet incorrectly handles substituted type parameters in a few places. Here are some notes from Scott:
1. Top-level heading ("Class AbstractList<E>"):
Leave as is.
2. "All Implemented Interfaces:"
Include the substituted type parameters (so Iterable<E> not Iterable<T>).
The doclet shouldn't do the hard work to make those substitutions happen:
it needs support from the doclet API.
3. Class hierarchy diagram:
Same as #3.
4. "Direct Known Subclasses:"
Omit the type parameters. They're unbound, and so are just confusing.
This is inconsistent visually with #2 and #3, but that's OK.
The same goes for "All Known Implementing Classes".
5. "Specified by:"
Not necessary to include the type parameters, since they'll be available
up top in the "All Implemented Interfaces" section. But it should be
easy for the doclet to match up an interface name with the appropriate
type parameters, in which case they'd be very nice to have. I'd say go
for it.
6. "Overrides:"
Not necessary but nice to have, as with #5. Unlike #5 there is already
support in the doclet API for getting the type parameters. However,
until #5 includes type parameters, I wonder if showing them
here seems too inconsistent (I could go either way on this).
In the cases where type parameter information is desired but not yet
available to the doclet, for the initial putback I strongly recommend
omitting the parameters rather than showing the wrong thing. We'll
hope to get permission to add the new functionality later. This applies
to items #2 and #3, and optionally to #5 and #6.
Do not fix this bug until 4922918 is fixed. That's the bug for the required doclet API changes.
1. Top-level heading ("Class AbstractList<E>"):
Leave as is.
2. "All Implemented Interfaces:"
Include the substituted type parameters (so Iterable<E> not Iterable<T>).
The doclet shouldn't do the hard work to make those substitutions happen:
it needs support from the doclet API.
3. Class hierarchy diagram:
Same as #3.
4. "Direct Known Subclasses:"
Omit the type parameters. They're unbound, and so are just confusing.
This is inconsistent visually with #2 and #3, but that's OK.
The same goes for "All Known Implementing Classes".
5. "Specified by:"
Not necessary to include the type parameters, since they'll be available
up top in the "All Implemented Interfaces" section. But it should be
easy for the doclet to match up an interface name with the appropriate
type parameters, in which case they'd be very nice to have. I'd say go
for it.
6. "Overrides:"
Not necessary but nice to have, as with #5. Unlike #5 there is already
support in the doclet API for getting the type parameters. However,
until #5 includes type parameters, I wonder if showing them
here seems too inconsistent (I could go either way on this).
In the cases where type parameter information is desired but not yet
available to the doclet, for the initial putback I strongly recommend
omitting the parameters rather than showing the wrong thing. We'll
hope to get permission to add the new functionality later. This applies
to items #2 and #3, and optionally to #5 and #6.
Do not fix this bug until 4922918 is fixed. That's the bug for the required doclet API changes.
- relates to
-
JDK-4922918 Provide supertypes of parameterized types with type params substituted.
-
- Resolved
-