[JSR-354] Re: JSR API und Javadoc Updates
- From: Anatole Tresch <atsticks@...>
- To: Jsr 354 JavaMoney Public Mailinglist <jcurrency_mail@...>
- Subject: [JSR-354] Re: JSR API und Javadoc Updates
- Date: Mon, 23 Sep 2013 03:08:29 +0200
thanks for your email. Similar to other feedback I am glad for everyone
that tells his thought, even when you are not always agreeing with our
approaches. The comments
on several aspects are, of course, very helpful. Just one hint from my
side: if tell somethig that e.g. from is now used differently than in 310,
it would be helpful, when you also directly would write what would be your
proposal to change it. This would it make far more easy, to include your
feedback. Similarly with constraints, e.g. constructors defined in the
spec. You can simply say, we should leave that constraints away, or help us
how we can do things better. I would really appreciate that.
BTW: do you wish to meet me before the BOF on Tuesday evening. We can also
discuss the contents of your feedback at that occasion, if you like.
2013/9/23 Stephen Colebourne <scolebourne@...>
> Some comments on more specific items.
> The interfaces specify a serialization format, but that does not make
> sense. Different implementations cannot be serialization compatible as
> the format includes the class name of the implementation.
> CurrencyUnit adds getCashRounding(), but doesn't explain why it is
> needed compared to fraction digits. If there is a use case, then an
> example would be beneficial.
> MonetaryAmount makes an attempt to define lots of implementation rules
> in the spec, but it is really difficult to make it happen.Trying to
> specify constructors for example is difficult as some implementers may
> want only factory methods. The Money class does not implement the
> More broadly, the API is designed in terms of BigDecimal methods, yet
> does not expose BigDecimal.
> MonetaryAmount uses from() as an instance method, where that is now
> used by JSR-310 as a static method.
> The Function/Operator/Predicate interfaces should really have the same
> method names as their JDK8 counterparts.
> MoneyCurrency.withCacheRounding() method name is incorrect Cache ->
> Cash. Cache/no-cache isn't generally an exposed aspect of design.
> The main class is Money, yet the unsigned version is
> UnsignedMonetaryAmount. UnsignedMoney would b better. The real
> question is whether unsigned vs signed is a distinction for runtime or
> compile time.
> MoneyContext is not an appropriate part of the state of a money
> object. The concept of money consists only of a number and a currency.
> Money.equals() is ill-defined. For example, is 2.0 equal to 2.00? What
> about MathContext?
> Money.of() does not specify how numbers are converted to BigDecimal.
> There are two different Double to BigDecimal conversions for example.
> MoneyFunctions/MoneyRoundings don't give examples of their expected use.
> This is just a high level review of the core of the API. I'm not
> repeating broader comments where I disagree with the style and
> approach in general.
> On 20 September 2013 19:30, Anatole Tresch <atsticks@...> wrote:
> > Hi all
> > I now have gone through almost every Javadoc class description and
> > I catched up everything that was missing, especially documentations about
> > thread safety, immutability etc.
> > It could still be that there is something missing, but from my side, I
> > think, we have a state, that we now can show to the public.
> > I want to ask you (EVERYBODY please), to have a look into the attached
> > JavaDoc and source code repo, and really give FAST feedback, so we Harold
> > forward it for publishing again.
> > Feedback deadline will be 16:00 MET tomorrow 21th September.
> > Regards,
> > 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
Java Lead Engineer, JSR Spec Lead
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
Mobile +41-76 344 62 79*