Skip to main content

[JSR-354] Re: JSR API und Javadoc Updates

  • From: Stephen Colebourne <scolebourne@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: JSR API und Javadoc Updates
  • Date: Mon, 23 Sep 2013 01:46:32 +0100

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
spec.

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.
Stephen




On 20 September 2013 19:30, Anatole Tresch <atsticks@...> wrote:
> Hi all
>
> I now have gone through almost every Javadoc class description and hopefully
> 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


[JSR-354] JSR API und Javadoc Updates

Anatole Tresch 09/20/2013

[JSR-354] Re: JSR API und Javadoc Updates

Stephen Colebourne 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Anatole Tresch 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Stephen Colebourne 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Anatole Tresch 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Anatole Tresch 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Werner Keil 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Anatole Tresch 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Stephen Colebourne 09/23/2013

[JSR-354] Re: JSR API und Javadoc Updates

Werner Keil 09/23/2013
 
 
Close
loading
Please Confirm
Close