Skip to main content

[JSR-354] Re: javax.money public review comments

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: javax.money public review comments
  • Date: Tue, 26 Nov 2013 19:36:57 +0100

Roger,

Thanks, would be happy to discuss the right balance between portability and
a reasonable level of precision. Unless you want to model the entire US
debt in a single number (where of course BigInteger sounds best, nobody
cares about the decimal points in such a large value[?]) approaches of
either combining long values or double (down to 2 digit cent or penny most
currencies need, even that is sufficient, e.g. EZMoney uses it, most
corporate level ERP or Financial Management apps in  Java I know on a
source level use long) have been sucessful and sufficient.

It is not the first client and project I see here right now, where Java 6
is the golden standard in a Very Long Term application. The kind Eclipse
aims at with its "LTS" initiatives. I can't say too much, and of course
should Cameron lose the next election, some of these projects may be
dropped, but at least one major British Railway operator also considers
what we work on here. And safety and life critical systems like these will
run for 20 or 30 years and it'll take a decade, maybe more before they
consider changing from Java 6 to something else. Maybe 9 or 10 then, but
they will not abandon 6 just because of Lambas and certainly not for
JSR-310 which would blow the very restricted memory these Embedded apps
have even on SE[?]

In fact Anatole did a great job with "FastMoney" I pointed to that before,
but it seems necessary to remind of JavaFX NumberExpression:
http://docs.oracle.com/javafx/2/api/javafx/beans/binding/NumberExpression.html
Minus
the asString() methods which add formatting to a pure value
holder/manipulator, a more or less complete subset of these methods would
make sense for an interface like MonetaryAmount[?]

CurrencyUnit is pretty close to the JDK Currency, so even looking at
Roger's advice not to peer at Java 9 or other integration now, a similar
functionality may  not be wrong. Some methods are worth discussing, but
even improved APIs like ICU4J stuck to them after all.

Speaking of ICU4J, its very  own Mark (who also subscribed to that list)
provided formatting classes like DecimalFormatSymbols and its Java 8
version has been updated as of 2013. Instead of the isolated DecimalStyle
class in java.time.format helping Mark and Oracle to improve that inside
OpenJDK would have been the more sensible thing to do instead of cloning it
for a small isolated purpose while every other Decimal/Number formatting
functionality will continue to use DecimalFormatSymbol[?]

Werner

On Tue, Nov 26, 2013 at 6:57 PM, roger riggs <roger.riggs@...> wrote:

>  Hi Werner,
>
> Since portability of code and libraries is a significant value across Java
> runtimes the types and semantics must be the same so that binary reuse is
> possible.  That means that the types need to have the same behavior
> regardless of the implementation.  A different implementation in a
> different namespace cannot achieve that.  The currency API needs to define
> range and precision in its own terms and make the guarantees; allowing the
> internal representation not to be exposed.  The interfaces to less portable
> numeric types should be either avoided or factored to be adaptable.  There
> are several techniques available though none produce as nice an interface
> as being able to assume the full set of numeric types. Tradeoffs are
> unavoidable.
>
> Roger
>
> p.s. I prefer to think I have had a broader experience and view by virtue
> of working on both Java SE and ME; it allows me to see more clearly why
> tradeoffs are made in each context.
>
>
>
> On 11/26/2013 12:32 PM, Werner Keil wrote:
>
> Roger,
>
>  Thanks for further elaborating that.
>
>  As CLDC/MEEP co Spec Lead or EG Member you may be a bit biased, but on
> the other hand, taking abstract functionality provided by such interfaces,
> would you say an alternate RI or implementation for ME/CLDC could also be
> of interest and relevance?[?]
>
>  (no endless discussion about Data types here please, it is just a
> general clarification[?])
>
>  Werner
>
>
>

Attachment: 329.gif
Description: GIF image

Attachment: 326.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



[JSR-354] Re: javax.money public review comments

(continued)

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Anatole Tresch 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

Stephen Colebourne 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

Stephen Colebourne 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Anatole Tresch 11/27/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/27/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/27/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/27/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/27/2013

[JSR-354] Re: javax.money public review comments

Sascha Freitag 11/26/2013
 
 
Close
loading
Please Confirm
Close