Add a simple cache for ComparableVersions

[TobiX]

This is a simple fix for #869.

This can improve performance in pathetic corner cases by up to 50%. From some example executions (something similar as the pathetic case in #869):

Before:

[INFO] Total time:  01:51 min

After:

[INFO] Total time:  43.714 s

In this first implementation, the cache is unbounded. In all my tests it never grew over ~1500 entries, but it might keep some memory active in pathetic cases...

PS: I used a ConcurrentHashMap, because I don't know how parallel (if at all?) Maven can run this code...

[jarmoniuk]

I was looking into moving this to Maven level. However:

Neither ComparableVersion nor DefaultArtifactVersion are immutable: parseVersion will mutate their state. If this is the case, they mustn't be cached.

In the plugin, we must therefore forbid ComparableVersion users from ever using parseVersion() on the instance retrieved from cache.

[TobiX]

@ajarmoniuk Oh right, parseVersion is public. That's unfortunate (aka. a bug waiting to happen 😉)... I found no local users of that method, but it might be considered API-breaking to make it private... Would an "immutable" subclass be a viable solution?

[jarmoniuk]

@TobiX well, that's indeed unfortunate. I wanted to promote your cache to maven-core, but looked into it closer and discovered that it's in fact mutable (because of that method). The interface is a bit... botched and it would be really nice to change it, but - Maven is big and who knows who depends on it.

What's more -- I saw that we could actually cache DefaultArtifactVersion instances, since they are also immutable except for that unfortunate method, which is also part of the interface. And we're actually constructing a lot more of those objects, and use them for comparison.

So, instead, I've introuced this change: #898

we're caching DefaultArtifactVersions instead and only in the plugin -- on condition that we will never call parseVersion in our plugin.

[jarmoniuk]

FYI: https://issues.apache.org/jira/browse/MNG-7659