Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Wed, 1 Oct 2014 13:51:56 -0700
Werner.
I understood in some cases we need to do this cast, but it should be avoid,
because it's not make sense with generics, generics was born to solve
problems like this.
We need to focus this will be a new API, so we should to use the new
features present in ME 8+
On Wed, Oct 1, 2014 at 12:06 PM, Werner Keil
<
>
wrote:
>
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
>
>>>>>
>
>>>>>
>
>>>>
>
>>
>
--
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
