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. 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