암초보

- Comparator 사용시

Comparator의 구현체를 파라미터로 넘김.

=> Collections.sort(list, comparator);

- Comparable 사용시...

Comparable 구현체의 list를 파라미터로 넘김

=> Collections.sort(list);

차이점은 list안에 들어가는 class를 수정하느냐와 마느냐,,,

그리고 정렬할때 비교 방식을 바꾸느냐 마느냐의 차이인듯...

list같은 걸 돌리는 for문에서

remove를 호출할 때 발생...

java.util.ConcurrentModificationException

이유는 index 문제.. 생각해보면 금방 알 수 있듯이..

증가된 index와 list의 size를 비교하는데 있어서 문제가 발생하게된다.

아래와 같은 방법으로 해결하면 됩니다.

1. Take a copy of the collection , iterate over the copy and remove elements from the original. 

2. During iteration, build up a set of elements to remove, and then perform a bulk removal after iteration has completed.

3. Use an List implementation which can deal with concurrent modifications, like the CopyOnWriteArrayList

대충 이런식이 좋은거 같다.

List<String> list = new ArrayList<String>();
...
for (Iterator<String> iterator = list.iterator(); iterator.hasNext(); ) {
    String value = iterator.next();
    if (value.length() > 5) {
        iterator.remove();
    }
}

List<String> toRemove = new ArrayList<String>();
for (String fruit : list) {
    if ("banane".equals(fruit))
        toRemove.add(fruit);
    System.out.println(fruit);
}
for (String fruit : toRemove) {
    list.remove(fruit);
}

1. 플러그인의 업그레이드 버젼이나 새로운 이클립스 버젼이 나올때마다, 이클립스에 스프링 관련 플러그인을 조합하여 새로운 IDE를 구성해야 하는 부담이 없음
2. 이에 따라오는, 플러그인의 버전 호환성 문제
3. STS는 스프링 팀이 매번 베타버전, RC 버전을 거쳐가면서 플러그인의 호환성 문제나 버전 이슈를 충분히 검증해 준다.

결론 : 스프링소스가 제공하는, 플러그인 조합이 완료된 STS를 사용하는 편이 유리함.