"adrian(a)jboss.org" wrote : 1) The compareTo() that uses a registry to do comparison | will only work when the specific version being tested uses the registry. | This is expected. Since you need to write a comparator anyway. It's then minimal work if you also need to write a thin wrapper over existing external Version impl. btw: our VersionIMpl was changed, and it's now the same implementation as OSGi Version Except that it knows how to compare to other internal Version impls. Or when do you expect to have direct compareTo to external Version instance? Since we control all the comparison code, we/user can also introduce thin wrappers. If you let any Version type to be present in our VersionRange, then you would have to let version be Object, which is a lot less type safe than our Version approach with comparators and thin wrappers present. Not to mention that there is exactly one external Version impl present that I'm aware of. Or what did you have in mind with your 'pass the Comparator into the VersionRange check.' approach? "adrian(a)jboss.org" wrote : | Also for HashMaps/Sets, etc. | the hashCodes will likely disagree, so they are broken. What if we put this in Version | public boolean equals(Object obj) | { | if (obj instanceof Version == false) | return false; | | VersionComparatorRegistry registry = VersionComparatorRegistry.getInstance(); | return registry.compare(this, Version.class.cast(obj)) == 0; | } | | public int hashCode() | { | return toString().hashCode(); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124908#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...