Use Advanced Search to search the entire archive.
Re: Other experts
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Other experts
- Date: Fri, 17 Oct 2014 19:15:45 +0200
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