RFR: 5047859 : (reflect) Class.getField can't find String[].length
David Holmes
david.holmes at oracle.com
Thu Aug 29 05:18:35 UTC 2013
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.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.
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
>
More information about the core-libs-dev
mailing list