Could AbstractUnit use the current UnitFormat instead of SimpleUnitFormat?

[keilw]

Currently the AbstractUnit base class uses the SimpleUnitFormat implementation: SimpleUnitFormat.getInstance() for parse() and toString().

Instead AbstractUnit (or even the Unit interface in a future version of the API) could call ServiceProvider.current().getFormatService().getUnitFormat() using the "default" UnitFormat implementation from the "current" ServiceProvider, allowing extention modules like UCUM defining their own UnitFormatService in a ServiceProvider with a higher priority, then that module would become the default for toString() and parse() operations of all units in an implementation.

[daniel-shuy]

Agreed. And I think the same should be done for AbstractQuantity as well (currently uses the SimpleQuantityFormat implementation).

On a related note, there is currently no AbstractQuantityFormat implementation in the UCUM module, something which I plan to create a PR for once my application to the JSR as a contributor is approved.

[keilw]

Thanks but it's a little more complicated there because the default QuantityFormat already uses SimpleQuantityFormat plus a default reasonable NumberFormat instance.

There is no need for a QuantityFormat implementation in UCUM because it does not declare its own QuantityFormat, only UnitFormat is customized there.
So the only thing to think about is combinations of the UCUMFormat instances to configure NumberDelimiterQuantityFormat but this can be done as needed, it would be a sort of convenience adding one or the other also via UCUMFormatService, but there is no need for a QuantityFormat implementation in that module.

[keilw]

For the UCUM extension, if you had a PR that makes sense along the mentioned classes like UCUMFormatService, please note, that is independent of a JCP membership, only API, RI or TCK need the Associate or higher membership level, for all the others that is good but not required.

[daniel-shuy]

You're right, sorry, I was creating a custom UCUMQuantityFormat class to use UCUMFormat instead of SimpleUnitFormat in our projects, but if AbstractUnit can be enhanced to automatically use the corresponding implementation, then AbstractUnit can be used instead, allowing the code to be agnostic to the extension modules.

[keilw]

Yes as a first step AbstractUnit could use the SPI and later (maybe a possible MR2 of JSR 385, which is why contributors like you and your company are very welcome also in this phase) even Unit itself may declare a default parse() or toString() method instead of abstract ones.