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 15:24:32 +0100

On 23 September 2013 05:01, Anatole Tresch <atsticks@...> wrote:
>> 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.
>
> should we leave the choice to the implementation, how amounts are created?
> That would possibly lead to incompatibilities... WDYT?

I think there is limited value to specifying static methods in
description. No user can call them except by reflection, and such a
reflective approach would only be used by low level XML/JSON type
serialization frameworks who are very used to dealing with such issues
without guidance (which they wouldn't rely on anyway).

>> MonetaryAmount uses from() as an instance method, where that is now
>> used by JSR-310 as a static method.
> Should we use with instead?

The use of with as a prefix for methods that alter some but not all of
an immutable object has become reasonably well established now.

>> The Function/Operator/Predicate interfaces should really have the same
>> method names as their JDK8 counterparts.
>
> That would make it difficult that users can distinguish between them, once
> JDK8 is under the hood. Why this should a good idea, my experience says that
> naming things differently is not a bad thing, if they are the same the will
> be easily confused. Are there explicit criterias, why it should be better to
> name them the same, but in a different packages...?

Its hard to determine from the Javadoc what you intend people to do
with these things. With JSR-310, the adjuster and query are invoked by
methods on the main interfaces - Temporal has a with(TemporalAdjuster)
method for example, which links everything together.

> UnsignedMonetaryAmount is not anymore part of the API. There is a singleton
> factory class ConstraintMonetaryAmount, which allows to create
> MonetaryAmounts that ensure a Predicate is true, after each operation
> returning an amount as result. Creating an unsigned amount is also possible
> by a separate factory method. Must check, if the spec is not up to date
> there...

I'm reading the last Javadoc you sent.

I'll note that JSR-310 and other JDK classes like String, Integer etc
could have a constraint concept, but do not.

>> Money.equals() is ill-defined. For example, is 2.0 equal to 2.00? What
>> about MathContext?
>
> The current spec defines that in SE both numeric parts must be converted to
> BD, ...

I've found that defining equals in interfaces often causes a lot of
problems. JDK collections do, but lots of other interfaces do not.

This comes back to a point I've made before. You have to decide what
type you want the user to declare and use in method parameters, return
types and variables. With JDK collections you write:
 List a = new ArrayList()
but with JSR-310 you write
 LocalDate date = LocalDate.now();

So long as your users are declaring concrete types, the equals method
can be only on the concrete type.

As you know, I believe value type APIs should use the latter approach.

>> Money.of() does not specify how numbers are converted to BigDecimal.
>> There are two different Double to BigDecimal conversions for example.
> How this is best done, from your experience?

See 
http://www.joda.org/joda-money/apidocs/org/joda/money/Money.html#of%28org.joda.money.CurrencyUnit,%20double%29

Stephen


[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