Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BB050EF1E for ; Thu, 7 Feb 2013 14:49:16 +0000 (UTC) Received: (qmail 72902 invoked by uid 500); 7 Feb 2013 14:49:16 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 72787 invoked by uid 500); 7 Feb 2013 14:49:16 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 72687 invoked by uid 99); 7 Feb 2013 14:49:16 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Feb 2013 14:49:16 +0000 Date: Thu, 7 Feb 2013 14:49:16 +0000 (UTC) From: "Thomas Neidhart (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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