[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
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
[
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] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643093#comment-13643093
]
Thomas Neidhart commented on COLLECTIONS-310:
-
Hi Thomas,
I did not mean to criticize your outstanding effort (and your choice was
perfectly reasonable).
Maybe we should really do as you suggest and return an unmodifiable list for
4.0 to be on the safe side (although you put so much effort into this issue).
What do you think?
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
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642120#comment-13642120
]
Thomas Neidhart commented on COLLECTIONS-310:
-
I did take another look at your provided test-cases and I do not agree with the
following behavior:
* adding an element in a subList that is contained in the backing list results
in moving the element to the new location
This is not what I would expect, and also the backing list does not do this,
e.g. when calling add(obj) where obj is already contained in the list will
result in no change at all. I think we should make it clear, that the returned
subList is *backed* by a SetUniqueList, thus adding elements that are in the
backing list but not in the subList should not be added at all, as they are
already present, just not visible in this view.
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,
[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13604567#comment-13604567
]
Thomas Neidhart commented on COLLECTIONS-310:
-
Hi Thomas,
I have looked through both variants, but am still undecided.
Generally, I think we should keep the inheritance to
AbstractSerializableListDecorator, as the class should remain a decorator.
Adding more fields to the actual class also has the down-side that we need to
make sure that serialization still works correctly, so I would prefer to create
an inner static View class, which is returned when calling subList.
I will further play with your patch, and give you more feedback.
Thanks!
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
[
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] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
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] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
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] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13573550#comment-13573550
]
Thomas Neidhart commented on COLLECTIONS-310:
-
Right now, when calling subList, a new, independent SetUniqueList is created
which is filled with elements from the backing list of the specified range.
The problem comes from the fact that this new SetUniqueList does not check for
uniqueness in the backing list, but only in the sublist. If we would create an
inner class (see for example ListOrderedMap), which would delegate the calls
(after properly adjusting some arguments, e.g. calculate real index) to the
backing SeUniqueList we could support the sublist contract.
The order is maintained and the uniqueness is validated by the backing list.
What do you think?
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-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
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] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566631#comment-13566631
]
Thomas Neidhart commented on COLLECTIONS-310:
-
Hi Thomas,
I agree in general with your observation, but I do not understand your
statement 'because the specified element is not only added, an other element is
possibly removed during the invocation'.
Looking at the add method, I fail to see how this may happen. The use-case you
describe does explicitly call remove, so I wonder how this is related to the
previous statement.
This class in general should be used with a lot of care, and only if you know
exactly what you are doing, which is probably not very convincing either. I
would prefer to keep the class for now, but improve the javadoc wrt the current
limitations, which may never be fully resolved.
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-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
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-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
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] Commented: (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662689#action_12662689
]
Christian Semrau commented on COLLECTIONS-310:
--
It seems that properties of the SetUniqueList.subList are currently not tested:
The bulk tests for TestSetUniqueList are disabled.
I managed to enable them by using a copy of BulkTestSubList which is subclassed
from TestSetUniqueList instead of AbstractTestList, and which disables
extraVerify for itself and the outer test. For the bulkTestListIterator,
TestListIterator.supportsSet() must return false (but then still one test
fails).
But maybe this should be subject of a different jira issue.
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
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.
-
You can reply to this email to add a comment to the issue online.
