Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Final coordination and review of Spec, etc.
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Final coordination and review of Spec, etc.
- Date: Thu, 11 Aug 2016 10:42:25 +0200
Dear Jean-Marie/all,
Thanks a lot for the input. It seems Google Docs is a bit slow this
morning, but as Leo did could you change or propose changes to the document
directly?
Aside from this being a very late point and the PFD should reflect mostly
what the Final API/SPI looks like, I would not be comfortable putting all
format/i18n/UI related elements into SPI. Separating those concerns not
just being able to offer small enough modules (independent from each other
except in that one single case) we should see them as separate things.
Everything in SPI is a "provider" or "service" (also to provide something
defined by the API). SystemOfUnits also provides access to units, but when
you just combine a few units in a Java enum, you don't need it. You may
however require to format or parse those units without the need for a unit
system or quantity factory.
https://github.com/unitsofmeasurement/uom-impl-enum passes the TCK running
the FORMAT profile at most, but it has no need for anything in SPI or that
profile.
JCache is not modular, but there are certain concerns like JMX or its SPI
containing just one or two classes per package:
http://ignite.apache.org/jcache/1.0.0/javadoc/
CDI 2 hoping for more modularity and at to work at least on Java SE also
has at least 2 packages with just 3 or fewer elements:
http://docs.jboss.org/cdi/api/2.0.EDR1/
We can't out-rule adding something in a future version if formatting or
other needs arise. MEEP has an almost too complex number of modules and
ways they can be combined (with several of them depending on others)
Regards,
Werner
On Wed, Aug 10, 2016 at 10:48 PM, Jean-Marie Dautelle
<
>
wrote:
>
One small comment, in the Quantity API, there are missing carriage returns
>
in the example 😉
>
>
On Wed, Aug 10, 2016 at 10:44 PM, Jean-Marie Dautelle
>
<
>
>
wrote:
>
>
> Hello All,
>
>
>
> First thanks to Werner for his excellent work, the latest spec. is very
>
> clean and well written :)
>
>
>
> You will find my comments on-line.
>
>
>
> With regards to SPI package here is what I wrote:
>
>
>
> I think for the API, we should remove the format package and move
>
> UnitFormat and ParseException into the spi package. The two classes are
>
> consistent with the other interfaces already in the service provider
>
> package. Also a package with only one main interface is kind of depleted...
>
>
>
> Cheers and congratulations to all :)
>
> Jean-Marie
>
>
>
>
>
> On Wed, Aug 10, 2016 at 6:02 PM, Werner Keil
>
> <
>
>
> wrote:
>
>
>
>> In fact, we made it harder to decouple an entire module like format from
>
>> the SPI when we decided to replace generic calls like
>
>> <T> T getService(Class<T> serviceType)
>
>> in ServiceProvider with more concrete ones like
>
>> UnitFormatService
>
>> <http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/spi/UnitFormatService.html>
>
>> * getUnitFormatService
>
>> <http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/spi/ServiceProvider.html#getUnitFormatService%28%29>*
>
>> ()
>
>> Before that not even using the "format" package could have worked in
>
>> theory, ideally by moving the UnitFormatService into that package, too.
>
>>
>
>> The more concrete approach is similar to e.g. JCache, though its
>
>> CachingProvider returns more or less just one other service reference to
>
>> CachingManager and JSR 107 is not really modular (for an SE/EE environment
>
>> it probably does not need to)
>
>>
>
>> I guess only to save the usage of UnitFormat, not its declaration in the
>
>> SPI it may be a bit of an overhead to support returning a quantity factory
>
>> and unit system but not a unit format, but again, if you think it's very
>
>> beneficial, we could support it and add the necessary documentation and
>
>> TCK
>
>> changes.
>
>>
>
>> WDYT?
>
>> Werner
>
>>
>
>
>
>
>
>
>
> --
>
> It is not the strongest of the species that survives, nor the most
>
> intelligent. It is the one that is most adaptable to change. - Darwin's
>
> Origin of Species (digest)
>
>
>
>
>
>
--
>
It is not the strongest of the species that survives, nor the most
>
intelligent. It is the one that is most adaptable to change. - Darwin's
>
Origin of Species (digest)
>