hg: jdk8/tl/langtools: 7177701: error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation

[David Holmes]

Hi Joe,

On 20/06/2012 11:28 AM, Joe Darcy wrote:
> On 6/19/2012 6:14 PM, David Holmes wrote:
>> On 19/06/2012 10:27 PM, maurizio.cimadamore at oracle.com wrote:
>>> Changeset: 34e254ffd0e7
>>> Author: mcimadamore
>>> Date: 2012-06-19 13:25 +0100
>>> URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e254ffd0e7
>>>
>>> 7177701: error: Filling jar message during
>>> javax/imageio/metadata/IIOMetadataFormatImpl compilation
>>> Summary: Recent JDK hash changes affected order in which files are
>>> returned from JavacFileManager.list()
>>> Reviewed-by: jjg
>>>
>>> ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
>>
>> That change seems fragile to say the least. Somewhere some piece of
>> code depends on the iteration order of the collection. The recent
>> changes meant that HashSet's returned order changed and broke things.
>> So you change to a LinkedHashSet which somehow restores the old order
>> (or at least reorders it yet again but in a way that doesn't cause a
>> problem).
>>
>> David
>
> LinkedHashSet is specified to preserve insertion order in iteration:
> "This implementation [of LinkedHashSet] differs from HashSet in that it
> maintains a doubly-linked list running through all of its entries. This
> linked list defines the iteration ordering, which is the order in which
> elements were inserted into the set (insertion-order)."
>
> Therefore, LinkedHashSet is just the right class to use when predictable
> iteration order matters :-)

So is there an assumption that traversal is in insertion order? Or is it 
just that insertion order happens to work?

David


> -Joe