DefaultGroovyMethods#unique O(n²) performance

I just tried your suggestion.
It's indeed very fast... but running the full Groovy test suites with that change yields about 11 test failures!
Do you think you could have a closer look at it and correct the patch accordingly so we don't break our tests?
Thanks in advance.

I'm only thinking here – maybe some classes don't implement Comparable#compareTo and that's the reason?

Either way, please try this variant that uses LinkedHashSet:

public static <T> Collection<T> unique(Collection<T> self) {
        if (self instanceof Set)
            return self;
        Set<T> tempSet = new LinkedHashSet<T>(self);
        try {
            self.retainAll(tempSet);
        }
        catch (UnsupportedOperationException ex) {
            self.clear();
            self.addAll(tempSet);
            // Note that, as per Javadoc, both clear and addAll may throw an UnsupportedOperationException, too. :-(
        }
        return self;
    }

I'm not sure really sure what you used the NumberAwareComparator for, do you want the output to be sorted?

unique() is preserving the original order, and NumberAwareComparator allows for comparing 1.0 and 1 and only keep one of them

Changing unique()'s behaviour (ordering and number-aware comparison) is problematic.
So the approach suggested cannot be followed.
However, we already have the exact same functionality through the toSet() method!

    public static <T> Set<T> toSet(Collection<T> self) {
        Set<T> answer = new HashSet<T>(self.size());
        answer.addAll(self);
        return answer;
    }

It supports the same complexity as your approach.
So when you need a more performant 'unique' (which doesn't care of ordering of number comparison), you can use toSet() instead of unique().

See my last comment for reference.
After some eximination, the toSet() method already works the same way as your suggested patch.
And it's problematic to change unique() as it is now, as it complies to some ordering and comparision logic which is different.

@Guillaume Laforge

> unique() is preserving the original order, and NumberAwareComparator allows for comparing 1.0 and 1 and only keep one of them

Isn't that too much of a sugar?
Or 1.0 == 1 and thus .unique must be compliant with number-aware groovy equals?

Anyway it should be documented in .unique() as it's kinda unexpected from words "using the default comparator"