Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: DeDup an ArrayList Date: Thu, 4 Aug 2016 22:41:18 -0400 Organization: Aioe.org NNTP Server Lines: 50 Message-ID: References: <21r7qb1srdvnieuufjquie2qrfujso6l7p@4ax.com> NNTP-Posting-Host: 7SK6yTFfqwlIPNBLl3l7Qg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:35198 On 8/4/2016 10:05 PM, Andreas Leitgeb wrote: > Roedy Green wrote: >> This looks like trivial task, but every time I work on it, it keeps >> ballooning in complexity. >> >> I wish to deDup an ArrayList. Any two strings equalIgnoreCase are >> considered dups. One should be removed. The order of the items should >> be otherwise be undisturbed. >> >> Part of the trouble is removing an element from an ArrayList makes you >> lose track of where you are. > > Copy to a LinkedHashMap (using the toUpperCase()'d string as key, and > the original String as value), and finally copy back to a new ArrayList... > > The LinkedHashMap will take care of maintaining the ordering, except > of course, where dups are left out. import java.util.ArrayList; import java.util.LinkedHashMap; import java.util.List; import java.util.stream.Collectors; public class ListDeDup { public static void main(String[] args) { List lst = new ArrayList<>(); lst.add("Aa"); lst.add("Bb"); lst.add("Cc"); lst.add("cC"); lst.add("bB"); lst.add("aA"); System.out.println(lst); List res = lst.stream().collect(Collectors.toMap(o -> o.toLowerCase(), o -> o, (o1,o2) -> o1, LinkedHashMap::new)).values().stream().collect(Collectors.toList()); System.out.println(res); } } > Not sure if hashing on the uppercase version of a String is strictly > equivalent to pairwise equalIgnoreCase, though. Maybe not, maybe close > enough, maybe exactly same... The performance advantage (from n-squared > to roughly n) might be worth a little slack in some corner cases. There is always the "Turkish problem", but ... Arne