from:"Thomas Vahrst \(JIRA\)"

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-04-27 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643603#comment-13643603
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

Hi Thomas,
oops, I definitly do not feel criticized - I am sorry if my comment sounds this 
way. In fact this issue is a interesting programming challenge. Regardless of 
the efforts: I am convinced that SetUniqueList's 'mixture' of List API and Set 
behavior makes it very difficult to provide a simple, intuitive and consistent 
implementation of the sublist() method.

So I would appreciate the decision to let sublist() return an unmodifiable 
list. 

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-04-26 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642987#comment-13642987
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

Hi Thomas,
Christian Semrau, who reported this issue, provides in the issue description 
two possible solutions to the inconsistency of sublist. In a nutshell:
When adding a value to a SubList and this value exists in the underlying 
SetUniqueList,
1. the subList behaves like a SetUniqueList and the existing value is *moved* 
to the new position - thus breaking the contract of the underlying 
SetUniqueList.
2. nothing happens because the value already exists - which means that the 
*sublist* does not behave like a SetUniqueList.

Christian preferred the first solution, so I implemented all JUnit tests (and 
the proposed changes of SetUniqueList) according to solution no. 1


If we decide to switch to solution no. 2, I would at first change all unit 
tests according to this solution. Ok?

btw: invoking set() method with a value that exists outside the sublist will 
move the value to the new position, right?

(btw 2: did I allready mention that I am not happy at all with our attempt to 
solve a obviously inconsistent construct? Whether solution No. 1 or 2: I wonder 
how to write a good javadoc comment for sublist() which describes the behavior 
in a clear manner... The possibly most simple javadoc could read: This method 
returns a sublist which is umodifiable. ;-)


 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-04-26 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642987#comment-13642987
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 4/26/13 4:44 PM:

Hi Thomas,
Christian Semrau, who reported this issue, provides in the issue description
two possible solutions to the inconsistency of sublist. In a nutshell:
When adding a value to a SubList and this value exists in the underlying
SetUniqueList,
1. the subList behaves like a SetUniqueList and the existing value is *moved*
to the new position - thus breaking the contract of the underlying
SetUniqueList.
2. nothing happens because the value already exists - which means that the
*sublist* does not behave like a SetUniqueList.

Christian preferred the first solution, so I implemented all JUnit tests (and
the proposed changes of SetUniqueList) according to solution no. 1

If we decide to switch to solution no. 2, I would at first change all unit
tests according to this solution. Ok?

btw: invoking set() method with a value that exists outside the sublist will
move the value to the new position, right? And also: removing a value in a
sublist which exists outside the sublist range will remove this value in the
underlying SEtUnqiqueList?

(btw 2: did I allready mention that I am not happy at all with our attempt to
solve a obviously inconsistent construct? Whether solution No. 1 or 2: I wonder
how to write a good javadoc comment for sublist() which describes the behavior
in a clear manner... The possibly most simple javadoc could read: This method
returns a sublist which is umodifiable. ;-)

was (Author: t.vahrst):
Hi Thomas,
Christian Semrau, who reported this issue, provides in the issue description
two possible solutions to the inconsistency of sublist. In a nutshell:
When adding a value to a SubList and this value exists in the underlying
SetUniqueList,
1. the subList behaves like a SetUniqueList and the existing value is *moved*
to the new position - thus breaking the contract of the underlying
SetUniqueList.
2. nothing happens because the value already exists - which means that the
*sublist* does not behave like a SetUniqueList.

Christian preferred the first solution, so I implemented all JUnit tests (and
the proposed changes of SetUniqueList) according to solution no. 1

If we decide to switch to solution no. 2, I would at first change all unit
tests according to this solution. Ok?

btw: invoking set() method with a value that exists outside the sublist will
move the value to the new position, right?

Modifications of a SetUniqueList.subList() invalidate the parent list
-

Key: COLLECTIONS-310
URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
Project: Commons Collections
Issue Type: Bug
Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
Fix For: 4.0

Attachments: SetUniqueList.java, SetUniqueList.patch,
SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java

