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: Mon, 20 Oct 2014 13:59:57 +0200
Thanks for the feedback.
Will deal with JIRA later, I have to visit a client now.
Regards,
Werner
On Mon, Oct 20, 2014 at 1:50 PM, Otávio Gonçalves de Santana <
>
wrote:
>
Werner, you are right.
>
Martin,
>
>
Thanks for the reply. And confirming, you prefer to keep <?> methods in
>
the API.
>
Other downstream users are likely to use methods in Quantity, and the
>
ideological or "aestaetical" issues, Otavio mentioned affect Unit even more
>
than Quantity, so changing or removing any should consequently affect all
>
if anybody really wanted to do that.
>
>
I am pretty sure, a semantic connection between input and output will
>
never be available in Java. Some hard-wired hack and workaround like JSR
>
308 style type annotations are available but nobody really uses them. See
>
the "Checker Framework" its Unit support is cumbersome and totally
>
incomplete, plus it also only works at compile time and the information is
>
not available at runtime (can't say if there is some way to access them via
>
Reflection or not)
>
>
Reification of generics would add some benefit at runtime, it should work
>
say after you call asType() which currently always returns Q, in a future
>
Java version we might get Energy, Mass or Length instead, or
>
Quantity<Energy>. Allowing implementing classes to check operations at
>
runtime primarily. Other than the mentioned type annotations there is no
>
way you could do this at compile time even with what Java may get via
>
"Valhalla" or similar projects.
>
>
I don''t think bothering the JDK team at the moment makes sense. There
>
could be some kind of review during JSR stages, and if they are interested
>
or have something to add, they'll do, but again, this JSR is not aiming at
>
the platform in its 1.0 release at all, hence they normally have other
>
things to worry about[?]
>
Offering a "module" at a later stage could be possible, but let's see, how
>
it goes with Jigsaw first, that was due for many years, so we have to see
>
it work in Java 9 hopefully[?]
>
>
>
Otavio's input was neverthless valuable, especially as a remedy for issues
>
around asType(). the most type safe alternative to a cast or the <?>
>
wildcard for these operations.
>
>
Do you think asType() or whatever we'd call it there, works well in
>
Quantity, too? I am not sure, if simply routing everything to the
>
underlying Unit is sufficient, I believe in classes like AbstractQuantity I
>
even got that method already. Would be consequent to make it available in
>
the API.
>
>
Via the NumberValue wrapper around Number in JSR 354 there are methods
>
similar to asType() but for picking a particular number class like Double,
>
BigDecimal, etc.
>
At least to retrieve the factory, MonetaryAmount also returns a <?>
>
wildcard btw.[?] The fact it extends a type does not matter, the <?>
>
wildcard in Quantity or Unit is always restricted to match what <Q> does.
>
so you can never use Quantity<String> or Quantity<Object> but only
>
something like Quantity<Length>[?]
>
>
Regards,
>
Werner
>
>
On Mon, Oct 20, 2014 at 5:13 AM, Martin Desruisseaux <
>
>
>
wrote:
>
>
> Le 20/10/14 09:04, Werner Keil a écrit :
>
> > Please especially Martin/Jean-Marie, would you be happy to "split" the
>
> > API?
>
> Could you elaborate about what you mean by "split"?
>
>
>
> > Both on Quantity AND Unit of course, because the "crux" meaning all
>
> > <?> methods, Otavio feels are inappropriate result from Unit;-)
>
> >
>
> It depends if we envision any extension to the Java parameterized type
>
> system in the foreseeable future which would allow us to express the
>
> relationship between input and output arguments.
>
>
>
> > Now what about removing every <?> method:
>
> > divide() and multiply(<?>) invert() and potentially pow() from both
>
> > Quantity and Unit?
>
> I'm neutral about Quantity operations (as long as, if present, they are
>
> semantically corrects), since we never use them. But removing those
>
> operations from Unit would cause me to abandon JSR-363.
>
>
>
> Martin
>
>
>
>
>
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image