RFR: 5047859 : (reflect) Class.getField can't find String[].length

Joel Borggrén-Franck joel.franck at oracle.com
Wed Aug 28 20:26:01 UTC 2013

Hi David,

On Aug 27, 2013, at 5:21 AM, David Holmes <david.holmes at 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.

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.


More information about the core-libs-dev mailing list