On 29/08/2013 6:26 AM, Joel Borggrén-Franck wrote:
Hi David,
On Aug 27, 2013, at 5:21 AM, David Holmes <david.hol...@oracle.com> wrote:
Hi Joel,
On 26/08/2013 10:39 PM, Joel Borggren-Franck wrote:
Hi,
Please review doc fix and test for
http://bugs.sun.com/view_bug.do?bug_id=5047859
http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
This is a spec change to update the spec to match the long-standing
implementation.
Have to wonder why reflection chose to ignore 'length' when the JLS is so clear
that it is a field ??
This is way before my time but my guess is that hotspot got this wrong way back
when. From my experience with how length was implemented in JRockit it wasn't
obvious that it should be reflected as a Field.
Anyway ... I think the added wording to getField() is okay but:
1604 * follows. Let C be the class or interface represented by this
object:
I don't think it necessary, or desirable to replace 'class' with 'class or interface' here. If you
do then you should do it everywhere - which would be bad. Plus does it really mean "class, or
interface, or enum, or annotation" ? Sometimes "class" just means the thing a Class
represents.
I think it is a reasonable compromise between legalese precision and brevity.
The javadoc for Class is already inconsistent, using 'class or interface' in
some parts and a sole 'class' in others where 'class or interface' would be
more appropriate. I don't think it is realistic to expect a big rewrite of our
API doc for consistency, but that shouldn't stop us from improving things
locally. There are a few more clarification to the reflective parts of the
Class docs in in the pipe.
Even locally there are other uses of "class" which really mean "class or
interface" (or maybe even Class object?)-
1623 * @return the {@code Field} object of this class specified by
1631 * ancestor of the class loader for the current class and
1634 * of this class.
But changing these would not improve clarity at all IMHO. Using "class"
to mean "class or interface" is extremely common. Once the method specs,
as in this case, have stated that the method applies to "class or
interface" then I think it is perfectly fine to simply say "class"
thereafter unless you really need to distinguish between classes and
interfaces.
Cheers,
David
------
Annotation types are interface types and enum types are class types so it
rarely makes sense to single them out unless they are a special case. Interface
types are not class types.
There is also a clarification of getFields() javadoc without changing the
spec.
I don't think this change make sense given it already says it returns a zero-length array
for array classes - as Mandy pointed out. I don't think this "clarification" is
needed.
Agreed. I plan to revisit this part.
cheers
/Joel