The List returned by SetUniqueList.subList() is again a SetUniqueList. The
contract for List.subList() says that the returned list supports all the
operations of the parent list, and it is backed by the parent list.
We have a SetUniqueList uniqueList equal to {Hello, World}. We get a
subList containing the last element. Now we add the element Hello,
contained in the uniqueList but not in the subList, to the subList.
What should happen?
Should the subList behave like a SetUniqueList and add the element - meaning
that it changes position in the uniqueList because at the old place it gets
removed, so now uniqueList equals {World, Hello} (which fails)?
Or should the element not be added, because it is already contained in the
parent list, thereby violating the SetUniqueList-ness of the subList (which
fails)?
I prefer the former behaviour, because modifications should only be made
through the subList and not through the parent list (as explained in
List.subList()).
What should happen if we replace (using set) the subList element World with
Hello instead of adding an element?
The subList should contain only Hello, and for the parent list, the old
element 0 (now a duplicate of the just set element 1) should be removed
(which

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-03-04 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 3/4/13 8:32 PM:
---

SetUniqueList.patch contains JUnit Tests and Variant No. 1 for SetUniqueList. I
am not sure whether the patch has a correct format (I am not able to re-apply
the patch in Netbeans...) so I attached the corresponding java files as well.

Some comment to this solution:
1. During the implementation I recognized, that the existing implementation of
subList() uses the subList() method on the decorated list and then creates a
new Set and fills all elements of the sublist into the set.

Now this issue requires, that a parent list has to be modified on certain
invocations on a sublist - for example when adding an element to the sublist
which exists in the parent list somewhere outside the range of the sublist.
With the current sublist implementation, any attempt to modify a parent list
fails with a ConcurrentModifiationException. So we have to reimplement the
sublist functionality inside SetUniqueList and can not reuse the service of
AbstractListDecorator.

2. When we create a subList on a SetUniqueList, this sublist has to obbey the
SetUniqueList contracts. The original parent list will have slightly different
behavior when adding or setting values. When we create a second sublist based
on the first sublist, this top most list has to provide SetUniqueList semantics.

Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9

Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

(The 'movement' of 'd' causes the ConcurrentModificationException mentioned
above.)

Because of this requirements I decided for Variant No. 1, that every
SetUniqueList holds its own list and set and maintains a reference to it's
parent SetUniqueList and an offset value. The SetUniqueList garantees, that all
parent lists are updated according to the required functionality and that all
offset values are adjusted if necessary. This solution does not use the sublist
functionality of the decorated list but creates allway a new Set *and* List.

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

# a very details javadoc comment for the subList() method, explaining the
behavior.
# the implementation for listIterator().

... to be continued with variant no. 2 ...

was (Author: t.vahrst):
SetUniqueList.patch contains JUnit Tests and Variant No. 1 for
SetUniqueList. I am not sure whether the patch has a correct format (I am not
able to re-apply the patch in Netbeans...) so I attached the corresponding java
files as well.

Adds a 'd' to

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-03-04 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-310:
--

Attachment: SetUniqueListTest.java
SetUniqueList.v2.java

2nd variant of modified SetUniqueList and even more Testcases für sublist.

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-03-04 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592633#comment-13592633
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

SetUniqueListTest.java now contains some new testcases to test the behavior of 
listiterators of sublists. 

SetUniqueList.v2.java is the 2nd variant I implemented. In contrast to the 
first attempt, this class does not inherit from AbstractListDecorator but 
inherits from java.util.AbstractList. It holds a reference to a underlying list 
which is *shared* with all sublists. So every sublist holds the reference to 
the underlying list and maintains it's own set and a offset of its element 
range in the underlying list.

This variant contains support for iterators and listiterators on sublists.

I personally found this solution a bit more elegant than the first variant. 



 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more

[jira] [Updated] (COLLECTIONS-444) SetUniqueList may become inconsistent

2013-02-25 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-444:
--

Description: 
I found this bug during my work on issue COLLECTIONS-310 : 

When you 'set' an element to a position that contains this element, it is 
removed from the internal set. This leads to the situation that 
- invocing get() returns the element
- invocing contains() returns false.

Extending the existing test method for set:
{code}
   public void testSet() {
final SetUniqueListE lset = new SetUniqueListE(new ArrayListE(), 
new HashSetE());

// Duplicate element
final E obj1 = (E) new Integer(1);
final E obj2 = (E) new Integer(2);
final E obj3 = (E) new Integer(3);

lset.add(obj1);
lset.add(obj2);
lset.set(0, obj1);
assertEquals(2, lset.size());
assertSame(obj1, lset.get(0));
assertSame(obj2, lset.get(1));

assertTrue(lset.contains(obj1));  // fails !
assertTrue(lset.contains(obj2));

{code}




  was:
I found this bug during my work on issue COLLECTIONS-310 : 

When you 'set' an element to a position that contains this element, it is 
removed from the internal set. This leads to the situation that 
- invocing get() returns the element
- invocing contains() returns false.

Extending the existing test method for set:
{code}
   public void testSet() {
final SetUniqueListE lset = new SetUniqueListE(new ArrayListE(), 
new HashSetE());

// Duplicate element
final E obj1 = (E) new Integer(1);
final E obj2 = (E) new Integer(2);
final E obj3 = (E) new Integer(3);

lset.add(obj1);
lset.add(obj2);
lset.set(0, obj1);
assertEquals(2, lset.size());
assertSame(obj1, lset.get(0));
assertSame(obj2, lset.get(1));

assertTrue(lset.contains(obj1));  // fails !
assertTrue(lset.contains(obj2));

{code}



 SetUniqueList may become inconsistent
 -

 Key: COLLECTIONS-444
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-444
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2.1
Reporter: Thomas Vahrst

 I found this bug during my work on issue COLLECTIONS-310 : 
 When you 'set' an element to a position that contains this element, it is 
 removed from the internal set. This leads to the situation that 
 - invocing get() returns the element
 - invocing contains() returns false.
 Extending the existing test method for set:
 {code}
public void testSet() {
 final SetUniqueListE lset = new SetUniqueListE(new 
 ArrayListE(), new HashSetE());
 // Duplicate element
 final E obj1 = (E) new Integer(1);
 final E obj2 = (E) new Integer(2);
 final E obj3 = (E) new Integer(3);
 lset.add(obj1);
 lset.add(obj2);
 lset.set(0, obj1);
 assertEquals(2, lset.size());
 assertSame(obj1, lset.get(0));
 assertSame(obj2, lset.get(1));
 assertTrue(lset.contains(obj1));  // fails !
 assertTrue(lset.contains(obj2));
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-310:
--

Attachment: SetUniqueListTest.java
SetUniqueList.java
SetUniqueList.patch

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-310:
--

Attachment: (was: SetUniqueListTest.patch)

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

SetUniqueList.patch contains JUnit Tests and Variant No. 1 for SetUniqueList. I 
am not sure whether the patch has a correct format (I am not able to re-apply 
the patch in Netbeans...) so I attached the corresponding java files as well.



 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
 ] 

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 8:54 PM:


SetUniqueList.patch contains JUnit Tests and Variant No. 1 for SetUniqueList. I 
am not sure whether the patch has a correct format (I am not able to re-apply 
the patch in Netbeans...) so I attached the corresponding java files as well.

Some comment to this solution: 
1. During the implementation I recognized, that the existing implementation of 
subList() uses the subList() method on the decorated list and then creates a 
new Set and fills all elements of the sublist into the set. 

Now this issue requires, that a parent list has to be modified on certain 
invocations on a sublist - for example when adding an element to the sublist 
which exists in the parent list somewhere outside the range of the sublist. 
With the current sublist implementation, any attempt to modify a parent list 
fails with a ConcurrentModifiationException. So we have to reimplement the 
sublist functionality inside SetUniqueList and can not reuse the service of 
AbstractListDecorator.

2. When we create a subList on a SetUniqueList, this sublist has to obbey the 
SetUniqueList contracts. The original parent list will have slightly different 
behavior when adding or setting values. When we create a second sublist based 
on the first sublist, this top most list has to provide SetUniqueList semantics.

Example (from JUnit Tests)
{noformat} 
 subList2! e ! f ! g !  offset = 2
 subList1! c ! d ! e ! f ! g ! h !  offset = 2
 list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j !  offset = 0
 -
 Index 0   1   2   3   4   5   6   7   8   9

 Tests adding a 'd' to subList2. This should move the 'd' in subList1 and list 
in the range of subList2
 Expected result:

 subList2! e ! f ! g ! d !  offset = 1
 subList1! c ! e ! f ! g ! d ! h !  offset = 2
 list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j !  offset = 0
 -
 Index 0   1   2   3   4   5   6   7   8   9
{noformat} 












  was (Author: t.vahrst):
SetUniqueList.patch contains JUnit Tests and Variant No. 1 for 
SetUniqueList. I am not sure whether the patch has a correct format (I am not 
able to re-apply the patch in Netbeans...) so I attached the corresponding java 
files as well.


  
 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:07 PM:

Tests adding a 'd' to subList2. This should move the 'd' in subList1 and list
in the range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

# a very details javadoc comment for the subList() method, explaining the
behavior.
# the implementation for listIterator(). As already mentioned, a ListIterator
may itself become a sublist (when specifying a start index).

Tests adding a 'd' to subList2. This

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:09 PM:

Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

Tests adding a 'd' to subList2. This should

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:10 PM:

Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

(The 'movement' of 'd' causes the ConcurrentModificationException mentioned
above.)

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0
-
Index 0

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-18 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:12 PM:

Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

(The 'movement' of 'd' causes the ConcurrentModificationException mentioned
above.)

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

... to be continued with variant no. 2 ...

Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-17 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-310:
--

Attachment: SetUniqueListTest.patch

Many new testcases for sublists.

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueListTest.patch


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-17 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580284#comment-13580284
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

I am trying to create a sublist implementation which conforms to the required 
functions. The first attachement (SetUniqueListTest.patch) contains many new 
testcases for sublist, checking this functions. 

I implemented two possible solutions, more of that in the next posts. During 
the coding I realized a further problem concerning ListIterator. ListIterator 
supports add/set/remove functionality, which means, that a ListIterator based 
on a sublist needs the corresponding sublist behavior. And ListIterator may 
start at a specified index, so this  means, that a ListIterator with index  0 
based on a SetUniqueList itself is a subList of the underlying SetUniqueList - 
with all the necessary behavior. 

So for the first iteration on this issue, I ommited these tests. I will 
provided them later...

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueListTest.patch


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-17 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580284#comment-13580284
 ] 

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/17/13 8:53 PM:


I am trying to create a sublist implementation which conforms to the required 
functions. The first attachement (SetUniqueListTest.patch) contains many new 
testcases for sublist, checking this functions. 

I implemented two possible solutions, more of that in the following posts (in 
the next days). During the coding I realized a further problem concerning 
ListIterator. ListIterator supports add/set/remove functionality, which means, 
that a ListIterator based on a sublist needs the corresponding sublist 
behavior. And ListIterator may start at a specified index, so this  means, that 
a ListIterator with index  0 based on a SetUniqueList itself is a subList of 
the underlying SetUniqueList - with all the necessary behavior. 

So for the first iteration on this issue, I ommited these tests. I will 
provided them later...

  was (Author: t.vahrst):
I am trying to create a sublist implementation which conforms to the 
required functions. The first attachement (SetUniqueListTest.patch) contains 
many new testcases for sublist, checking this functions. 

I implemented two possible solutions, more of that in the next posts. During 
the coding I realized a further problem concerning ListIterator. ListIterator 
supports add/set/remove functionality, which means, that a ListIterator based 
on a sublist needs the corresponding sublist behavior. And ListIterator may 
start at a specified index, so this  means, that a ListIterator with index  0 
based on a SetUniqueList itself is a subList of the underlying SetUniqueList - 
with all the necessary behavior. 

So for the first iteration on this issue, I ommited these tests. I will 
provided them later...
  
 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueListTest.patch


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[]

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-02 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569532#comment-13569532
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

I took a deeper look on this issue and the suggested behavior/junit tests and 
tried to understand the problem(s). It seems, there a two issues with the 
current implementation regarding modifications of sublists:
# Modifications of sublist items are delegated to the underlying backing list 
(which is the default sublist implementation) but *not* to the internal set of 
the parent SetUniqueList.  So a new entry is added to the list, but the 
contains() method of the parent SetUniqueList returns false
# Modifications of the sublist may result in changes outside the range of the 
sublist. For example adding an element which is not in the sublist but 
somewhere in the backing list should result in *moving* the item from its 
current position to the new position defined by the subset. This move may 
corrupt the internal range offsets of the sublist. 

To solve


 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly,

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-02 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569532#comment-13569532
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/2/13 1:01 PM:
---

I took a deeper look on this issue and the suggested behavior/junit tests and
tried to understand the problem(s). It seems, there a two issues with the
current implementation regarding modifications of sublists:
# Modifications of sublist items are delegated to the underlying backing list
(which is the default sublist implementation) but *not* to the internal set of
the parent SetUniqueList. So a new entry is added to the list, but the
contains() method of the parent SetUniqueList returns false
# Modifications of the sublist may result in changes outside the range of the
sublist. For example adding an element which is not in the sublist but
somewhere in the backing list should result in *moving* the item from its
current position to the new position defined by the subset. This move may
corrupt the internal range offsets of the sublist.

The first issue seems easy to solve, for example by holding a reference of the
parent set in the subset. But if another subset is created based on the first
subset, we have to maintain a collections of parent sets.

The second issue is similar to a direct modification of a backing list - which
is not supported. The javadoc of sublist states
{quote}
The semantics of the list returned by this method become undefined if the
backing list (i.e., this list) is structurally modified in any way other than
via the returned list. (Structural modifications are those that change the size
of this list, or otherwise perturb it in such a fashion that iterations in
progress may yield incorrect results.)
{quote}

To solve this problem, the subList implementation has to track all
modifications of the backing list and adjust it's internal range offsets
accordingly. For example adding a duplicate item to a sublist, which exists
'in front' of the sublist will result
- moving the item to the new sublist position
- decrement the range offsets of the sublist.

So first of all I wrote a short javadoc comment for the sublist method:
{code}
/**
* Returns a view of the portion of this list between the specified
* fromIndex, inclusive, and toIndex, exclusive.
* p
* i(Violation)/i According to the codeList/code interface the
returned
* sublist has to be backed by the original list. Because a
codeSetUniqueList/code
* requires both a defined ordering of the list items iand/i uniqueness
of
* all list items, modifications cannot garantee consistant behavior of both
* the backing list and the sub list. It is strongly recommended not to
modify
* the sublist.
* p
*
* @param fromIndex
* @param toIndex
* @return
*/

{code}

Should we perhaps return the sublist as a UnmodifiableList?

was (Author: t.vahrst):
I took a deeper look on this issue and the suggested behavior/junit tests
and tried to understand the problem(s). It seems, there a two issues with the
current implementation regarding modifications of sublists:
# Modifications of sublist items are delegated to the underlying backing list
(which is the default sublist implementation) but *not* to the internal set of
the parent SetUniqueList. So a new entry is added to the list, but the
contains() method of the parent SetUniqueList returns false
# Modifications of the sublist may result in changes outside the range of the
sublist. For example adding an element which is not in the sublist but
somewhere in the backing list should result in *moving* the item from its
current position to the new position defined by the subset. This move may
corrupt the internal range offsets of the sublist.

To solve

Modifications of a SetUniqueList.subList() invalidate the parent list
-

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-02-02 Thread Thomas Vahrst (JIRA)

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569532#comment-13569532
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/2/13 1:02 PM:
---

I took a deeper look on this issue and the suggested behavior/junit tests and
tried to understand the problem(s). It seems, there a two issues with the
current implementation regarding modifications of sublists:
# Modifications of sublist items are delegated to the underlying backing list
(which is the default sublist implementation) but *not* to the internal set of
the parent SetUniqueList. So a new entry is added to the list, but the
contains() method of the parent SetUniqueList returns false
# Modifications of the sublist may result in changes *outside* the range of the
sublist. For example adding an element which is not in the sublist but
somewhere in the backing list should result in *moving* the item from its
current position to the new position defined by the subset. This move may
corrupt the internal range offsets of the sublist.

{code}

Should we perhaps return the sublist as a UnmodifiableList?

[jira] [Created] (COLLECTIONS-441) MultiKeyMap.clone() should call super.clone()

2013-02-02 Thread Thomas Vahrst (JIRA)

Thomas Vahrst created COLLECTIONS-441:
-

 Summary: MultiKeyMap.clone() should call super.clone()
 Key: COLLECTIONS-441
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-441
 Project: Commons Collections
  Issue Type: Improvement
  Components: Map
Affects Versions: 4.0-beta-1
Reporter: Thomas Vahrst
Priority: Minor


This issue addresses a findbugs issue: 
{quote}
org.apache.commons.collections.map.MultiKeyMap.clone() does not call 
super.clone()
{quote}
The current clone() implementation creates a new MultiKeyMap instance. This 
will lead to problems when clone() is invoked on subclasses of MultiKeyMap. 
This is a corresponding junit test which fails:

{code}
class MultiKeyMapTest

// Subclass to test clone() method
private static class MultiKeyMapSubclass extends MultiKeyMapString, 
String{
}

public void testCloneSubclass(){
MultiKeyMapSubclass m = new MultiKeyMapSubclass();
m.put(A, B, C);

MultiKeyMapSubclass m2 = (MultiKeyMapSubclass) m.clone();
assertEquals(C, m.get(A, B));

}



{code}


Instead of creating a new MultiKeyMap instance, the clone() method should 
invoke super.clone() which leads in Object.clone(). This always returns an 
object of the correct type. 

{code}
class MultiKeyMap{

/**
 * Clones the map without cloning the keys or values.
 *
 * @return a shallow clone
 */
@Override
public MultiKeyMapK, V clone() {

   try {
MultiKeyMapK,V m = (MultiKeyMapK, V) super.clone();
AbstractHashedMapMultiKey? extends K, V del = 
(AbstractHashedMapMultiKey? extends K, V)decorated().clone();

m.map = del;
((AbstractMapDecoratorK,V)m).map = (Map) del;
return m;
} catch (CloneNotSupportedException ex) {
throw new RuntimeException (ex);  // this should never happen...
}
}


{code}

*Note*
For serialisation compatibilty reasons to commons collections V.3.2,  
MultiKeyMap contains a map reference (the decorated map) which hides the same 
field in the super class AbstractMapDecorator. This is quite 'ugly' to 
understand and maintain.

Should we consider to break the compatibility to the 3.2 version? 









--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-441) MultiKeyMap.clone() should call super.clone()

2013-02-02 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-441:
--

Description: 
This issue addresses a findbugs issue: 
{quote}
org.apache.commons.collections.map.MultiKeyMap.clone() does not call 
super.clone()
{quote}
The current clone() implementation creates a new MultiKeyMap instance. This 
will lead to problems when clone() is invoked on subclasses of MultiKeyMap. 
This is a corresponding junit test which fails:

{code}
class MultiKeyMapTest

// Subclass to test clone() method
private static class MultiKeyMapSubclass extends MultiKeyMapString, 
String{
}

public void testCloneSubclass(){
MultiKeyMapSubclass m = new MultiKeyMapSubclass();

MultiKeyMapSubclass m2 = (MultiKeyMapSubclass) m.clone();

}



{code}


Instead of creating a new MultiKeyMap instance, the clone() method should 
invoke super.clone() which leads in Object.clone(). This always returns an 
object of the correct type. 

{code}
class MultiKeyMap{

/**
 * Clones the map without cloning the keys or values.
 *
 * @return a shallow clone
 */
@Override
public MultiKeyMapK, V clone() {

   try {
MultiKeyMapK,V m = (MultiKeyMapK, V) super.clone();
AbstractHashedMapMultiKey? extends K, V del = 
(AbstractHashedMapMultiKey? extends K, V)decorated().clone();

m.map = del;
((AbstractMapDecoratorK,V)m).map = (Map) del;
return m;
} catch (CloneNotSupportedException ex) {
throw new RuntimeException (ex);  // this should never happen...
}
}


{code}

*Note*
For serialisation compatibilty reasons to commons collections V.3.2,  
MultiKeyMap contains a map reference (the decorated map) which hides the same 
field in the super class AbstractMapDecorator. This is quite 'ugly' to 
understand and maintain.

Should we consider to break the compatibility to the 3.2 version? 









  was:
This issue addresses a findbugs issue: 
{quote}
org.apache.commons.collections.map.MultiKeyMap.clone() does not call 
super.clone()
{quote}
The current clone() implementation creates a new MultiKeyMap instance. This 
will lead to problems when clone() is invoked on subclasses of MultiKeyMap. 
This is a corresponding junit test which fails:

{code}
class MultiKeyMapTest

// Subclass to test clone() method
private static class MultiKeyMapSubclass extends MultiKeyMapString, 
String{
}

public void testCloneSubclass(){
MultiKeyMapSubclass m = new MultiKeyMapSubclass();
m.put(A, B, C);

MultiKeyMapSubclass m2 = (MultiKeyMapSubclass) m.clone();
assertEquals(C, m.get(A, B));

}



{code}


Instead of creating a new MultiKeyMap instance, the clone() method should 
invoke super.clone() which leads in Object.clone(). This always returns an 
object of the correct type. 

{code}
class MultiKeyMap{

/**
 * Clones the map without cloning the keys or values.
 *
 * @return a shallow clone
 */
@Override
public MultiKeyMapK, V clone() {

   try {
MultiKeyMapK,V m = (MultiKeyMapK, V) super.clone();
AbstractHashedMapMultiKey? extends K, V del = 
(AbstractHashedMapMultiKey? extends K, V)decorated().clone();

m.map = del;
((AbstractMapDecoratorK,V)m).map = (Map) del;
return m;
} catch (CloneNotSupportedException ex) {
throw new RuntimeException (ex);  // this should never happen...
}
}


{code}

*Note*
For serialisation compatibilty reasons to commons collections V.3.2,  
MultiKeyMap contains a map reference (the decorated map) which hides the same 
field in the super class AbstractMapDecorator. This is quite 'ugly' to 
understand and maintain.

Should we consider to break the compatibility to the 3.2 version? 










 MultiKeyMap.clone() should call super.clone()
 -

 Key: COLLECTIONS-441
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-441
 Project: Commons Collections
  Issue Type: Improvement
  Components: Map
Affects Versions: 4.0-beta-1
Reporter: Thomas Vahrst
Priority: Minor

 This issue addresses a findbugs issue: 
 {quote}
 org.apache.commons.collections.map.MultiKeyMap.clone() does not call 
 super.clone()
 {quote}
 The current clone() implementation creates a new MultiKeyMap instance. This 
 will lead to problems when clone() is invoked on subclasses of MultiKeyMap. 
 This is a corresponding junit test which fails:
 {code}
 class MultiKeyMapTest
 // Subclass to test clone() method
 private static class MultiKeyMapSubclass extends MultiKeyMapString, 
 String{
 }
 public void

[jira] [Commented] (COLLECTIONS-441) MultiKeyMap.clone() should call super.clone()

2013-02-02 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569649#comment-13569649
 ] 

Thomas Vahrst commented on COLLECTIONS-441:
---

In the suggested solution, the decorated map itself (an AbstractHashedMap 
instance) is cloned and then filled into the new MultiKeyMap instance. The 
clone() method of AbstractHashedMap contains another findbugs issue: it returns 
null in the case of a CloneNotSupportedException:

{quote}
org.apache.commons.collections.map.AbstractHashedMap.clone() may return null
{quote}

Instead of returning null, throwing a RuntimeException makes findbugs happy ;-)

{code}
/**
 * Clones the map without cloning the keys or values.
 * p
 * To implement codeclone()/code, a subclass must implement the
 * codeCloneable/code interface and make this method public.
 *
 * @return a shallow clone
 */
@Override
@SuppressWarnings(unchecked)
protected AbstractHashedMapK, V clone() {
try {
final AbstractHashedMapK, V cloned = (AbstractHashedMapK, V) 
super.clone();
cloned.data = new HashEntry[data.length];
cloned.entrySet = null;
cloned.keySet = null;
cloned.values = null;
cloned.modCount = 0;
cloned.size = 0;
cloned.init();
cloned.putAll(this);
return cloned;
} catch (final CloneNotSupportedException ex) {
   // return null; // should never happen.
   throw new RuntimeException(ex); // should never happen. 
}
}
{code}

 MultiKeyMap.clone() should call super.clone()
 -

 Key: COLLECTIONS-441
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-441
 Project: Commons Collections
  Issue Type: Improvement
  Components: Map
Affects Versions: 4.0-beta-1
Reporter: Thomas Vahrst
Priority: Minor

 This issue addresses a findbugs issue: 
 {quote}
 org.apache.commons.collections.map.MultiKeyMap.clone() does not call 
 super.clone()
 {quote}
 The current clone() implementation creates a new MultiKeyMap instance. This 
 will lead to problems when clone() is invoked on subclasses of MultiKeyMap. 
 This is a corresponding junit test which fails:
 {code}
 class MultiKeyMapTest
 // Subclass to test clone() method
 private static class MultiKeyMapSubclass extends MultiKeyMapString, 
 String{
 }
 public void testCloneSubclass(){
 MultiKeyMapSubclass m = new MultiKeyMapSubclass();
 
 MultiKeyMapSubclass m2 = (MultiKeyMapSubclass) m.clone();
 
 }
 {code}
 Instead of creating a new MultiKeyMap instance, the clone() method should 
 invoke super.clone() which leads in Object.clone(). This always returns an 
 object of the correct type. 
 {code}
 class MultiKeyMap{
 /**
  * Clones the map without cloning the keys or values.
  *
  * @return a shallow clone
  */
 @Override
 public MultiKeyMapK, V clone() {
try {
 MultiKeyMapK,V m = (MultiKeyMapK, V) super.clone();
 AbstractHashedMapMultiKey? extends K, V del = 
 (AbstractHashedMapMultiKey? extends K, V)decorated().clone();
 
 m.map = del;
 ((AbstractMapDecoratorK,V)m).map = (Map) del;
 return m;
 } catch (CloneNotSupportedException ex) {
 throw new RuntimeException (ex);  // this should never happen...
 }
 }
 {code}
 *Note*
 For serialisation compatibilty reasons to commons collections V.3.2,  
 MultiKeyMap contains a map reference (the decorated map) which hides the same 
 field in the super class AbstractMapDecorator. This is quite 'ugly' to 
 understand and maintain.
 Should we consider to break the compatibility to the 3.2 version? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-01-30 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566703#comment-13566703
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

Mmmh, I don't understand my own comment any more... Must have been tired. So 
you are right: the sorting example is nonsense, please ignore it. 

I agree to keep the class - I'll try to write some additions to the javadoc 
comment for the subList() method to clarify the behavior... 

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-27 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563907#comment-13563907
 ] 

Thomas Vahrst commented on COLLECTIONS-322:
---

I think, the generic way you propose is ok. I suggest to close the issue.
Thomas.

 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, nodelistAsIterable.patch, 
 patch.txt, TestNodeListAsCollection.java


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-26 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-322:
--

Attachment: nodelistAsIterable.patch

I implemented the suggested Utility methods, which provide an Iterable for a 
given NodeList or ParentNode. See nodelistAsIterable.patch

I chose IteratorUtils as implementation class, I found this class matching best 
 for the new services.

The util methods now allow easy iteration over org.w3c.NodeLists or ChildNodes 
of a given parent node:

{code}
for(Node childNode : IteratorUtils.asIterable(parentNode){
  ... do something;
}

{code}





 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, nodelistAsIterable.patch, 
 patch.txt, TestNodeListAsCollection.java


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-26 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563432#comment-13563432
 ] 

Thomas Vahrst edited comment on COLLECTIONS-322 at 1/26/13 10:29 AM:
-

I implemented the suggested Utility methods, which provide an Iterable for a 
given NodeList or ParentNode. See nodelistAsIterable.patch

I chose IteratorUtils as implementation class, I found this class matching best 
 for the new services.

The util methods now allow easy iteration over org.w3c.NodeLists or ChildNodes 
of a given parent node:

{code}
Node parentNode = ...;

for(Node childNode : IteratorUtils.asIterable(parentNode){
  ... do something;
}

{code}





  was (Author: t.vahrst):
I implemented the suggested Utility methods, which provide an Iterable for 
a given NodeList or ParentNode. See nodelistAsIterable.patch

I chose IteratorUtils as implementation class, I found this class matching best 
 for the new services.

The util methods now allow easy iteration over org.w3c.NodeLists or ChildNodes 
of a given parent node:

{code}
for(Node childNode : IteratorUtils.asIterable(parentNode){
  ... do something;
}

{code}




  
 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, nodelistAsIterable.patch, 
 patch.txt, TestNodeListAsCollection.java


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-01-26 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563537#comment-13563537
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

As already stated in the javadoc of SetUniqueList, this class does not adhere 
to the api contract of java.util.List. The class name as well as the 
implemented interface (java.util.List) implies the behavior of a List, but that 
is not true. Several methods violate the List contract and state this in its 
javadocs. 

Furthermore: some javadocs are not clear enough about the contract violation. 
For example the javadoc of the 'add()' method states a 'violation' of the api 
because the method may return 'false'. But this method also violates the 
java.util.List *semantics*, because the specified element is not only added, an 
other element is possibly removed during the invocation. 

Imagine a generic sort algorithm for lists, which internal moves elements in 
the list by *first* adding the element at the new position and then removing 
the element at the old position. This algorithm would probably remove most of 
the elements in the list... (Btw: this test fails with an 
UnsupportedOperationException:
{code}
  ListString list = new ArrayListString();
  list.addAll( Arrays.asList(one, two, three, four, five, six, 
seven, eight, nine, ten));
  SetUniqueListString uniquelist = SetUniqueList.setUniqueList(list);

{code}

In my opinion this jira issue concerning the subList() behavior cannot be 
solved in a way that makes the behavior expectable for the user. So instead of 
providing an implementation which may work in most cases but sometimes fails 
and describing this strange behavior (it took some time to understand the 
issue...) in the method's javadoc, I would suggest to throw an 
UnsupportedOperationException.

I personally would consider removing the whole class. Many developers use the 
apache commons classes as code reference for their own concrete coding problems 
and SetUniqueList isn't a good example of the decorator pattern - as stated 
above. (And in addition violates the liskov substitution principle). The better 
solution is already described in SetUniqueList's javadoc:

{code}
 * The {@link org.apache.commons.collections.set.ListOrderedSet ListOrderedSet}
 * class provides an alternative approach, by wrapping an existing Set and
 * retaining insertion order in the iterator.
{code}

What do yout think? Any comments?

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

2013-01-26 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563537#comment-13563537
 ] 

Thomas Vahrst edited comment on COLLECTIONS-310 at 1/26/13 4:32 PM:


As already stated in the javadoc of SetUniqueList, this class does not adhere 
to the api contract of java.util.List. The class name as well as the 
implemented interface (java.util.List) implies the behavior of a List, but that 
is not true. Several methods violate the List contract and state this in its 
javadocs. 

Furthermore: some javadocs are not clear enough about the contract violation. 
For example the javadoc of the 'add()' method states a 'violation' of the api 
because the method may return 'false'. But this method also violates the 
java.util.List *semantics*, because the specified element is not only added, an 
other element is possibly removed during the invocation. 

Imagine a generic sort algorithm for lists, which internal moves elements in 
the list by *first* adding the element at the new position and then removing 
the element at the old position. This algorithm would probably remove most of 
the elements in the list... (Btw: this test fails with an 
UnsupportedOperationException:
{code}
  ListString list = new ArrayListString();
  list.addAll( Arrays.asList(one, two, three, four, five, six, 
seven, eight, nine, ten));
  SetUniqueListString uniquelist = SetUniqueList.setUniqueList(list);

  Collections.sort(uniquelist);

{code}

In my opinion this jira issue concerning the subList() behavior cannot be 
solved in a way that makes the behavior expectable for the user. So instead of 
providing an implementation which may work in most cases but sometimes fails 
and describing this strange behavior (it took some time to understand the 
issue...) in the method's javadoc, I would suggest to throw an 
UnsupportedOperationException.

I personally would consider removing the whole class. Many developers use the 
apache commons classes as code reference for their own concrete coding problems 
and SetUniqueList isn't a good example of the decorator pattern - as stated 
above. (And in addition violates the liskov substitution principle). The better 
solution is already described in SetUniqueList's javadoc:

{code}
 * The {@link org.apache.commons.collections.set.ListOrderedSet ListOrderedSet}
 * class provides an alternative approach, by wrapping an existing Set and
 * retaining insertion order in the iterator.
{code}

What do yout think? Any comments?

  was (Author: t.vahrst):
As already stated in the javadoc of SetUniqueList, this class does not 
adhere to the api contract of java.util.List. The class name as well as the 
implemented interface (java.util.List) implies the behavior of a List, but that 
is not true. Several methods violate the List contract and state this in its 
javadocs. 

Furthermore: some javadocs are not clear enough about the contract violation. 
For example the javadoc of the 'add()' method states a 'violation' of the api 
because the method may return 'false'. But this method also violates the 
java.util.List *semantics*, because the specified element is not only added, an 
other element is possibly removed during the invocation. 

Imagine a generic sort algorithm for lists, which internal moves elements in 
the list by *first* adding the element at the new position and then removing 
the element at the old position. This algorithm would probably remove most of 
the elements in the list... (Btw: this test fails with an 
UnsupportedOperationException:
{code}
  ListString list = new ArrayListString();
  list.addAll( Arrays.asList(one, two, three, four, five, six, 
seven, eight, nine, ten));
  SetUniqueListString uniquelist = SetUniqueList.setUniqueList(list);

{code}

In my opinion this jira issue concerning the subList() behavior cannot be 
solved in a way that makes the behavior expectable for the user. So instead of 
providing an implementation which may work in most cases but sometimes fails 
and describing this strange behavior (it took some time to understand the 
issue...) in the method's javadoc, I would suggest to throw an 
UnsupportedOperationException.

I personally would consider removing the whole class. Many developers use the 
apache commons classes as code reference for their own concrete coding problems 
and SetUniqueList isn't a good example of the decorator pattern - as stated 
above. (And in addition violates the liskov substitution principle). The better 
solution is already described in SetUniqueList's javadoc:

{code}
 * The {@link org.apache.commons.collections.set.ListOrderedSet ListOrderedSet}
 * class provides an alternative approach, by wrapping an existing Set and
 * retaining insertion order in the iterator.
{code}

What do yout think? Any comments?
  
 Modifications of a

[jira] [Commented] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-26 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563743#comment-13563743
 ] 

Thomas Vahrst commented on COLLECTIONS-322:
---

There is a small sample code in the javadoc of 
IteratorUtils.nodelistIterator(Node) which doesn't match.:
{code}
* Convenience method, allows easy iteration over NodeLists:
 * pre
 *   for(Node childNode : IteratorUtils.asIterable(node)){
 * ...
 *   }
 * /pre

{code}

Should now be :

{code}
* Convenience method, allows easy iteration over NodeLists:
 * pre
 *   IterableNode iterable = IteratorUtils.nodeListIterator(node);
 *   for(Node childNode : IteratorUtils.asIterable(iterable)){
 * ...
 *   }
 * /pre

{code} 

... or perhaps better using the iterator in a while loop:

{code}
* Convenience method, allows easy iteration over NodeLists:
 * pre
 *  IteratorNode iterator = IteratorUtils.nodeListIterator(nodeList);
 *  while(iterator.hasNext()){
 *  Node childNode = iterator.next();
 *  ...
 *  }
 * /pre
{code}


 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, nodelistAsIterable.patch, 
 patch.txt, TestNodeListAsCollection.java


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-19 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558035#comment-13558035
 ] 

Thomas Vahrst commented on COLLECTIONS-322:
---

proposal for an implementation for NodeListAsList, with Junit Tests. 

 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, 
 TestNodeListAsCollection.java, vcs-diff2762905948687805364.patch


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-19 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-322:
--

Attachment: vcs-diff2762905948687805364.patch

 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, 
 TestNodeListAsCollection.java, vcs-diff2762905948687805364.patch


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-19 Thread Thomas Vahrst (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558035#comment-13558035
 ] 

Thomas Vahrst edited comment on COLLECTIONS-322 at 1/19/13 3:50 PM:


proposal for an implementation for NodeListAsList, with Junit Tests. 

NodeListAsList implements the Unmodifiable interface, because the 
org.w3c.NodeList has not support for adding/removing items. 
In most cases the org.w3c.NodeList is used to iterate over the children of a 
parent node. So it may be a better idea to provide a NodeListUtils class with 
methods like
{code}
  IterableNode NodeListUtils.asIterable(org.w3c.NodeList)  
  IterableNode NodeListUtils.getChildNodesAsIterable(org.w3c.NodeList)
{code}
instead of NodeListAsList. NodeListAsList could then be made a private inner 
class of NodeListUtils. 

  was (Author: t.vahrst):
proposal for an implementation for NodeListAsList, with Junit Tests. 
  
 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, 
 TestNodeListAsCollection.java, vcs-diff2762905948687805364.patch


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-19 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-322:
--

Attachment: (was: vcs-diff2762905948687805364.patch)

 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, patch.txt, 
 TestNodeListAsCollection.java


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

2013-01-19 Thread Thomas Vahrst (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-322:
--

Attachment: patch.txt

 Adds a Collections wrapper around the w3c NodeList
 --

 Key: COLLECTIONS-322
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
 Project: Commons Collections
  Issue Type: Improvement
  Components: List
Reporter: Hasan Diwan
Priority: Minor
 Fix For: 4.0

 Attachments: NodeListAsCollection.java, patch.txt, 
 TestNodeListAsCollection.java


 org.w3c.dom.NodeList is defined as an abstract collection of Nodes and 
 java.util.List is defined as An ordered collection (also known as a 
 sequence). The user of this interface has precise control over where in the 
 list each element is inserted. The user can access elements by their integer 
 index (position in the list), and search for elements in the list.. It 
 seemed similar enough, so I did an implementation of the useful methods, 
 while throwing the appropriate exception when the method wouldn't make sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Updated] (COLLECTIONS-444) SetUniqueList may become inconsistent

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Created] (COLLECTIONS-441) MultiKeyMap.clone() should call super.clone()

[jira] [Updated] (COLLECTIONS-441) MultiKeyMap.clone() should call super.clone()

[jira] [Commented] (COLLECTIONS-441) MultiKeyMap.clone() should call super.clone()

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Commented] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Comment Edited] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[jira] [Commented] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Commented] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Comment Edited] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList

36 matches

Site Navigation

Mail list logo

Footer information