RFR 8186961 Class.getFields() does not return fields of previously visited super interfaces/classes.
Mandy Chung
mandy.chung at oracle.com
Fri Dec 1 23:27:39 UTC 2017
> On Dec 1, 2017, at 2:52 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>
>
>> On 1 Dec 2017, at 12:16, mandy chung <mandy.chung at oracle.com> wrote:
>>
>>
>>
>>> On 11/30/17 12:17 PM, Paul Sandoz wrote:
>>> Here is the updated webrev:
>>>
>>>
>>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/
>>>
>>>
>>> I opted for the simple solution using a LinkedHashSet.
>>>
>>
>> This fix looks good except a typo in the test:
>>
>> 94 "Class %s does not have extracly one field: %d", c.getName(), nfs));
>>
>> s/extracly/exactly/
>>
>
> Fixed.
>
>
>> I am wondering if these @run should run with both othervm and agentvm mode since
>> it currently depends on the jtreg command-line
>
>
>> (I believe our test target uses
>> agentvm as the default).
>>
>
> It does.
>
> * @run main/othervm StaticFieldsOnInterface C
> * @run main/othervm StaticFieldsOnInterface D
> * @run main/othervm StaticFieldsOnInterface Y
>
> This ok?
>
Yes.
Mandy
>
>>> It’s possible to heavily optimize (avoiding the production of a linked hash set until required [*]) but the resulting code is harder to understand.
>>>
>>
>> I was tempted to come up with optimization too when first reading the patch but I am with you. I like the resulting code simple and clear. The difference is an array list vs linked hash set which we should wait until this is really a performance issue. FWIW getMethods implementation also creates a linked hash set if not cached.
>>
>
> Ok, thanks,
> Paul.
More information about the core-libs-dev
mailing list