[JIRA] Commented: (JXT-82) ListView's clear empties the whole backingList instead of only the entries it's responsible for

[Brent Putman (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/JXT-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663#comment-13663 ] 

Brent Putman commented on JXT-82:
---------------------------------

This is definitely a bug. So far I've identified 2 issues associated with this:

1) The simple fix above won't work as-is. There is a boundary condition here such that when the last member of the sublist is removed, the index structure in the backingList has the whole index for the QName key removed (see removeElementFromIndex(QName index, ElementType element)).  So when the LiewView naively then does indexList = backingList.get(index); to reset what it holds, it gets null, causing all subsequent ops on the ListView to fail with NPE's.

This is an issue that can arise from any of the methods that mutate the list in a subtractive way, e.g. clear(), remove(), removeAll(), retainAll(), etc.

The simplest solution would be to have IndexedXMLObjectChildrenList#get(QName) never return null, but instead insert and return an empty list.  This would be symmetrical with what the IndexedXMLObjectChildrenList#sublist(QName) method does, creates an artificial empty List entry in the objectIndex.

Otherwise the ListView would have to special case this and set indexList to a locally constructed empty list whenever backingList.get(QName) returns null.

I need to examine further the ramifications of doing either of these approaches.


2) Symantically speaking, this got me to thinking about what it really should mean to remove an item from the sublist.  The sublist is created on the basis of a QName.  But in the backing list members are indexed potentially via 2 different QNames, element and type name.  So if I have a Foo, which is of FooType, and I take a sublist based on say FooType: if I clear() or remove() from the FooType sublist, should that really cause the member to disappear from the backing list entirely? It's still a Foo and it's not obvious that as a Foo (as distinct from it being a FooType) it should be operated on.  Maybe can't fix this in v2, just noting this semantic issue for possible v3 work.



> ListView's clear empties the whole backingList instead of only the entries it's responsible for
> -----------------------------------------------------------------------------------------------
>
>                 Key: JXT-82
>                 URL: https://issues.shibboleth.net/jira/browse/JXT-82
>             Project: XMLTooling - Java
>          Issue Type: Bug
>    Affects Versions: 1.3.1
>            Reporter: anli.shundi at idp.protectnetwork.org
>            Assignee: Brent Putman
>             Fix For: 1.3.3
>
>
> class {{ListView<ElementType extends XMLObject> extends AbstractList<ElementType>}} inside {{IndexedXMLObjectChildrenList}} overrides the method {{clear()}} of {{java.util.AbstracList}} but violates its javadoc:
> According to http://download.oracle.com/javase/6/docs/api/java/util/AbstractList.html#subList(int,%20int)
> {quote}
> ...the following idiom removes a range of elements from a list:
>       {{list.subList(from, to).clear();}}
> {quote}
> ListView's clear calls {{backingList.clear();}} instead; that is it clears the whole backing list instead of limiting to the QNames it lists itself.  A quick fix would be to call {{backingList.removeAll(this)}} instead.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira