Skip to main content

[jsr363-experts] Re: Remove javax.measure.format.Parser interface

  • From: Leonardo Lima < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: Remove javax.measure.format.Parser interface
  • Date: Tue, 16 Dec 2014 07:46:35 -0200

I agree that IF we should have parsing in the API, it has to be optional.

I still didn't see value in it from the device PoV, but maybe from a
server-side it can have some value. I suggest we leave it as is for now and
explore more the use case.

Regards,
Leonardo.

On Sat, Dec 13, 2014 at 1:28 PM, Werner Keil 
< >
 wrote:
>
> That would be too limiting, and the Spec already explains what Parser is
> meant for. At least for UCUM there are plenty of use cases same for unit
> libraries OGC used.
> That's why it is a separate more versatile element. Effectively it's
> something JSRs like 310 and other parts of Java 8 forgot to handle
> properly, but use cases like UCUM alone justify we do this. It makes no
> sense to push this into RI as the UnitFormat type itself uses it, but a
> UCUM parser or any other parser (which may return a Unit but also a
> Quantity or similar, thus UnitUnparsableException was too specific and
> cause exception cluttering since we'll need a "QuantityUnparsableException"
> etc. then too;-) will not need the format() method in UnitFormat, that's
> why they are separate. If there's time I'll add this type of UCUM parser.
> SWE-Common got exactly the same, org,vast.unit.UnitParser, the main
> difference is ours can also be  used by UnitFormat;-)
>
> Modularity and optionality serve devices that won'd need formatting,
> especially on ME. Leonardo has just scratched a few of these devices, but
> he mentioned their footprint is extremely low. So keeping formatting and
> parsing in an optional  package makes it easier to be used even on the
> smallest devices.  If we clutter the root package we'll deprieve a very
> large portion of current and more importntly future IoT devices of the
> chance to use this JSR.
>
> Werner
>
> On Sat, Dec 13, 2014 at 12:35 PM, Martin Desruisseaux <
>  >
>  wrote:
>>
>>  I would like to propose (again) to remove the
>> javax.measure.format.Parser interface. I think that a general-purpose
>> Parser interface is out of JSR-363 scope (why would someone who need
>> such general-purpose interface would use the JSR-363 one instead than the
>> one of any other projects?). Furthermore, the current Parser interface
>> misses its generality intend, since its parse method declares a
>> ParserException which extends MeasurementException.
>>
>> My proposal:
>>
>>    - Remove Parser (move its method into UnitFormat)
>>    - Rename ParserException as UnparseableUnitException. This exception
>>    is already linked to units of measurement anyway through its
>>    MeasurementException parent class.
>>    - Since we have only 2 types, move them in the javax.measure package.
>>
>> Martin
>>
>>


[jsr363-experts] Remove javax.measure.format.Parser interface

Martin Desruisseaux 12/13/2014

[jsr363-experts] Re: Remove javax.measure.format.Parser interface

Werner Keil 12/13/2014

[jsr363-experts] Re: Remove javax.measure.format.Parser interface

Leonardo Lima 12/16/2014

[jsr363-experts] Re: Remove javax.measure.format.Parser interface

Martin Desruisseaux 12/16/2014

[jsr363-experts] Re: Remove javax.measure.format.Parser interface

Werner Keil 12/16/2014
 
 
Close
loading
Please Confirm
Close