TestRunnerStatement with dynamic Parameter-list by pesse · Pull Request #96 · utPLSQL/utPLSQL-java-api

Ah.
I thought about this a lot yesterday. The thing is - we are not implementing the normal compareTo method, but we implement something which is only used by isGreaterOrEqualTo and isLessOrEqualTo.
For these 2 cases I think the comparison order is important, because the lazier "equal" depends on the base version to have a null.

Example:
Technically, when comparing 3.1.7 with 3.1.7.3085, 3.1.7 is less and not equal. That's how the comparison was before (null being treated as 0 basically).
But that's not what I want when using isGreaterOrEqualTo - I want this function to be forgiving if I only provide 3.1.7 as base, so any number in the 4th level of the comparison should be treated as being equal.
On the other hand, when I provide a specific base (e.g. 3.1.7.3085), I really expect it to be precise, so I can't treat i2 the same way in that case.

Maybe I should not use parameters here and instead write the isGreaterOrEqualTo function separately so it's more clear we're not implementing a strict compareTo here.