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 14:12:56 -0700
But returning to the thread,
Thank you, I did, I am waiting to question in Jira.
On Wed, Oct 1, 2014 at 1:51 PM, Otávio Gonçalves de Santana <
>
wrote:
>
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
>
>
--
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
