Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Thu, 16 Oct 2014 19:54:29 +0200
On Thu, Oct 16, 2014 at 7:23 PM, Martin Desruisseaux <
>
wrote:
>
Le 17/10/14 02:00, Werner Keil a écrit :
>
>
I see nothing that would break the Java language in either of the proposed
>
approaches.
>
>
>
(...Sight...) Werner, are you serious? Really?
>
>
You leave me no choice. I will write to the OpenJDK list Sunday.
>
>
>
Do what you cannot leave, but note, unless either of the Spec Leads
(Leonardo abstained from the ballot till he gets a better idea of the
subject/discussion, Jean-Marie has been silent on all of it, maybe he is
busy or has no opinion?) sanction that, it makes a bad impression of the
work of the EG[?]
Unless you wanted to ask them about changes like the ones in JEP101 or
Valhalla, but most of them won't even be finished before we have to, so if
you want to bother them, go ahead, but at least on Oracle's side it would
sound a bit bad.
We try to be as democratic as possible, not JSR 310 dictatorship where even
those very JDK architects were snubbed and many of their concerns brushed
away and things done as Stephen insisted they should do. We have multiple
Spec Leads and unlike 310 they each have a say. So have EG members but at
the end of the day a consensus musts be reached not just here.
I must disagree on that. The generic factory approach is incompatible with
>
#1.
>
>
I wrote that code years ago. You choose to delete it. I will bring it back.
>
>
>
Otavio changed the Dynamic Proxy version using Reflection in the SE port.
And given there is no Reflection in ME 8, most of it also got applied to RI.
This is the "Quantity" in JScience:
http://www.jscience.org/api/org/jscience/physics/amount/Amount.html
The only place you may refer to is the old JSR 275 code as there was no
other QuantityFactory in the later API:
https://kenai.com/projects/jsr-275/sources/svn-repository/content/trunk/jsr-275/src/main/java/javax/measure/quantity/QuantityFactory.java?rev=259
It returned the interface, but that at the time was "crippled", the
Quantity had no operations. And see JScience 4.x (intended as RI of JSR
275) that took Quantity and returned Quantity<?> or Quantity<Q> for all
relevant operations, not Q[?]
We did not remove anything, we just stuck to what the initial RI did
anyway. Hence I hope, Jean-Marie can also contribute to the
discusssion/decision making.
>
asType() has turned out to be unstable and cumbersome
>
>
You have never been able to give me any proof of that claim. I will never
>
believe it without a code demonstrating the problem.
>
>
We cannot do a "diff" between all unit systems, especially US or UCUM here,
but if you do that diff, you'll see all the places that asType() simply
broke the code starting with SE 8u20. Also look at SE port issues,
especially all
https://github.com/unitsofmeasurement/unit-impl-se/issues?q=is%3Aissue+is%3Aclosed
GitHub gives you a detailed idea of what changed in the SE port. Aside from
Otavio and myself, Geoff Capper also helped fix some of them.
>
>
Note, Otavio's suggestion goes pretty much in that direction[?]
>
>
Otavio's suggestion is a violation of the Java language. The OpenJDK list
>
reply (if they accept to reply) will make that clear.
>
>
>
Including the problems with asType().
>
>
I'm sure that this problem does not exist.
>
>
>
It does, see above, in the SE 8 implementation there are very few cases
where asType() did not break the code and it seems the remedy could be used
to replace all existing calls.
>
If API insisted on a type like "Energy", then for each possible return
>
type an interface and implementing class had to be declared
>
>
No Werner, I tried to explain you 4 times and you still do not understand
>
me. The 50 currently existing interfaces, *one* java.lang.reflect.Proxy
>
implementation, *nothing else needed* (but possible is some want
>
optimizations).
>
>
>
Both the Quantity<T> return type and a Quantity<?> one are flexible
>
>
They are unsafe.
>
>
>
not forcing developers to declare an interface for every single final or
>
intermediary value they need for their calculations.
>
>
No one suggested that, why are you still bringing that point?
>
>
>
Otavio also mentioned, Lambda related JEPs including 101 could be broken
>
or made extremely hard to cope with by the existing <?> approach.
>
>
Okay, that is the first significant new point I have seen in this
>
discussion for a while, thanks for bringing it. Can we have some details
>
about this issue
>
Some is related to asType() being broken from an update version of SE 8 on.
@Otavio, please elaborate on that, either here in the list or JIRA. If
necessary from next week on, we could also consider Hangouts, etc.
>
>
>
Martin
>
Cheers,
Werner
Attachment:
347.gif
Description: GIF image