Skip to main content

[JSR-354] Re: Comment on Public Review of jsr-354

  • From: "Tresch, Anatole (KGVA 28)" <anatole.tresch@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Comment on Public Review of jsr-354
  • Date: Thu, 21 Nov 2013 15:46:54 +0000
  • Accept-language: de-CH, en-US

Hi all,

If we would introduce a method to access the numeric value, I would propose 
something like:

public <T> getNumber(Class<T> type);

We then also might also add something like:

public Collection<Class> getSupportedNumberTypes();

This would prevent users from "accidentally" using Number and also leaves 
room for future extensions. But I would NOT want to return Number explicitly 
here. We could then require to support BigDecimal on SE, which also can 
easily be tested by the TCK.

Cheers,
Anatole

Anatole Tresch
CREDIT SUISSE AG
Information Technology | Java Core Framework & Support
Spec Lead JSR 354 Money & Currency
8070 Zürich | Switzerland
Phone +41 44 334 03 89
anatole.tresch@...<mailto:anatole.tresch@...> | 
www.credit-suisse.com<http://www.credit-suisse.com>

From: Werner Keil [mailto:werner.keil@...]
Sent: Thursday, November 21, 2013 13:37
To: jcurrency_mail@...; mhochschild@...
Subject: [JSR-354] Re: Comment on Public Review of jsr-354

Actually you don't need to wait for JSR 308 to handle ReadOnly behavior, take 
JavaFX again: 
http://download.java.net/jdk8/jfxdocs/javafx/beans/property/ReadOnlyProperty.html

The "mother" of all value types there is: 
http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html

IMHO a generics based pattern like

T<http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html>
 getValue()
Returns the current value of this ObservableValue
Returns:
The current value
is precisely what MonetaryAmount is missing.

Google while still in the EC made a review comment during the PDR of JSR 275 
on an aspect of the API back then (Unit-API has addressed most of these and 
more) claiming, that aspect sounded like the language of a "19th Century 
French Nobleman", of course the time when much of the SI unit system was 
defined...

getAmountFractionDenominator() or getAmountFractionNumerator() I'm sorry to 
say sound exactly the same. You may find Scrooge in "A Christmas Carol" and 
writers from the same "epoch" use that when pinching their pennies, but no 
sane and real life person today outside a high school or university math 
class will use such terms.

T getValue() with MonetaryAmount<T extends Number> if you want allowing each 
implementing like Moneta Money to chose the right representation would be far 
more understandable.
JavaFX 8 does that ever since version 2:

public interface ObservableNumberValue

extends 
ObservableValue<http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html><java.lang.Number>
A common interface of all sub-interfaces of 
ObservableValue<http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html>
 that wrap a number.

Why can't other APIs that hope to become part of the JDK one day, too learn 
from that?

Werner

On Thu, Nov 21, 2013 at 12:24 PM, Werner Keil 
<werner.keil@...<mailto:werner.keil@...>> wrote:

On Thu, Nov 21, 2013 at 11:53 AM, Stephen Colebourne 
<scolebourne@...<mailto:scolebourne@...>> wrote:
On 21 November 2013 09:29, Meno Hochschild 
<mhochschild@...<mailto:mhochschild@...>> wrote:
> Of course there is a solution in form of properly applied generics. We know
> very well that JSR-310 project team leaders do all to avoid generics because
> they consider it as "messy". But this is the language feature Java offers as
> solution. And on concrete application level the solution is not at all
> messy, but very helpful and readable.
Not quite so. In JSR-310 I found no way to get generics to actually
work. The problem which 310 tackles involves many more interacting
interfaces, and the increased friction between the types nullifies the
benefits of generics. (For example, a 310 adjuster might only work on
a date but be applied to a date-time)


Most likely due to a lack of experts like Jean-Marie, Martin and others who 
helped make this work well between JSR 275 and Unit-API. Or those working on 
JavaFX [cid:image001.gif@01CEE6D9.482FFFC0]


> A MonetaryAdjuster must always be written for a special type. In the current
> state of JSR 354 instanceof-checks and type-casts cannot be avoided using
> the present method signature. This is in my opinion a heavy regression back
> to the time before JSR 14 was introduced in Java 5. Astonishing when you
> plan your JSR for even Java 9.
The intention here was to be slightly different to 310.

An implementation of an adjuster would be permitted to return any type
of MonetaryAmount (NB. the Javadic may not have ended up refecting
this). Thus the adjuster might be:

public MonetaryAmount adjustInto(MonetaryAmount a) {
  return MyMoneyClass.from(a).doMyAdjustment()
}

and the caller would be

public FooMoney with(MonetaryAdjuster adj) {
  return FooMoney.from(adj.adjustInto(this));
}

As such, the lack of generics is deliberate.


On the MonetaryAmount signature, what is really needed is the "self
type", a special type that declares itself as the type of the current
type. If this existed and had the syntax <this>, then the
MonetaryAmount interface would be defined as:

public <this> adjustInto(MonetaryAmount amount);

The self type is a well known language concept. I've found its
omission from Java particularly affects immutable classes, like we
have here. http://blog.joda.org/2007/08/java-7-self-types_1953.html


A more interesting question is whether MonetaryAmount should be
read-only, which would sidestep the debate. My primary concern is
defining an interface that allows a full formatter/parser to be built,
similar to 310's DateTimeFormatterBuilder. Before the API is locked
down, such a full formatter (that uses the API but isn't part of the
API) needs to be fully worked through (I know that work has already
been done on this). Until I have a good feel for the parser, its hard
to have a good sense of whether the adjuster is needed there (I
suspect it isn't).

For these I'm afraid you'll have to "swallow" JSR 308 checkers some 
day[cid:image002.gif@01CEE6D9.482FFFC0]
I'm only following them on the sidelines, e.g. to see if there are synergies 
from its (again only SE so like 310 that disqualifies them from a broad 
enough use in devices we hear are all going to run Java within a few months, 
years at most[cid:image001.gif@01CEE6D9.482FFFC0]) checkers, especially the 
ones around Units and Quantities, but there are all sorts of annotations, see 
the OpenJDK page you must have brushed a few times, too: 
http://openjdk.java.net/projects/type-annotations/

Stephen


Werner

GIF image

GIF image



[JSR-354] Comment on Public Review of jsr-354

Meno Hochschild 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Stephen Colebourne 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Stephen Colebourne 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013
 
 
Close
loading
Please Confirm
Close