Problem building seshat

[keilw]

At the moment at least on Windows it is not possible to build Seshat.

    [javac] Compiling 8 source files to C:\Users\...\git\seshat\target\classes\META-INF\versions\10
C:\Users\...\git\seshat\src\main\java_10\tech\uom\seshat\LinearConverter.java:315: error: unmappable character (0x81) for encoding windows-1252
     *    t = (x⋅scale� + offset�) ∕ divisor�

The project encoding is supposed to be UTF-8 but somehow I don't see it enforced in the POM. It could be a reason why it works on some (Linux or Mac) systems while failing on Windows. Otherwise possible the AntRun goals have an encoding issue.

[desruisseaux]

You are right, the source encoding was not specified in the maven-antrun-plugin configuration. Thanks for reporting! I just added a declaration. Do you have a chance to test again?

[keilw]

Maven Update still won't pick up the necessary JVM (Java 10) but Maven can build now. Thanks for the quick response. Are there any JUnit tests demonstrating how Length rather than Quantity<Length> can be used, is that castOrCopy()?

[desruisseaux]

Thanks for confirmation. Yes, castOrCopy can be used but is not mandatory; you can just cast directly to the target type. Example:

Quantity<Length> a;       // Any length created by Seshat.
Length b = (Length) a;    // Will work.

The castOrCopy method is there for interoperability with other implementations: if the given Unit can not be casted (because it come from an implementation other than Seshat and that other implementation does not allow direct casting), then castOrCopy will copy the quantity into something producing the same effect.

[keilw]

Having to cast is not so elegant, but as an alternative why not. A few attendees at DWX made suggestions for future versions of the API as well, including methods that would take the Q (e.g. Length) directly. I know we had this idea once or twice, but while it could work for add() or subtract() how should it work in the API signature for multiply() or divide()?

There was also a suggestion of adding a Quantity.of(Number, Unit) instead of implementation classes like Quantities or a QuantityFactory implementation. I'm not sure, if a simple Unit.of() or Quantity.of() will work without the class being passed in addition?

[keilw]

Anyway we should not look into either of these ideas before a new major version like 2.1 or 3.x. Probably once Valhalla/value types are available. Any idea about https://github.com/unitsofmeasurement/unit-api/issues/195? The priority is used if there were any duplicate names among services, but could it be used to sort the available() services without breaking anything?

[desruisseaux]

Returning Length instead of Quantity<Length> is easy for operations that do not change the unit dimension, like addition and subtraction. However it is not possible in Java for all operations that compute a new unit dimension, like multiply and divide. For those operations we will have to stick to Quantity<?> for the foreseeable future.

[keilw]

As long as the existing operations don't conflict with them we could explore adding alternate methods like add(Q) but since the others like multiply() or divide() have to return a Quantity I wouldn't replace them, otherwise it would seem inconsistent. Anyway, closing this ticket as it seems resolved, please other ideas for future improvements, let's raise them in https://github.com/unitsofmeasurement/unit-api/issues.