Skip to main content

[JSR-354] Re: Spec Updated

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Spec Updated
  • Date: Tue, 15 Oct 2013 12:31:33 +0200

Anatole/all,

Thanks for the feedback. To get a feeling for such option I created
branches named "flexible-subunits" in each relevant repository (no examples
yet)
If you look at the ThreeTen main repo, you'll find myriads of branches,
many of them "explore/..." (worth a thought, maybe we pick up some of the
naming patterns there, too?[?]) and not only due to my EC duty of reviewing
pending JSRs I was involved in a few naming discussions there leading to a
harmonization with the rest of the JSR or choices everyone, especially
Oracle and the JDK team felt was best.

I recall a few thoughts from your discussion with Google also recommended
slightly different ways of numeric representation or access. This isn't
totally different, but comes without a new numeric type for now. And
largely blends in with concepts that make sense for 310. Without a similar
branch or PoC nobody can tell, if the more powerful query could be used in
a convenient and simple way to access subunits.

There was one or the other thought by fellow experts and participants
(we're an open list here, so I can't tell, but believe it was a full EG
member) to get hold of a number of coin types for a particular currency.
While by definition not aimed at paper bills (but coins, especially those
with a dedicated subunit and name) one could use this pattern very easily
for a code snipped like

SubUnit s = SubCurrency.of(MoneyCurrency.of("USD"), "dime");

