Exception logged at startup with KILOMETRES_PER_HOUR

[sebastienjust]

First, thank you for this awesome library and congratulations for having JSR 363 approved by the JCP .

When accessing for the first time to the default UnitFormat this way :
ServiceProvider.current().getUnitFormatService().getUnitFormat()

This exception gets logged :
Feb 09, 2017 7:29:57 PM tec.uom.se.format.SymbolMap <init> SEVERE: Error java.lang.NoSuchFieldException: KILOMETRES_PER_HOUR at java.lang.Class.getField(Class.java:1703) at tec.uom.se.format.SymbolMap.<init>(SymbolMap.java:113) at tec.uom.se.format.SymbolMap.of(SymbolMap.java:139) at tec.uom.se.format.EBNFUnitFormat.<init>(EBNFUnitFormat.java:214) at tec.uom.se.format.EBNFUnitFormat.<clinit>(EBNFUnitFormat.java:169) at tec.uom.se.internal.format.DefaultUnitFormatService.<init>(DefaultUnitFormatService.java:62) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) at java.util.ServiceLoader$1.next(ServiceLoader.java:480) at tec.uom.se.spi.DefaultServiceProvider.loadServices(DefaultServiceProvider.java:139) at tec.uom.se.spi.DefaultServiceProvider.getServices(DefaultServiceProvider.java:96) at tec.uom.se.spi.DefaultServiceProvider.getService(DefaultServiceProvider.java:100) at tec.uom.se.spi.DefaultServiceProvider.getUnitFormatService(DefaultServiceProvider.java:166)

It seems related to the fact that in uom-se-1.0.3.jar!/tec/uom/se/internal/format/messages.properties reference to tec.uom.se.unit.Units.KILOMETRES_PER_HOUR=km/h tries to match with

Units.class:
static final Unit KILOMETRES_PER_HOUR = KILOMETRE_PER_HOUR;
this way defined as an alias for Units.KILOMETRE_PER_HOUR

It doesn't seem to cause problems in daily usage but it may be worth to point this issue.

We are using this maven dependency, which brings the unit-api 1.0 as a transitive dependency :

<dependency> <groupId>tec.uom</groupId> <artifactId>uom-se</artifactId> <version>1.0.3</version> </dependency>

Thank you

[keilw]

Thanks for your appreciation and raising that. There was a parallel pase with the plural deprecated. As there are other systems and standards like Unicode CLDR / ICU4J using the singular in such case, we wanted to be match those rather than the totally inconsistent mess the JDK got. java.util.Calendar defined constants like HOUR ages ago. The lower level Concurrency tools (yet also under java.util.concurrent) started calling the same HOURS from Java 5. And since JSR 310 (java.time) initially used that new but inconsistent enum it also called its own enum with a plural version. The Unicode standard is more important for us in that case. It supports pluralization but only when you format things (based on whether it's "1 h" or "10 h") and creators of the Unicode standard were also involved in the original Date/Time definitions. While those who added this enum to Java 5 seemed less aware or interested in those standards. Sorry for the inconvenience. The snapshot version ("1.0.4-SNAPSHOT") should have this addressed pretty much as of now. We'll publish a new release as soon as we can.

[keilw]

Finished with 1.0.4-SNAPSHOT. I hope you may be able to use that version already, otherwise 1.0.4 Milestone should be out soon. Thanks for bringing it to our attention.

[sebastienjust]

Thank you very much ! that was a lightspeed fix :)