Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Email proposal to the
- Date: Tue, 21 Oct 2014 16:03:27 +0200
See
https://code.google.com/p/unitsofmeasure/source/browse/#svn%2Fbranches%2Fexamples%2Fjscience
While JScience 5 is not complete, at least the Unit Subsystem worked, so I
also added Jean-Marie's example there to test it.
jscience4demo runs against the older 4.x Version of JScience. You can get
that e.g. on MavenCentral. Most of the examples are either NetBeans
or Eclipse Projects (or hybrid running in both), some also contain Ant
scripts.
Werner
On Tue, Oct 21, 2014 at 3:39 PM, Werner Keil
<
>
wrote:
>
Well, we never got as far as operations on a Quantity (
>
https://kenai.com/projects/jsr-275/sources/svn-repository/content/trunk/jsr-275/src/main/java/javax/measure/quantity/Quantity.java?rev=259)
>
so the old Dynamic Proxy factory that could have instanciated a Length
>
would not work there anyway.
>
>
AFAIK (please correct me Jean-Marie) the JScience 4.x Amount class
>
implements Quantity, specialized with a generic argument like <Length> but
>
there is no implementing these Interfaces.
>
>
Hence, even if you say directly instanciated LengthAmount from the new SI
>
module, any operation will not return Length nor the concrete class but a
>
generic one like DoubleQuantity<Length> or DecimalQuantity<Length>. It'll
>
never return Length or its explicit implementing class.
>
>
The two approaches are totally incompatible, you could in theory (with the
>
SE-based old factory Approach only, make a serious Suggestion how that
>
would work in ME?[?]) force all operations to only return Q, but there
>
would not be freedom of a Wildcard like <?> since the Q those operations
>
were to return would be the Argument from Q<Q> not the Quantity any more.
>
>
IMHO this would be worse and not feasible for flexible calculations, as
>
you either have to "invent" an artificial replacement type like "Any" or
>
return Quantity after all.
>
>
So the old "legacy" Proxy based factory could return the Interface, but it
>
was a lose end with no parts of the System ever using or more importantly
>
returning those concrete classes, not even JScience 4 (correct me by
>
presenting a code snippet you ran against it[?])
>
>
Werner
>
>
On Tue, Oct 21, 2014 at 3:08 PM, Martin Desruisseaux <
>
>
>
wrote:
>
>
> Hello Werner
>
>
>
> Le 21/10/14 21:52, Werner Keil a écrit :
>
>
>
> On Tue, Oct 21, 2014 at 2:34 PM, Martin Desruisseaux <
>
>
>
>
> wrote:
>
>
>
>> In your example a ClassCastException can happen here (choose the
>
>> alternative you prefer):
>
>>
>
>> Length r = (Length) speed.multiply(time);
>
>> Length r = speed.multiply(time).cast(Length.class);
>
>>
>
>>
>
> This is highly discouraged as it won't work unless you also implement
>
> Length in a dedicated class like LengthAmount,...
>
>
>
> The safe alternative that you mention is the second one above. I just
>
> made a typo and accidentally called the method "cast" instead of "asType
>
> ".
>
>
>
> On you issue about the cast to (Length), I may be guessing your concern.
>
> You said that it won't work because Unit<Q> instance do not have an
>
> associated Class<Q> property, is that right? If, given a Unit<Q> object,
>
> we could get the Class<Q> of the Quantity interface, then nothing would
>
> prevent us from instantiating a Length, either directly as a
>
> plain-old-object or through java.lang.reflect.Proxy. Do I'm
>
> understanding your concern right?
>
>
>
> Martin
>
>
>
>
>
Attachment:
329.gif
Description: GIF image
Attachment:
35F.gif
Description: GIF image