Won't bother you with the other lines, check out the branch if you like or
further improve it. Effectively while on the highest level fully compatible
with CurrencyUnit (no subunit, even if it was a "multiple" like a "10
Dollar bill" ever makes sense witout the base currency) this encapsulates
all aspects of currency fractions allowing to handle a value like "I got 1
Dollar, 3 Quarters, a Dime and 2 Cent in my pocket" without complex
multi-amount structures or a query.

That doesn't mean the query isn't necessary, but for this kind of
information it seems a bit of an overkill. Besides, there are several
currencies with subunits of "1/5" rather than "1/100" or similar fractions.
As of now, the RI can't handle them.

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 Tue, Oct 15, 2013 at 7:43 AM, Anatole Tresch <atsticks@...> wrote:

> Hi Werner
>
> I agree that subunits are a topic, but imo this topic is fully covered by
> queries/adjusters (you can write your own financial library and support
> subunits on your money class as many as you like) so for me this
> discussions lokks like a ri topic, not a spec topic.
>
> Also to mention is that The numeric representation suggested is for
> interoperability only and quite powerful, even non decimal values are
> mappable to it. It definitively also allows minor units to be mapped.
>
> Cheers
> Anatole
>
> -
> Anatole Tresch
> Glärnischweg 10
> 8620 Wetzikon
> Tel +41 (43) 317 05 30
> -
> Send from Mobile
>
> Am 14.10.2013 um 17:53 schrieb Werner Keil <werner.keil@...>:
>
> At least for Units (stay tuned, the new IoT focus gave some momentum
> especially among new EC members in that area, so has the inclusion of
> JSR-275 to Dozens of projects including Eclipse or Apache despite its JCP
> status, but you said for yourself, the JCP sometimes thinks a little
> differently than e.g. various Open Source communities<338.gif>) there is a
> strong demand for multiples and sub-multiples. The current implementations
> of Unit-API have no need for defining such prefixes on a Spec/API level, if
> future development in that area doesn't change requirements, it may not be
> added to any future JSR either.
>
> I would say strongly defined submultiples of a currency (Just take US
> Dollar, there are several sub-units there used in everyday life<347.gif>
> http://en.wikipedia.org/wiki/Us_dollar, Japan or BTC are other examples,
> but there must be more than just US$ in physical currencies using distinct
> sub-multiples, too)
>
> This makes the simple getMajor/Whole getFraction (after all, "good old
> java.util.Currency" had 
> *getDefaultFractionDigits<http://docs.oracle.com/javase/7/docs/api/java/util/Currency.html#getDefaultFractionDigits()>
> *()) insufficient.
> The multiples aside from local variations (e.g. Cr./Lkh. insteead of
> Mill./Bill, but even in German "Billion" is "Milliarde" and our "Billion"
> has a higher value) probably don't need special attention, but
> sub-multiples are a different story, especially with some of the most
> important currencies in the world using more than just one.
>
> Chinese currency just like Japanese also has 2 common sub-units
> http://en.wikipedia.org/wiki/Chinese_currency
>
> JDK made the mistake of ignoring some of those for over a decade, forcing
> people to reinvent the wheel. We should simplify and standardize at least
> some of that, otherwise they'd stick with java.util.Currency and BigDecimal
> after all.
>
> 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"
>
>
> On Mon, Oct 14, 2013 at 5:34 PM, Stephen Colebourne <scolebourne@...>wrote:
>
>> Date and Time is not the same as Money, or other amounts (such as
>> Kilograms or Volts).
>>
>> Date/Time uses fields, such as years/months/days/hours/minutes which are
>> not always resolvable. For example, "6 months and 3 days" cannot be
>> simplified without addition to an actual date.
>>
>> By contrast, Kilograms, or USD represent a single number associated with
>> the unit.
>>
>> Thus while I initially thought that a MonetaryUnit would be useful,
>> allowing things like THOUSANDS, MILLIONS, TENTHS, the reality is that it
>> adds complexity for little gain. The underlying system being modelled is so
>> simple (currency + number) that anything on top of that tends to get in the
>> way.
>>
>>
>> The query and adjuster interfaces exist to allow algorithms to work
>> *based on a single input monetary amount*. Thus a query might be "is
>> positive", "is negative", "is greater than my trading limit". But it might
>> also be "split the input money into three even parts":
>>
>> MonetaryAmount amount = ...
>> boolean isNegative = amount.query(isNegativeQuery());
>> boolean isZero = amount.query(isZeroQuery());
>> MonetaryAmount[] split = amount.query(splitEvenly(3));
>>
>> The point is that a query/adjuster can be written once and work with any
>> implementation of the JSR, not just one. That will be a vital feature when
>> writing formatters.
>>
>> The spec now gives more detail on adjusters and queries.
>>
>> Stephen
>>
>>
>>
>>
>>
>>
>> On 14 October 2013 15:55, Werner Keil <werner.keil@...> wrote:
>>
>>> Except 310 defined *both*, why? The equivalent to
>>> TemporalAmount.get(TemporalUnit) would make sense for
>>> MonetaryAmount.get(CurrencyUnit)
>>>
>>> Please show (ideally we might like that in the spec document or at least
>>> JavaDoc of MonetaryQuery to make it a little more concrete and allow 
>>> people
>>> to understand what to do with it)
>>> an equivalent with the Query<35F.gif>
>>>
>>> I understand it could be used that way, but from a gut feeling (and
>>> that's exactly what the "spec" as of now it's only JavaDoc there, for 310
>>> says, that you should not use queries there) MonetaryQuery would be "Show
>>> me the total debt of the United States?" while it seems like an overkill
>>> for "How many Satoshi are in this Bitcoin amount?".
>>>
>>> Cheers,
>>> Werner
>>>
>>>
>>> On Mon, Oct 14, 2013 at 4:20 PM, Anatole Tresch <atsticks@...>wrote:
>>>
>>>> I do not think, we miss monetary Fields in the spec. For major, minor
>>>> we may implement according adjusters/queries. For different minor unit
>>>> types for bitcoin you can do the same using monetary queries...
>>>> Exactly as for temporal fields...
>>>>
>>>> Cheers
>>>> Anatole
>>>>
>>>> -
>>>> Anatole Tresch
>>>> Glärnischweg 10
>>>> 8620 Wetzikon
>>>> Tel +41 (43) 317 05 30
>>>> -
>>>> Send from Mobile
>>>>
>>>> Am 14.10.2013 um 12:42 schrieb Werner Keil <werner.keil@...>:
>>>>
>>>> Anatole,
>>>>
>>>> I assume you refer to
>>>> http://download.java.net/jdk8/docs/api/java/time/temporal/TemporalQuery.html
>>>>  well,
>>>> IMHO we're still missing a MonetaryField.
>>>> That's precisely the element that allows something that would be
>>>> >The MonetaryField interface provides another mechanism for querying
>>>> monetary amounts. That interface is limited to returning a long. By
>>>> contrast, queries can return any type.
>>>> I am not sure, if the query (much more an enterprise feature from what
>>>> we discussed) makes sense on a JDK level, but if Java 8 throws it into 
>>>> the
>>>> already monolithic giant pot for Time, we might as well do so for
>>>> Money/Currency<35C.gif>
>>>>
>>>> See Japan or other examples with multiple submultiples of a whole
>>>> amount, or Google's recommendation, I think the current "Major/Minor"
>>>> approach is not sufficient for an interface that should also match the
>>>> general idea behind TemporalAmount.
>>>>
>>>> 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"
>>>>
>>>>
>>>> On Mon, Oct 14, 2013 at 8:25 AM, Anatole Tresch <atsticks@...>wrote:
>>>>
>>>>> Hi Werner/all
>>>>>
>>>>> we see already use cases for queries using functional style, e.g.
>>>>> counting the number of amounts that exceeds some amount, or more 
>>>>> generally
>>>>> implementing predicates for queries or statistical calculations. So I
>>>>> clearly agree with Stephen on the requirement to have an extension point
>>>>> that is not required to return monetary amounts.
>>>>>
>>>>> I think it is a very important point to stick to the naming of 310
>>>>> here. So I do not see any reasons to change anything here.
>>>>>
>>>>> Cheers,
>>>>> Anatole
>>>>>
>>>>>
>>>>>
>>>>> 2013/10/14 Werner Keil <werner.keil@...>
>>>>>
>>>>>> Adjuster somewhat similar to Rounding feels OK, it's like turning a
>>>>>> wheel. The query feels a bit abstract and JavaMoney already contains
>>>>>> clearer functional interfaces meant for Lambda, too;-)
>>>>>>
>>>>>> Without a strong use case I'm not sure, if query makes sense.
>>>>>> Will check with other JSRs, there are at least 2 others defining a
>>>>>> "query" mechanism.
>>>>>>
>>>>>> Werner
>>>>>> Am 14.10.2013 00:03 schrieb "Stephen Colebourne" <
>>>>>> scolebourne@...>:
>>>>>>
>>>>>>> Adjuster and Query are a very open variation of the strategy design
>>>>>>> pattern. They allow behaviour to be encapsulated outside of the main
>>>>>>> money class. They are named and behave exactly as per JSR-310, which
>>>>>>> users of the API will appreciate. They also fit well into a
>>>>>>> functional/lambda world.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 13 October 2013 18:13, Werner Keil <werner.keil@...> wrote:
>>>>>>> >
>>>>>>> > So far MonetaryQuery.queryFrom() is used 3 times in the RI.
>>>>>>> >
>>>>>>> >
>>>>>>> > The JavaDoc
>>>>>>> >  /** * Queries this monetary amount for a value. * <p> * This
>>>>>>> queries this amount using the specified query strategy object. * <p> *
>>>>>>> Implementations must ensure that no observable state is altered when 
>>>>>>> this *
>>>>>>> read-only method is invoked. * * @param <R> * the type of the result *
>>>>>>> @param adjuster * the query to invoke, not null * @return the query 
>>>>>>> result,
>>>>>>> null may be returned (defined by the query) */
>>>>>>> >
>>>>>>> > is a bit buggy to start with. "adjuster" should be called query,
>>>>>>> and the whole notion of query(Query) seems a little odd.
>>>>>>> > The text should be clarified, "value" is meaningless, especially
>>>>>>> since you need to pass a query and all that query does so far is to 
>>>>>>> route
>>>>>>> to its internal (less conveniently named) proxy method. I think we 
>>>>>>> should
>>>>>>> try to untangle that, it feels a bit redundant.
>>>>>>> >
>>>>>>> > Werner
>>>>>>> >
>>>>>>> > On Sun, Oct 13, 2013 at 6:53 PM, Werner Keil <
>>>>>>> werner.keil@...> wrote:
>>>>>>> >>
>>>>>>> >> Anatole/all,
>>>>>>> >>
>>>>>>> >> I changed a few links to the Git repositories already as they
>>>>>>> were outdated.
>>>>>>> >>
>>>>>>> >> Just rephrased a method to match the actual code, but the JavaDoc
>>>>>>> in MonetaryQuery leaves more questions than we would like to see 
>>>>>>> unanswered.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>  * It is recommended to use the second approach, {@code
>>>>>>> query(MonetaryQuery)},
>>>>>>> >>  * as it is a lot clearer to read in code.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> If it is recommended to use a totally different method, then
>>>>>>>  can't we just call it query() and use that interface, or let's drop
>>>>>>> MonetaryQuery from the spec to avoid lose ends?
>>>>>>> >>
>>>>>>> >> These "we specify A,  but you should use B because A has a stupid
>>>>>>> name" makes no sense and confuses people.
>>>>>>> >>
>>>>>>> >> There's already enough ambiguity e.g. in the current JSPA or
>>>>>>> Process document, some of us in the EC hope to resolve, so couldn't 
>>>>>>> we try
>>>>>>> to keep that out of specs please
>>>>>>> >>
>>>>>>> >> Cheers,
>>>>>>> >> Werner
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Sun, Oct 13, 2013 at 10:32 AM, Simon Martinelli <
>>>>>>> simon.martinelli@...> wrote:
>>>>>>> >>>
>>>>>>> >>> Hi Anatole,
>>>>>>> >>>
>>>>>>> >>> I was 3 weeks in vacation but now I am back and read the spec.
>>>>>>> >>> Unfortunately I am not able to add comments. Can you please give
>>>>>>> me the necessary authorization?
>>>>>>> >>>
>>>>>>> >>> Thanks,
>>>>>>> >>> Simon
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On Sat, Oct 12, 2013 at 9:08 PM, Anatole Tresch <
>>>>>>> atsticks@...> wrote:
>>>>>>> >>>>
>>>>>>> >>>> Dear all
>>>>>>> >>>>
>>>>>>> >>>> I have updated the spec and accommodated the latest input,
>>>>>>> mainly from Stephen. I think we have a small, comprehensive and very
>>>>>>> elegant spec, so thanks to all (especially Stephen) for your time and
>>>>>>> contributions.
>>>>>>> >>>> I have left some comments, so you may see easily, where there
>>>>>>> might be points to be discussed.
>>>>>>> >>>>
>>>>>>> >>>> So please revise the spec once more, and add your comments
>>>>>>> directly into the document (as Google Doc comment). If you feel OK, 
>>>>>>> with
>>>>>>> the current state to progress, please add a comment at the end of the
>>>>>>> document, so I know we have now an agreement on the current document 
>>>>>>> and I
>>>>>>> see who finally has read it!
>>>>>>> >>>>
>>>>>>> >>>> Here is the link:
>>>>>>> >>>>
>>>>>>> https://docs.google.com/document/d/1FfihURoCYrbkDcSf1WXM6fHoU3d3tKooMnZLCpmpyV8/edit#heading=h.5wnzm49wl111
>>>>>>> >>>>
>>>>>>> >>>> I would be glad, if we can do that within the next 2-3 days, so
>>>>>>> we can then finally publish our Public Review. I will check now, if 
>>>>>>> the API
>>>>>>> JavaDoc requirements are aligned with the current spec.
>>>>>>> >>>>
>>>>>>> >>>> Have a nice weekend!
>>>>>>> >>>> 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*
>>>>>
>>>>
>>>>
>>>
>>
>

Attachment: 329.gif
Description: GIF image



[JSR-354] Re: Spec Updated

(continued)

[JSR-354] Re: Spec Updated

Anatole Tresch 10/13/2013

[JSR-354] Re: Spec Updated

Stephen Colebourne 10/13/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/13/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/14/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/14/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/14/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/14/2013

[JSR-354] Re: Spec Updated

Stephen Colebourne 10/14/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/14/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/15/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/15/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/15/2013

[JSR-354] Re: Spec Updated

Mark Davis ☕ 10/15/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/13/2013
 
 
Close
loading
Please Confirm
Close