Skip to main content

Re: Other experts

  • From: Werner Keil < >
  • To:
  • Subject: Re: Other experts
  • Date: Fri, 17 Oct 2014 16:09:38 +0200

Leo/all,

Thanks for the message. Will briefly reply both, you mostly quoted Otavio's
or Martin's recent thread, but may have seen my caveat about the judgment
and design conflicts between various ends of the JDK as early as JDK 1.x or
Java 5. When it was officially still done by Sun alone, but especially
things like Date/Calendar came from a planned IBM/Apple(!) joint venture
named Taligent/Pink, which few pieces left turned into OTI, a group that
created large portions of Eclipse;-)

Speaking of which, the IoT project there is interested, and we should
involve them or other users (including Jean-Marie, whether JScience or
Embedded/Realtime Java usage at Airbus, those are also are users who'd
implement the API more likely than using the RI;-) but not every
"downstream" user will want to join the EG, too. I'm not even sure, if
their company is still a JCP member?
Many feel happy if Eclipse represents them as a whole;-)

Unlike the use of JSR-275 by GeoAPI (lead and represented by Martin) so far
there are solutions and implementations like JScience or UOMo (already at
Eclipse) offering such arithmetic on an implementation level alone.

There are not too many serious Unit libraries, if you Google it with Java
you'll find this JSR beside 275 or JScience first;-)

Something notable for Ada, but the language may allow things, Java doesn't
http://www.dmitry-kazakov.de/ada/units.htm
The basic terms are similar, as for most languages, simply because almost
every of them relates to Andrew Kennedy's papers;-)
Kawa (note the Lambda;-) is a powerful GNU environment for Java over 10
years old
http://www.gnu.org/software/kawa/Quantities.html
It was around, when the EG of JSR 108 eventually withdrew the JSR. And
without having been on board then I assume, it was because of similar
disputes and discussions;-O
In Kawa you can pretty much do anything and you normally get a result.
Errors at most are thrown at runtime.
OSGi Measurement, it certainly influenced the new approach a bit:
http://www.osgi.org/javadoc/r4v42/org/osgi/util/measurement/Measurement.html

Note all operations exist in the API except Measurement.invert()
Which IMHO is the most questionable here, at least for Quantity. I'd be
happy to drop that unless a large user base cries for it.
OSGi Measurement checks everything at runtime. 1m.add(1kg) throws an
exception, but although JavaDoc states there could be an
ArithmeticException for Measurement.mul(Measurement), too, I have never
seen one. And operations like:
1kg.div(1sec) work fine and produce results like "1 kg/s" just like
1km.div(1sec) shows "1 km/s" (Acceleration).

I am not sure, if depriving users at least from basic operations (+-*/)
like those defined by Fowler in his Quantity pattern would be good?;-)

Otherwise several users might stick to Kawa or OSGi Measurement or simply
reinvent the wheel;-/

If an implementing class needs to throw a Runtime exception because e.g.
"kg/s" was wrong, but "km/s" allowed in that context, then it'll do.

If we wanted to enforce strict type safety, then similar to OpenXC there
should be concrete classes for everything;-)
http://android.openxcplatform.com/reference/com/openxc/measurements/Measurement.html
On top of BaseMeasurement and Quantity. Note, there's no generic for a
quantity type, only to ensure, numeric values are used and Quantity extends
Unit, I hope nobody wants us to go there?;-D
Unless the classes are final, one could declare a Meter.multiply(Meter)
method in a subclass of Meter returning Liter.
OpenXC has no intention of arithmetic support, even basic unit conversion
is not supported. Probably a reason why practically no other vendor than
Ford cares about it, not even in Europe?;-)

Regards,
Werner
Am 17.10.2014 13:59 schrieb "Leonardo Lima" 
< >:

> Hello, Werner!
>
> You mentioned you talked with Eclipse guys about they supporting this.
>
> Why don't they join this JSR as Experts as well? Did you propose it to
> them?
>
> I think it would add value to the discussion, having other people with
> explicit needs in this field.
>
> Regards,
> Leonardo.
>


Other experts

Leonardo Lima 10/17/2014

Re: Other experts

Werner Keil 10/17/2014

Re: Other experts

Leonardo Lima 10/17/2014

Re: Other experts

Werner Keil 10/17/2014

Re: Other experts

Werner Keil 10/22/2014

Re: Other experts

Werner Keil 10/27/2014

Re: Other experts

Martin Desruisseaux 10/18/2014
 
 
Close
loading
Please Confirm
Close