Inconsistent comparing of RexsVersion objects

fva-net / rexs-api-java

The REXS API Java library contains core utility classes for the REXS interface.

Apache License 2.0

2 stars 0 forks source link

Inconsistent comparing of RexsVersion objects #133

Open johkoenig opened 2 weeks ago

johkoenig commented 2 weeks ago

The class RexsVersion has currently two methods which allow a comparison of versions: equals and compareTo. The behaviour of both is not consistent, though.

equals compares based on the name. So, if I have v1 = RexsVersion.create("1.6", 1600) and v2 = RexsVersion.create("1.6 extended", 1600), the result of equals is False.
compareTo compares on the number (internally defined as order). So, compareTo will return 0 for v1 and v2.

I propose to select one field for equality and comparison and apply it to both. I think that the numerical value of order is better suited than the name, which is of type String.

johkoenig commented 1 week ago

Some literature on this topic: https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html

It is strongly recommended (though not required) that natural orderings be consistent with equals. This is so because sorted sets (and sorted maps) without explicit comparators behave "strangely" when they are used with elements (or keys) whose natural ordering is inconsistent with equals. In particular, such a sorted set (or sorted map) violates the general contract for set (or map), which is defined in terms of the equals method.

johkoenig commented 6 days ago

This issue is a little bit more complicated than originally estimated. If we use only the numeric order as datapoint for comparison, it may happen that versions get replaced, for example it HashSets or HashMaps.

Another approach would be to compare both the name and the numeric order. However, this would make it more complicated to order the items accordingly.

karstenroethig commented 4 days ago

I suggest that we introduce a Version class that supports the Semantic Versioning format (https://semver.org/). Then we can always sort based on the actual version.

johkoenig commented 4 days ago

Good idea. The semver4j library could be used for that. Vendor-specific extensions could be marked as build info, so for example the released version 1.6.0 with ZF-specific extensions would be 1.6.0+ZF.

johkoenig commented 4 days ago

As discussed, we will follow two paths here:

A new REXS version class (working title RexsVersion2) will adopt the existing versioning scheme and remove the double-definition of string number and numeric order.
It will be adressed in the CCB to adjust the REXS versioning scheme to semantic versioning. It could be adopted for 1.7 (which would be 1.7.0 then). Realistically, however, I think this will not come before version 2.