[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
> 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
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?