Ppc64le builds failed on Travis-ci

[sanjaymsh]

Hi,

I am enabling the ppc64le build on travis-ci. So added arch: ppc64le in .travis.yml. but builds are failing for ppc64le.
Below are the log error summary:

"[ERROR] Tests run: 20, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.039 s <<< FAILURE! - in javax.measure.test.MetricPrefixTest
[ERROR] testYocto Time elapsed: 0.014 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <9.999999999999999E-28> but was: <1.0000000000000002E-27>
at javax.measure.test.MetricPrefixTest.testYocto(MetricPrefixTest.java:196)
[ERROR] testZepto Time elapsed: 0 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <s * 1.0E-21> but was: <s * 1.0000000000000001E-21>
at javax.measure.test.MetricPrefixTest.testZepto(MetricPrefixTest.java:212)"

There are 2 tests(testYocto & testZepto) from the file unit-api/src/test/java/javax/measure/test/MetricPrefixTest.java which are failing.
For full error log please look into the link: https://travis-ci.com/github/sanjay-cpu/unit-api/builds/185148918

Please have a look into the issue.

Thanks !!

[keilw]

Hi,
Thanks for adding those. I don't have any PPC64 to test that I'm afraid. Keep in mind, this is a minimalistic dummy implementation behind those tests, therefore if it e.g. used double we can try to address it by using BigDecimal instead, otherwise I see little value building it against so many different platforms, because the API itself has no implementation.
Especially "org.opentest4j.AssertionFailedError: expected: <s * 1.0E-21> but was: <s * 1.0000000000000001E-21>" sounds pretty bogus it might be wrong data types, thus will have a look if we could use BD here (the older versions of the API needed to keep that out, because it was meant to run on Java SE 7 or Java ME 8 Embedded, but that is not a criteria anymore.

[keilw]

I can't see your fork where the YML is changed, and the mentioned Travis job is not automatically triggered by the master of this repository, so please merge the master and see, if BigDecimal makes a change? We cannot create tests only for PPC64, so if the numeric representation of the JDK was really that different, we may have to leave that for now, because the simple implementations are not as sophisticated as e.g. Indriya or Seshat, where it would be an interesting idea, but for the API it makes less sense.

[keilw]

It looks like PPC has more decimal places even with BigDecimal. The only way to fix this here is to limit the number of decimal places in the string representation of those test units. Those are not really comparable to the actual implementations because they are a minimalistic implementation. This looks like it should be working.

[keilw]

Ok, done, I also added Java 15 which just went Final.