Skip to main content

Re: Other experts

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Other experts
  • Date: Mon, 27 Oct 2014 11:16:30 +0100

Hi,

Just wanted to share, that the reps of Eclipse projects who are interested
to use JSR 363 or in some cases already use 275 said, they are OK with the
proposed method signature of both Unit and Quantity, and that users need to
be somewhat "responsible" so an explicit cast (or call to asType() where
possible) is fine for them[?]

I almost finished https://java.net/jira/browse/UNITSOFMEASUREMENT-66 and
given downstream users feel happy using that where calculations permit, I
should soon be able to close it. Could we look into
https://java.net/jira/browse/UNITSOFMEASUREMENT-67 and
https://java.net/jira/browse/UNITSOFMEASUREMENT-65 please.
@Otavio, you mentioned there could be some issue with an of() on an
abstract class, could you elaborate that please?
The JEP draft I quoted in https://java.net/jira/browse/UNITSOFMEASUREMENT-67
shows clear intention by the JDK Team to add those to Interfaces (since
Java SE 8 you can do that, I don't think ME 8 allows it, but we'd have to
check, given it is based on SE 7 I doubt it however) so using at least an
Abstract base class like AbstractUnit or AbstractQuantity sounds a lot more
natural. Abusing BaseQuantity (which serves as extention point to concrete
types, if the general purpose ones don't suit needs by certain users, that
includes defining concrete classes implementing Interfaces like
Temperature, Mass, etc.[?]) to return all other "parallel" types looks
rather dodgy. So either we must make all of the concrete quantities public
if we insist on each having an of() method, or put those we want to keep
back to AbstractQuantity.
Unlike Unit, where a complicated Factory mechanism is unnecessary (for most
the SystemOfUnits Interface acts as factory[?]) we also have now 2(!)
competing quantity factories and convenience methods, see
https://java.net/jira/browse/UNITSOFMEASUREMENT-65.

Regards,
Werner

On Wed, Oct 22, 2014 at 1:17 PM, Werner Keil 
< >
 wrote:

> Hi,
>
> Eclipse Science Project DAWNSci (see
> https://projects.eclipse.org/wg/science/projects) also has plans to
> Support unit types and currently references JSR-275 (since e.g.
> LocationTech, does, too) So there are a few (including UOMo which will
> migrate to JSR 363 as soon as it's available via Orbit, too) with These
> requirements. Even if they may not join the JCP or this EG, their
> activities are coordinated e.g. via WG Mailing lists like the one for
> Science.
>
> Regards,
> Werner
>
> On Fri, Oct 17, 2014 at 7:15 PM, Werner Keil 
> < >
> wrote:
>
>> Leo,
>>
>> It was in the other "big" thread, I no longer see it in "Drafts" so I
>> trust it went out, but you may have missed it covered by someone else's
>> reply[?]
>>
>> I did raise that question elsewhere, but Eclipse Foundation represented
>> by Mike, in few cases of his absense by Wayne is currently not interested
>> in any "technical" aspects of JSRs like this or others. It purely gets
>> involved in the "Usual Suspects" especially IP and license related stuff.
>> Though I heard at DemoCamps, Mike himself did once write software now
>> evolved over time at Eclipse (in "his" days it was still Smalltalk[?]) he
>> now is unlikely to actively commit code. Despite his role at Twitter,
>> Eclipse UOMo mentor Chris A. still does write code, but he did not seem to
>> have much time or interest to join the EG either. We briefly talked about
>> it, but neither Eclipse nor Twitter so far joined any JSR. And what Chris
>> mentioned, they might do so on even more "low level" things like
>> Concurrency, etc.
>>
>> Regards,
>>
>>  Werner
>>
>>
>> On Fri, Oct 17, 2014 at 6:42 PM, Leonardo Lima 
>> < >
>> wrote:
>>
>>> Werner,
>>>
>>> I didn't get it. Did you propose Eclipse to join our JSR as EG member or
>>> not?
>>>
>>>
>>> Regards,
>>> Leonardo.
>>>
>>> On Fri, Oct 17, 2014 at 11:09 AM, Werner Keil 
>>> < >
>>> wrote:
>>>
>>>> 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.
>>>>>
>>>>
>>>
>>
>

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



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