Skip to main content

Re: Remove "generic" multiply/divide operations from Quantity

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Wed, 1 Oct 2014 12:06:43 -0700

I just spoke to Paul Perrone after his Real Time Java Vehicle testing talk.
He'd be interested to look at JSR 282 btw (happy to get him in touch with
Jean-Marie over that;-) but the important message from his slides is, that
almost every case where they derive something like:

Sensor1 sensor1 = (Sensor1) sensorManager.getSensor(SENSOR1_ID); they use
cast and that is a realtime safety-critical system controlling cars or
drones[?]

So casting can in some cases like mixed operations not be avoided
completely.
You're more than welcome to explore JSR 308 and its Unit Checkers for SE 8+
and added safety at compile time. I spoke to Alex Buckley (a co Spec Lead
of 308) though he said, Oracle itself has practically no use for it. And
the feedback by Java EE Spec Leads at last night's BOF was equally mixed to
frosty.

We discussed 308 here earlier, and e.g. Martin agreed it could help. Would
be only SE specific, so nothing for the API or Spec. Thus on the API level
we could have methods that allow cast and e.g. in ME 8 one will probably
have to without extra checking by JSR 308, etc. See Perrone the industry
uses that today and they control cars or patient monitors with those
embedded systems. In my previous project this was quite similar in the
train control business btw.

HTH,
Werner

On Wed, Oct 1, 2014 at 11:58 AM, Otávio Gonçalves de Santana <
>
 wrote:

> The problem is using cast with genetics almost always means problem with
> design API.
> On Oct 1, 2014 11:49 AM, "Werner Keil" 
> < >
>  wrote:
>
>> Sure, that is good. As we would at most consider the mentioned alternate
>> method (it looks a bit scary with so many generic arguments though;-) I
>> rejected the current one as it does not seem feasable. Please let's see
>> what comments come up in JIRA or here then we're happy to consider another
>> pull request for this topic.
>>
>> Thanks,
>> Werner
>>
>> On Wed, Oct 1, 2014 at 11:35 AM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>>> I am just created the pull request,  don't pull the code,  of course I
>>> will wait this discussion.
>>> On Oct 1, 2014 11:18 AM, "Werner Keil" 
>>> < >
>>>  wrote:
>>>
>>>> Yes I am. You may need to subscribe to the ticket.
>>>>
>>>> Please be patient with actual changes to the code. We heard by Bruno at
>>>> the JCP EC you are very eager to help and it was also a key factor that
>>>> earned you the JCP Award the other day, but the API and prior efforts 
>>>> (all
>>>> the way back to JSR 208) have a long history and lived as Open Source
>>>> projects (even in several "forks" see UCAR) for over a decade now. Some 
>>>> are
>>>> used by other standards, see GeoAPI, so a level of compatibility and
>>>> consistency with existing API is about as important as for a part of the
>>>> JDK itself. Hence, let's be careful and gentle with any structural change
>>>> and not rush things.
>>>>
>>>> Thanks,
>>>> Werner
>>>>
>>>> On Wed, Oct 1, 2014 at 7:19 AM, Otávio Gonçalves de Santana <
>>>>  >
>>>>  wrote:
>>>>
>>>>> Are you guys received some alerts when someone comments this issue?
>>>>> I am not :(
>>>>>
>>>>> BTW: I added a comment:
>>>>> https://java.net/jira/browse/UNITSOFMEASUREMENT-59
>>>>>
>>>>> On Tue, Sep 30, 2014 at 4:02 PM, Werner Keil 
>>>>> < >
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> However while specialized implementations are allowed, I don't think
>>>>>>> they are needed. A single implementation can handle every standard
>>>>>>> subtypes (Speed, Time, Length, etc.), provided that the
>>>>>>> QuantityFactory
>>>>>>> implementation is complete enough.
>>>>>>>
>>>>>>>
>>>>>> No objections to that.
>>>>>>
>>>>>> In fact, using the additional domain "si.uom" I spawned a separate
>>>>>> library for those. While SI quantity types (being just interfaces) 
>>>>>> should
>>>>>> be in the API this is an extension to either RI or SE implementation 
>>>>>> (since
>>>>>> it extends AbstractQuantity or a similar base type) and can live quite 
>>>>>> well
>>>>>> in a separate module.
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> > Martin, could you open a JIRA ticket for the suspect type issue on
>>>>>>> > inverse, please?
>>>>>>>
>>>>>>> As said in my previous email, I tried but JIRA seems partially down
>>>>>>> tonight. Will try again tomorrow.
>>>>>>>
>>>>>>>     Martin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Otávio Gonçalves de Santana
>>>>>
>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>> twitter: http://twitter.com/otaviojava
>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>> 55 (11) 98255-3513
>>>>>
>>>>>
>>>>
>>

Attachment: 329.gif
Description: GIF image



Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/12/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/13/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

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