Issue with TCK test of UnitFormat?

[Martin Desruisseaux]

Hello Werner

As a side effect of Apache Spatial Information System (SIS) development, I created a custom implementation of JSR-363. This implementation passes all TCK tests except one, but that test failure looks like a TCK issue to me. The problem occurs in the following test:

    UnitFormatTest.testUnitFormatFormatAppendable()

The intend of that test is to verify that the UnitFormat implementation has a public format(Unit, Appendable) method. But the UnitFormatTest class at line 83 invokes the TestUtils.testHasPublicMethod(…) method with the trySuperclassFirst boolean set to true, which cause TestUtils at line 256 to invoke Class.getSuperclass(). Consequently the test is performed (in my case) on the java.text.Format class, not on the provided UnitFormat class. Since java.text.Format does not have a format(Unit, Appendable) method, the test always fails with the following stack trace:

tec.units.tck.TCKValidationException: Section 4.3: Class must implement method format([interface javax.measure.Unit, interface java.lang.Appendable]): java.lang.Appendable, but does not: java.text.Format
    at tec.units.tck.util.TestUtils.testHasPublicMethod(TestUtils.java:228)
    at tec.units.tck.util.TestUtils.testHasPublicMethod(TestUtils.java:256)
    at tec.units.tck.tests.format.UnitFormatTest.testUnitFormatFormatAppendable(UnitFormatTest.java:83)

A possible fix could be to replace the true boolean value by false at line 83 in UnitFormatTest.

    Martin

[Werner Keil]

Hello Martin,

Thanks for reporting this. Unlike some UnitFormat implementations of JSR 275 we did not extend java.text.Format. Something also practiced by a couple of other JSRs like 310 or 354.

Will try to see, if this can be done without breaking the 3 existing implementations. If so it could be easy. Other JSRs like 107 have released 1.0.1 updates to their TCKs without a formal MR (which would be needed to fix the API license, something that still remains undone) so if that could help without breaking existing implementations, we can do it. If it did break implementations, we'd have to look closer at it.

AbstractUnitFormat could be a main reason for that switch. I really cannot predict if this test still worked for all implementations without it.

Regards,

Werner

[Werner Keil]

Martin,

I gave it a try and it works without breaking compatibility with the RI it seems. Will have to run against the other 2 official implementations but it should work there, too.

Aside from these 2 adjustments (not using a deprecated method in 43-A4 has no effect on the outcome) it allows a few small improvements mostly to JavaDoc or in the POM. E.g. no longer pointing to java.net JIRA which will go away, so it is a welcome opportunity for a minor fix pack 1.0.1.

Hoping to get it out no later than the weekend.

Regards,

Werner

[Werner Keil]

As I should meet Hazelcast EC Rep Chris (https://jcp.org/en/press/news/ec-feature#engelbert) who speaks at the local JUG meeting tonight, I may be able to ask him, how they got the list of compatible implementations:

https://jcp.org/aboutJava/communityprocess/implementations/jsr107/index.html

JSR 107 has at least one Apache project that's compatible, so we'd love to see e.g. SIS and other implementations passing the TCK listed on a similar page.

As Chris talks about a project related to the JDK (Panama) I may also ask him if they know any common OpenJDK or JCP driven guideline for Jigsaw package names. Until then, please let's use what Dmitry said and JSR 374 uses (it also matches JDK internal ones that contain "javax" packages)

Regards,

Werner

[Werner Keil]

Martin/all,

Please note, while also brushing a few things mostly in JavaDoc I officially released a service Update 1 of the TCK last night: https://github.com/unitsofmeasurement/unit-tck

This solves the issue, so you can use the latest TCK build.

Between now and JavaOne I also plan to share the list of compatible implementations with Heather/PMO.

Is SIS using JSR 363 already released or still a snapshot?

Regards,

Werner