Re: [mdr-users] NullPointerException with IBM JRE

Thanks for your explanation - I have fixed it similarly to how you 
suggested.
Regards,
Martin

Mike Martin wrote:

> Martin wrote:
>
>> Thanks for the patch. I have to admit I do not understand (even after 
>> your explanation) how the IBM JRE works (when it makes the entries 
>> invalid and why your patch fixes that). Could you please point me to 
>> some web page containing the description of the problem?
>
>
> The only place I can think of is Sun's Javadoc for Map.Entry
> itself, which says:
>
>    public static interface Map.Entry
>
>    A map entry (key-value pair).  The Map.entrySet method returns a
>    collection-view of the map, whose elements are of this class.  The
>    only way to obtain a reference to a map entry is from the iterator
>    of this collection-view.  These Map.Entry objects are valid only
>    for the duration of the iteration; more formally, the behavior of
>    a map entry is undefined if the backing map has been modified after
>    the entry was returned by the iterator, except through the iterator's
>    own remove operation, or through the setValue operation on a map
>    entry returned by the iterator.
>
> In other words, the Map.Entry objects in an entry set are not
> necessarily copies of the entry data, they're actually backed
> by the entries in the map (note that Map.Entry.setValue()
> actually updates its backing entry).
>
> When one says:
>
>    ArrayList result = new ArrayList(dirty.entrySet());
>
> 'result' is filled with Map.Entry objects but those objects
> are still backed by the entries in the 'dirty' map.  If we
> then do:
>
>    dirty.clear();
>
> we've just invalidated all those Entry objects according to
> the rule above.  By changing it to:
>
>    ArrayList result = new ArrayList(new HashMap(dirty).entrySet());
>
> we copy the entries to another map which is *not* subsequently
> modified, so the Entry objects will remain valid indefinitely.
>
> BTW, I have another patch I'd like to submit re. XMI writing
> and the XML encoding attribute.  Is this a good place for us
> to correspond on patches or is somewhere else preferred?
>
> Mike