Skip to main content

[JSR-354] Re: Ballot - please reply soon!

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Ballot - please reply soon!
  • Date: Mon, 8 Apr 2013 23:48:36 +0200

Dear Anatole,

Thanks for the questions.

On Mon, Apr 8, 2013 at 11:35 PM, Anatole Tresch <atsticks@...> wrote:
Dear All

may I ask for a short ballot on the most important points I currently would like have a more common sense about???

Core (answer with Y or N, my opinions are inline):
1) Remove LocalizableCurrencyUnit, LocalizableAmount?  Y
both interfaces are defined but currently not used. Additionally the formatting module defines a LocalizableItem, which basically models the same.
I'm a bit indifferent here, if they were removed, only when MERGED into the subsequent super-interfaces like CurrencyUnit or MonetaryAmount. 
 
2) Use 310 names for methods on MonetaryAmount: N (perhaps rename ulp...)
JSR 310 names like plus, minus, multipliedBy, scaled, negated (paste tense in general),
N
 
 
 
3) Should we replace the methods asType, intValue, doubleValue etc. on MonetaryAmount, with BigDecimal getBigDecimal()? Y

N
(let's not bake in BigDecimal even more if Number was exposed, see below, concrete classes could always override it with BD, e.g. in the Money class could be avoided in the interface via Generics, too)
 
4) Should we support Number as input type on algorithmic operation on MonetaryAmount also? N
e.g. (on Money) Money add(MonetaryAmount) also is defined as Money add(Number).
Y 
 can be used with specific types in concrete classes, but shall remain Number on the interface level, see above. an alternative could be Generics.

5) Should we rename the Rounding interface to MonetaryAdjuster? N
MoneyAdjuster is more bread. MoneyRounding (class) can then implement MoneyAdjuster (interface).
 (too abstract, rarely used in finance)

6) Should we CHange Rounding:  public MonetaryAmount round(MOnetaryAmount amount); would be changed to public <T extends MonetaryAmount> T round(T amount);: Y
With instance of Money value type this would enable to write the following code:
Money m = rounding.round(Money.of("CHF", 1234.34));
Y 
 
7) Should we drop the extensions stuff and introduce corresponding singletons (they still can reuse the ComponentLoader for loading the implementations): Y
Y 
In the absence of a real module concept as of Java 9, using ServiceLoader, OSGi or both seems more future proof here.
 
8) Should we introduce an additional RoundingType, to distinguish the usage such as cash, online, card? N
N (too custom specific
9) Should Region be modelled as extendable class instead of an interface? Y
Y
See ICU4J 
  • Please fill in this form and send it back to me as soon as possible.
  • Please only answer with Y or N, or leave the answer open, if you really do not have an opinion. I want to avoid a broader discussion as of now (which must not mean, that I will start one, if needed, but I think a ballot is enough here, since the topics are rather specific.

Thank very much, for your quick answers!

Regards,


--
Anatole Tresch
Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks
Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79



--

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

Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR

Skype werner.keil | Google+ gplus.to/wernerkeil

* JavaOne Russia: April 23-24 2013, Moscow, Russia. Werner Keil, JCP Executive Committee Member, JSR 354/360 EG Member will present "JSR 321, JSR 354, Standards for the Future of Java Embedded"

* Eclipse Stammtisch: May 15 2013, Zurich, Switzerland. Werner Keil, UOMo Lead, JSR 360 EG Member will present "M4M 2 the Rescue of M2M"

* GeeCON: May 16-17 2013, Krakow, Poland. Werner Keil, JCP Executive Committee Member, JSR 360 EG Member will present "Standards for the Future of Java Embedded"


[JSR-354] Ballot - please reply soon!

Anatole Tresch 04/08/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/08/2013

[JSR-354] Re: Ballot - please reply soon!

Tresch Anatole (KFSC 225) 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Sascha Freitag 04/16/2013

[JSR-354] Re: Ballot - please reply soon!

Stephen Colebourne 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Tresch Anatole (KFSC 225) 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Tresch Anatole (KFSC 225) 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

KFSC 52 04/16/2013
 
 
Close
loading
Please Confirm
Close