Skip to main content

[JSR-354] Re: Spec for Public Review: Ballot!

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Spec for Public Review: Ballot!
  • Date: Fri, 18 Oct 2013 18:20:46 +0200

Anatole/all,

As examples like that in Iran (and any country where Inflation or a
Financial crisis devaluates the currency, the US just avoided that last
night at the brink of destruction[?]) show, a subunit may not have to be a
"minor" part, so it is worth considering a get() like in 310. As of now,
JavaMoney, possibly specialized MonetaryAmount types for Bitcoin or local
currencies could start exploring that, but a simple long get(CurrencyUnit)
method would do no harm to the API and make it more versatile, not
complicated.

For all other aspects of what 310 offers, I e.g. didn't find it necessary
to list the actual (sub) units with the amount, though it'll certainly help
formatting, parsing and general human interaction (for the "10 $, 2 dimes,
50 ct" example) In the current form unless JavaMoney can soothe some of
that, it's inevitable the "Humanizer" project will also come for JSR 354 as
it did for 310 and JodaTime (not sure about JodaMoney) simply because real
people with real life problems need things the JDK often forgot about it
trying to please "academic" more than normal use cases.

As of now, Moneta covers pretty much all of what the ThreeTen BP does with
the get() method in a case like Duration:

  @Override
    public long get(TemporalUnit unit) {
        if (unit == SECONDS) {

            return seconds;
        }
        if (unit == NANOS) {
            return nanos;
        }
        throw new DateTimeException("Unsupported unit: " + unit);
    }

Not too impressive or complex, but its API did provide a separate getter,
despite the fact that at least the concrete class (NOT the interface[?])
must have separate getSeconds() or getNanos() methods, too. That is pretty
much the problem with our approach. Of course, you would not use an enum in
case of currency subunits, but to safe people from the insane "getEuros()
vs. getDollars()" example by folks like Eric Evans, a get(CurrencyUnit)
would be much more elegant and flexible. Allowing people to define a
CurrencyUnit implementation for subunits or "superunits" where necessary.

P.s.: Another project by Google at Eclipse, WindowBuilder uses the notion
of "denominator" and "numerator, but there we're talking Java UI
LayoutManagers, not monetary amounts[?]

Cheers,
Werner

Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
Language Champion | Java Godfather

Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil

* Nighthacking with Stepen Chin Fall 2013: Nov 2013, Germany. Werner Keil,
Eclipse UOMo Lead will hack "M2M", "UOMo", "JavaMoney" and other cool Java
(Embedded) stuff

* JMaghreb 2.0: Nov 7-8 2013, Casablanca, Morocco. Werner Keil, JCP EC
Member, JSR 354 EG Member may present "Java Social", "JSR 354"

* Eclipse DemoCamps Fall 2013: Nov/Dec 2013, Germany, Austria, France.
Werner Keil, Eclipse UOMo Lead, Babel Language Champion will present "M2M",
"ETCS"

 Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
Language Champion | Java Godfather

Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil

* Nighthacking with Stepen Chin Fall 2013: Nov 2013, Germany. Werner Keil,
Eclipse UOMo Lead will hack "M2M", "UOMo" and other cool Java Embedded stuff

* JMaghreb 2.0: Nov 7-8 2013, Casablanca, Morocco. Werner Keil, JCP EC
Member, JSR 354 EG Member may present "Java Social", "JSR 354"

* Eclipse DemoCamps Fall 2013: Nov/Dec 2013, Germany, Austria, France.
Werner Keil, Eclipse UOMo Lead, Babel Language Champion will present "M2M",
"ETCS", "Triple'E class DevOps"


On Thu, Oct 17, 2013 at 12:05 PM, Werner Keil <werner.keil@...> wrote:

> Anatole/all,
>
> As examples like that in Iran (and any country where Inflation or a
> Financial crisis devaluates the currency, the US just avoided that last
> night at the brink of destruction[?]) show, a subunit may not have to be a
> "minor" part, so it is worth considering a get() like in 310. As of now,
> JavaMoney, possibly specialized MonetaryAmount types for Bitcoin or local
> currencies could start exploring that, but a simple long get(CurrencyUnit)
> method would do no harm to the API and make it more versatile, not
> complicated.
>
> For all other aspects of what 310 offers, I e.g. didn't find it necessary
> to list the actual (sub) units with the amount, though it'll certainly help
> formatting, parsing and general human interaction (for the "10 $, 2 dimes,
> 50 ct" example) In the current form unless JavaMoney can soothe some of
> that, it's inevitable the "Humanizer" project will also come for JSR 354 as
> it did for 310 and JodaTime (not sure about JodaMoney) simply because real
> people with real life problems need things the JDK often forgot about it
> trying to please "academic" more than normal use cases.
>
> As of now, Moneta covers pretty much all of what the ThreeTen BP does with
> the get() method in a case like Duration:
>
>   @Override
>     public long get(TemporalUnit unit) {
>         if (unit == SECONDS) {
>
>             return seconds;
>         }
>         if (unit == NANOS) {
>             return nanos;
>         }
>         throw new DateTimeException("Unsupported unit: " + unit);
>     }
>
> Not too impressive or complex, but its API did provide a separate getter,
> despite the fact that at least the concrete class (NOT the interface[?])
> must have separate getSeconds() or getNanos() methods, too. That is pretty
> much the problem with our approach. Of course, you would not use an enum in
> case of currency subunits, but to safe people from the insane "getEuros()
> vs. getDollars()" example by folks like Eric Evans, a get(CurrencyUnit)
> would be much more elegant and flexible. Allowing people to define a
> CurrencyUnit implementation for subunits or "superunits" where necessary.
>
> Cheers,
> Werner
>
>  Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
> Language Champion | Java Godfather
>
> Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
>  Skype werner.keil | Google+ gplus.to/wernerkeil
>
> * JMaghreb 2.0: Nov 7-8 2013, Casablanca, Morocco. Werner Keil, JCP EC
> Member, JSR 354 EG Member will present "Java Social", "JSR 354"
>
> * Eclipse DemoCamps Fall 2013: Nov/Dec 2013, Germany, Austria, France.
> Werner Keil, Eclipse UOMo Lead, Babel Language Champion will present "M2M",
> "ETCS"
>
>
> On Thu, Oct 17, 2013 at 9:54 AM, Anatole Tresch <atsticks@...>wrote:
>
>> Hi Werner
>>
>> Imo the api is still sufficient also for these cases :
>> - the denominator must not be a power of ten (its just a recommendation)
>> - all minor unit variants mentioned still are representable by our logic.
>> - so the interoperability is still given.
>> - accessing all the examples you mentioned can be modeled by adjusters or
>> queries.
>> - since minor units similar to fraction units may change over time, we
>> have also a time dimension.
>> - additionally use cases may require additional, different views, eg the
>> available major units in a banking machine or the supported minor units in
>> an exchange shop on an airport.
>> - also note that in the original outline of this jsr we excluded
>> explicitly non decimal values to be supported. Looking at the current
>> numeric interop format, even that is possible now some extend.
>>
>> Looking at the complexities mentioned, they would clearly be out of scope
>> for a jdk addition. And with the fact that the current extension mechanisms
>> still work, such requirements imo are for the ri or javamoney. Eg we could
>> provide historic access for minor units (as adjusters, possibly extended)
>> or for simplity add a method getMinorUnits to the MoneyCurrency class for
>> the current minors of a currency (a valuable data provider is a required
>> for both cases, wikipedia is not such one).
>>
>> Cheers
>> Anatole
>>
>>
>> -
>> Anatole Tresch
>> Glärnischweg 10
>> 8620 Wetzikon
>> Tel +41 (43) 317 05 30
>> -
>> Send from Mobile
>>
>> Am 17.10.2013 um 01:46 schrieb Werner Keil <werner.keil@...>:
>>
>> Hi,
>>
>> Observers and JUG Members on this list from Morocco or Egypt should
>> certainly know, that beside the mentioned cases of China or Japan,
>> Mauretania uses a subunit divided by 5
>>  (UM1 = 5 khoums) also a legal tender in Western Sahara among a few other
>> currencies, and Egypt (hoping there aren't any "Morsi Dinars" or further
>> fragmentation there, too?) uses 2 subunits: £E1 = 100 piasters, 1,000
>> milliemes. And while staying in the Middle East, to make it worse, Iran has
>> 2 subunits, but one is actually a multiple of the main currency: 1 rial =
>> 100 dinars, 10 rials = 1 toman
>>
>> The simple WholeAmount / Fraction separation is insufficient in both
>> directions it seems. All these countries, even Iran (especially after
>> somewhat promising developments in Geneva this week) do business with their
>> neighbors and the rest of the World. It would be foolish to limit the API
>> to countries like the United States or Euro zone, if many of the biggest or
>> most populated countries in the world
>http://en.wikipedia.org/wiki/List_of_countries_by_population ;(China Nr.
>> 1, Japan Nr. 10, Egypt and Iran each about the population of Germany, but
>> in both cases it probably outgrew Germany by now, or will do within
>> months,...) simply cannot use it.
>>
>> Cheers,
>> Werner
>>
>> On Thu, Oct 17, 2013 at 1:15 AM, Anatole Tresch <atsticks@...>wrote:
>>
>>> Hi Tony
>>> incorporated almost all changes, despite:
>>>
>>>
>>>    1. In 4.2.2 I would have thought that the exposed getAmount* should
>>>    all be unsigned with a signum() call returning the sign of the actual
>>>    MonetaryAmount. This would avoid the validation around the signs of the
>>>    Whole, Numerator and Denominator amounts.
>>>
>>>    Logically a MonetaryAmount would always then be:
>>>    Signum * ( WholeAmount + ( FractionNumerator / FractionDenominator )
>>>    )
>>>
>>> I had a long discussion on that topic with Mark Davis. Perhaps we will
>>> have to revisit this point, but basically there are two ways to solve the
>>> signum issue: the one we have for now, or the one you proposed
>>> also...perhaps Mark can give us some short bits on that ;-)
>>>
>>>
>>>
>>> 2013/10/16 Werner Keil <werner.keil@...>
>>>
>>>> English Native Speaker??
>>>>
>>>> Das meinte ich auf Tony oder Stephen bezogen
>>>>
>>>>
>>>> On Wed, Oct 16, 2013 at 7:59 PM, Anatole Tresch <atsticks@...>wrote:
>>>>
>>>>>  Hi Tony
>>>>>
>>>>> thanks for your input. As also native speaker have written the
>>>>> document, still there are some points to improve. This update is done
>>>>> easily. I think I will create the package on Friday, so there is plenty 
>>>>> of
>>>>> time to accommodate your input ;-)
>>>>>
>>>>> Cheers,
>>>>> Anatole
>>>>>
>>>>>
>>>>> 2013/10/16 Werner Keil <werner.keil@...>
>>>>>
>>>>>> Tony,
>>>>>>
>>>>>> Thanks for the details, that is much appreciated. Since you are a
>>>>>> member of the full EG, unless it already happened, Anatole should be 
>>>>>> able
>>>>>> to grant you edit rights to the document, too.
>>>>>> I spent a long time with English speaking teams and lived with native
>>>>>> speakers, but even I am not a native speaker myself, and especially in
>>>>>> large teams with people from all countries documents are not always
>>>>>> proof-read even in large organisations<329.gif>
>>>>>>
>>>>>> Given the 30 day minimum review period before the (next) EC will find
>>>>>> it on the ballot, it makes almost no difference, if the PD would start 
>>>>>> this
>>>>>> or next week. Unless there are more updates and spell-checks 
>>>>>> necessary, I
>>>>>> would see no problem filing it early next week, but it would make 
>>>>>> little
>>>>>> difference if it was filed a week later.
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 16, 2013 at 12:37 PM, Tony Jewell <tjewell@...>wrote:
>>>>>>
>>>>>>> [Apologies for just being a sleeper so far]
>>>>>>>
>>>>>>> *yes*
>>>>>>> *
>>>>>>> *
>>>>>>> Just reading the spec (0.7) - [feel free to ignore my comments if
>>>>>>> they have been dealt with previously]
>>>>>>>
>>>>>>>    1. In section 3.2.5 you should probably have a footnote that
>>>>>>>    explains the difficulties of Indian Rupees to give context.
>>>>>>>
>>>>>>>    2. In 4.2.2 I would have thought that the exposed getAmount*
>>>>>>>    should all be unsigned with a signum() call returning the sign of 
>>>>>>> the
>>>>>>>    actual MonetaryAmount. This would avoid the validation around the 
>>>>>>> signs of
>>>>>>>    the Whole, Numerator and Denominator amounts.
>>>>>>>
>>>>>>>    Logically a MonetaryAmount would always then be:
>>>>>>>    Signum * ( WholeAmount + ( FractionNumerator /
>>>>>>>    FractionDenominator ) )
>>>>>>>
>>>>>>>    3. In 4.2.3 the method signature is syntactically wrong having
>>>>>>>    an extra "T".
>>>>>>>
>>>>>>>    4. In 4.2.3 the adjuster example could possibly do with a little
>>>>>>>    tidy around the names:
>>>>>>>
>>>>>>>    MonetaryAmount amount = …
>>>>>>>
>>>>>>>    MonetaryAdjuster convertToUSD = ...
>>>>>>>    MonetaryAmount usdAmount = amount.with(convertToUSD)
>>>>>>>    5. In 4.3
>>>>>>>    "like INR" => "like Indian Rupee (INR)" and also reference same
>>>>>>>    footnote as above.
>>>>>>>    "can be also formatted" => "can also be formatted"
>>>>>>>
>>>>>>>    6. In 5:
>>>>>>>    "Finally there exists some functionalities...." could probably
>>>>>>>    be rewritten as (if I'm understanding the meaning correctly):
>>>>>>>    "Finally there is always the possibility that no common ground
>>>>>>>    can be found for the way some required functionality can be 
>>>>>>> modelled
>>>>>>>    generically across implementations. It would then be the 
>>>>>>> responsibility of
>>>>>>>    the implementers to follow best, or at least de-facto, practice."
>>>>>>>
>>>>>>>    Not sure if this is correct either.
>>>>>>>
>>>>>>>    7. 5.1
>>>>>>>    "may provide according rounding adjusters by passing one of the
>>>>>>>    following parameters" => "may provide rounding adjusters based on 
>>>>>>> one or
>>>>>>>    more of the following:"
>>>>>>>
>>>>>>>    8. 5.3
>>>>>>>    "The JSR's expert group distincts the following types of
>>>>>>>    precision, which are important to distinguish." => "The JSR's 
>>>>>>> expert group
>>>>>>>    identified the following important and distinct precision types:"
>>>>>>>
>>>>>>>    9. 5.3.1.1
>>>>>>>    "does explicitly not specify" => "does not explicitly specify"
>>>>>>>
>>>>>>> Apologies for being picky on the English and grammar.
>>>>>>>
>>>>>>> I am hoping with being between contracts I can play a more active
>>>>>>> role in this project.
>>>>>>>
>>>>>>> ATB,
>>>>>>>
>>>>>>> Tony J
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 15, 2013 at 10:28 PM, Anatole Tresch <atsticks@...
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi everybody in EG
>>>>>>>>
>>>>>>>> so it seems that we can go for the Public Review now...?
>>>>>>>>
>>>>>>>> Everybody please answer with *Yes,* or* No. If No, tell, what you
>>>>>>>> think is still missing or should be improved/changed.*
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Anatole
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Anatole Tresch*
>>>>>>>> Java Lead Engineer, JSR Spec Lead
>>>>>>>> Glärnischweg 10
>>>>>>>> CH - 8620 Wetzikon
>>>>>>>>
>>>>>>>> *Switzerland, Europe Zurich, GMT+1*
>>>>>>>> *Twitter:  @atsticks*
>>>>>>>> *Blogs: **http://javaremarkables.blogspot.ch/*
>>>>>>>> *Google: atsticks
>>>>>>>> Mobile  +41-76 344 62 79*
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Anatole Tresch*
>>>>> Java Lead Engineer, JSR Spec Lead
>>>>> Glärnischweg 10
>>>>> CH - 8620 Wetzikon
>>>>>
>>>>> *Switzerland, Europe Zurich, GMT+1*
>>>>> *Twitter:  @atsticks*
>>>>> *Blogs: **http://javaremarkables.blogspot.ch/*
>>>>> *Google: atsticks
>>>>> Mobile  +41-76 344 62 79*
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Anatole Tresch*
>>> Java Lead Engineer, JSR Spec Lead
>>> Glärnischweg 10
>>> CH - 8620 Wetzikon
>>>
>>> *Switzerland, Europe Zurich, GMT+1*
>>> *Twitter:  @atsticks*
>>> *Blogs: **http://javaremarkables.blogspot.ch/*
>>> *Google: atsticks
>>> Mobile  +41-76 344 62 79*
>>>
>>
>>
>

Attachment: 35C.gif
Description: GIF image

Attachment: 329.gif
Description: GIF image

Attachment: LayoutData.jpg
Description: JPEG image



[JSR-354] Re: Spec for Public Review: Ballot!

(continued)

[JSR-354] Re: Spec for Public Review: Ballot!

Greg Bakos 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Jeff Prestes 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

tom.huesler@... 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Werner Keil 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Stephen Colebourne 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Werner Keil 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Tresch, Anatole (KGVA 28) 10/17/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Tony Jewell 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Werner Keil 10/16/2013

[JSR-354] Re: Spec for Public Review: Ballot!

Anatole Tresch 10/16/2013

Message not available

Message not available

Message not available

Message not available

Message not available

[JSR-354] Re: Spec for Public Review: Ballot!

Werner Keil 10/18/2013
 
 
Close
loading
Please Confirm
Close