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

David Holmes david.holmes at oracle.com
Wed Jun 20 02:09:41 UTC 2012

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

More information about the core-libs-dev mailing list