RFR: 8062194: java.util.jar.Attributes should use insertion-ordered iteration
Martin Buchholz
martinrb at google.com
Tue Oct 28 18:09:15 UTC 2014
Xueming, I understand that getting CCC approval is a fair amount of
work. At your option, we could leave the spec unchanged and do
without CCC, given that Attributes' iteration order has changed in
every past release. Or we could split the spec change off as a
separate improvement.
On Mon, Oct 27, 2014 at 12:15 PM, Martin Buchholz <martinrb at google.com> wrote:
> [+core-libs-dev oops I forgot to cc: the first time...]
>
> On Mon, Oct 27, 2014 at 12:02 PM, Xueming Shen <xueming.shen at oracle.com>
> wrote:
>>
>> On 10/27/2014 11:33 AM, Martin Buchholz wrote:
>>>
>>> Hello Xueming, Alan,
>>>
>>> I'd like you to do a code review.
>>>
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Attributes-iteration-order/
>>> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/Attributes-iteration-order/>
>>> https://bugs.openjdk.java.net/browse/JDK-8062194
>>
>>
>> The change looks fine. But guess we might have to go through the CCC for
>> this one,
>> given the nature of its "incompatibility"?
>>
>
> Yes - technically, this is a small incompatibility. (But Attribute
> iteration order has changed many times)
>
>>
>> Btw, is there any "noticeable" performance concern of switching from
>> hashmap to linkedhashmap?
>> Guess, we might have use scenario that lots of attributes is being access
>> when lots of jar get
>> opened the same time...
>
>
> LinkedHashMap uses a "little more" cpu and memory. The cost is small enough
> that some people have suggested simply replacing HashMap's implementation
> with that of LinkedHashMap, and that is not totally crazy, but we're not
> going that far. Attributes are unlikely to contain many elements or to be
> long-lived.
>
More information about the core-libs-dev
mailing list