[JSR-354] Re: JSR API und Javadoc Updates
- From: Werner Keil <werner.keil@...>
- To: "jcurrency_mail@..." <jcurrency_mail@...>
- Subject: [JSR-354] Re: JSR API und Javadoc Updates
- Date: Mon, 23 Sep 2013 09:15:52 -0700
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
Language Champion | Java Godfather
Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
* JavaOne US 2013: Sep 23-26 2013, San Francisco, USA. Werner Keil, JCP EC
Member, JSR 351/354 EG Member will co-present "Java Identity Management",
Security", "JSR 354"
* JMaghreb 2.0: Nov 7-8 2013, Casablanca, Morocco. Werner Keil, JCP EC
Member, JSR 354 EG Member will present "Java Social", "JSR 354"
On Mon, Sep 23, 2013 at 7:24 AM, Stephen Colebourne <scolebourne@...>wrote:
> 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
> > 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.
Can you give examples for that. I saw in some parts of JDK 8 also CLDC the
of() static factory has been used by libraries other than java.time. How
> >> 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,
> > JDK8 is under the hood. Why this should a good idea, my experience says
> > naming things differently is not a bad thing, if they are the same the
> > 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
> > 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
> > 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
> > 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.
Note, *Money *is an RI class but not the interface, unless I missed some
last minute renaming of MonetaryAmount to Money[?]
> 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.
Wherever this works the latter sounds fine.
> >> 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?
Description: GIF image