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 21:46:06 +0200
On Thu, Oct 16, 2014 at 8:49 PM, Martin Desruisseaux <
>
wrote:
>
Le 17/10/14 02:54, Werner Keil a écrit :
>
>
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[?]
>
>
I know it will make a bad impression. But frankly, if this group can not
>
perform a logical analysis, we deserve it.
>
>
Unfortunately there are many "cooks" there, and just take the JSON mess,
WebSockets or JSR 310 they often get involved in ill-decisions about Java,
too[?]
I had many discussions also during JavaZone and related trip with fellow
speakers. Who argued exactly in this direction.
Changes effectively breaking code in Java 8u20 or the giant mess around ME
8 Embedded (where code compiled with new versions of both SE 7 or 8 no
longer works in ME Embedded 8 or 8.1, Leo confirmed the bug with other
libraries, see
https://java.net/jira/browse/UNITSOFMEASUREMENT-57) are also
based on "Core Java" things these guys tried to "improve" but creating bugs
and chaos instead.
If you really want to ask a "Blind man" to guide this "One eyed" EG go
ahead, but see above issues, they got a much bigger chunk of bugs and
issues on their agenda.
If Oracle cannot fix the ME 8 bug then MEEP is DEAD for IoT[?]
>
>
We try to be as democratic as possible
>
>
But main parts of my argument is about *logic*! Democracy has nothing to
>
do in logic. Do you think that expressions like "*if A=B and B=C then A=C*"
>
is a matter of opinion? On which of the following points do you disagree?
>
(I explained those points in more details in my first today's email):
>
>
>
1. *LOGICAL FACT:* the "non-wildcards" proposal, when applied to the
>
specific case of the Java language, can not be logically consistent.
>
2. *LOGICAL FACT:* going ahead despite the logical problem break the
>
integrity of Java parametric type safety.
>
3. *OPINION:* The JSR-363 group has no authority for breaking the Java
>
language that way.
>
>
>
If I'm wrong on point 1 or 2, it should take you only 5 minutes to
>
convince me: just point to the logical flaw in the arguments of my first
>
today's email.
>
>
>
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.
>
>
Do we agree that SE can use reflection, and that ME take only a subset of
>
quantity types?
>
>
Not in the current form, putting the "quantity" package and everything else
into a single monolithic JAR means, it will always be there.
The version of the API/Enum implementation that work with ME 8 already used
a single JAR. Hence medemo.jar is 161kb in size for a simple "Hello World"
type example.
https://github.com/unitsofmeasurement/uom-demos/blob/master/javame/medemo/src/medemo/Medemo.java
uses only Time and Temperature, nevertheless the single JAR app created by
ME 8 SDK contains every single of the 51 SI quantities. No Stripping, that
was forbidden by Oracle, hence it will not happen. The only way you could
select is if we break the API into small JARs like MEEP, otherwise every
type will be there even if the packages are officially declared "optional"
Go ask Oracle/JDK team about that, but probably better to the ME team[?]
>
>
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
>
>
Yes I was thinking about that class. It could be simplified a little bit.
>
>
>
It returned the interface, but that at the time was "crippled", the
>
Quantity had no operations.
>
>
We can add the operations, no problem with that.
>
>
>
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
>
[?]
>
>
But nobody proposed to return Q! I explicitly wrote *Quantity<?>
>
multiply(Quantity<?>)* in my previous email! I also wrote "*the old
>
method signature was in my opinion the best we can achieve*". Energy is a
>
subtype of Quantity<Energy>, which is itself assignable to Quantity<?>.
>
Consequently a Quantity<?> multiply(Quantity<?>) method can return an
>
instance of Energy. No need for thousands of methods or methods returning
>
Q.
>
>
No, it's incompatible and the compiler won't let you.
If you tried:
Area area = height.multiply(height);
in the BMIDemo, even with a Quantity<?> return value it won't compile.
Unlike Otavio's proposal, you could in theory try to cast to Energy.
Trying so gives this runtime exception:
Exception in thread "main" java.lang.ClassCastException:
tec.units.ri.quantity.DoubleQuantity cannot be cast to
javax.measure.quantity.Energy
at tec.uom.demo.health.BMIDemo.main(BMIDemo.java:43)
And even if you declared a sub-interface of Quantity called BMI as the
result of the (old style) divide() method, a general purpose Quantity class
(just like JScience Amount) won't be cast to Energy or BMI. The only place
where this could work is if you operate entirely on concrete classes like
the Enum implementation does or the "uom.si" module.
Of course you would not get these from QuantityFactory or Quantities, but
have to do something like EnergyQuantity.of() or new EnergyQuantity() with
a concrete class called EnergyQuantity that implements both Quantity (or
extends a base class like BaseQuantity) and Energy.
Feel free to demonstrate, how QuantityFactory or similar factory classes
could do the trick without declaring both an interface (like Energy) and
concrete class (like EnergyAmount or EnergyQuantity)
Instead of arguing for days and weeks without any progress, please let's
follow what JSR 354 did a lot (and while it was just few contributors
there, even 310 had multiple "experimental" branches before being sucked
into OpenJDK[?])
Instead of a pull-request, try creating either a branch of relevant
projects like "unit-api" (and the implementation of your choice) or fork it
in your own local GitHub account (both options should allow a pull-request
later after the probe was succesfully demonstrated and tested)
>
>
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
>
>
I found no mention of 'asType' under that link and by browsing in the
>
comments, but maybe I didn't looked hard enough. Anyway this is not the
>
main issue, since we are not proposing a Quantity.asType(Class) method.
>
>
>
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.
>
>
Then, please point me to a place where it broke the code. Is it possible
>
to give me something more accurate than digging in the history of the
>
entire project?
>
>
Martin
>
>
Werner
Attachment:
35C.gif
Description: GIF image
Attachment:
341.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image