Skip to main content

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



Re: Email proposal to the

(continued)

Re: Email proposal to the

Otávio Gonçalves de Santana 10/19/2014

Re: Email proposal to the

Werner Keil 10/19/2014

Re: Email proposal to the

Leonardo Lima 10/19/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Otávio Gonçalves de Santana 10/20/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Otávio Gonçalves de Santana 10/20/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014

Re: Email proposal to the

Werner Keil 10/19/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014
 
 
Close
loading
Please Confirm
Close