Skip to main content

[JSR-354] Re: LJC JSR 354 Feedback

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: LJC JSR 354 Feedback
  • Date: Tue, 29 Apr 2014 12:37:53 +0200

Anatol/all,

Thanks for the update.
Instead of the generic setTimestamp() methods the attributes sound a bit
more flexible, but I agree, a simple long value for a timestamp even if it
was more or less a convenience method mapped to an attribute of type Long
sounds reasonable. Especially if you look at myriads of redundant setters
and getters all across JSR 310 it would still look and feel rather clean
and lean[?]

Cheers,
Werner

On Tue, Apr 29, 2014 at 11:37 AM, Tresch, Anatole <
anatole.tresch@...> wrote:

>  Hi Werner/all
>
>
>
> I updated the API branch so it is not using any long timestamps anymore.
> Basically it would work this way, but may recommend to set type safe
> parameter objects as attributes,  and not using just plain named
> attributes, because you easily will have some misspelling with names ;-(
>
>
>
> So instead of:
>
>
>
> *new *ConversionContext.Builder(“myProvider”).*setAttribute(“timestamp”,
> 12345567L)….* .create();
>
>
>
> It would be much more type-safe to do something like:
>
>
>
> *new *ConversionContext.Builder(“myProvider”).*setAttribute(new
> MyParams().*setTimestamp(1234567L)… .create()).create();
>
>
>
> Nevertheless it is questionable if we should really omit long timestamps,
> where they make sense.
>
>
>
> What would be possibly a good ide is enhancing the context functionality
> by also adding methods like:
>
>
>
> Boolean getBoolean(Object key);
>
> Boolean getBoolean(Object key, Boolean defaultValue);
>
> Integer getInt(Object key);
>
> Integer getInt(Object key, Integer defaultValue);
>
> …
>
> And on the Builder:
>
>
>
> Builder setBoolean(Object key, Boolean value);
>
> Builder setInt(Object key, Integer value);
>
>
>
> This would reduce much boilerplate client code that has to be written to
> use the these generic contexts (one of the outcome of adapting the RI to
> the new reduced API proposal).
>
> WDYT?
>
>
>
> Cheers
>
> Anatole
>
>
>
>
>
> *From:* Anatole Tresch [mailto:atsticks@...]
> *Sent:* Montag, 28. April 2014 13:40
> *To:* Jsr 354 JavaMoney Public Mailinglist
> *Subject:* [JSR-354] Re: LJC JSR 354 Feedback
>
>
>
> Hi Werner
>
>
>
> where do you see a "generic timestamp" - I do not see any. The
> ConversionContext already in previous releases extended AbstractContext and
> therefore allows adding any arbitrary attributes, identified by name or
> type.
>
>
>
> The most typesafe usage would be that each rate provider would define its
> own parameter object, so one could then do something like:
>
>
>
> ConversionContext ctx = new ConversionContext.Builder().setAttribute(new
> MyParams1(...)).setAttribute(new MyParams2(...)).create();
>
> ExchangeRateProvider prov = MonetaryConversions.getRateProvider(ctx,
> "real", "A", "B");
>
> ...
>
>
>
> Hereby I assume that provider *"A"* is consuming MyParams1and provider
> *"B"* is consuming MyParams2.
>
>
>
> Consequently it depends on the provider, what makes sense. In reality you
> may have a realtime provider (*"real" *first in the chain, that may not
> be able to deliver anything (or even does not require any specific
> configuration). *MyParams1 *then could take long timestamps, and
> MyParams2 may also support LocalDate and other new stuff, either from the
> threeten backport or from the JDK9 libs. So it seems to me a simple but
> flexible API, which is able to cover any complexities and nevertheless is
> simple is use for simple use cases.
>
> Also the different usages of context with the new proposal is uniform.
> They same mechanism applies to AmountFormatContext, ConversinoContext and
> ProviderContext.
>
>
>
> I will have to leaf now for some hours, hooking up later on the discussion
> ;-)
>
>
>
> Cheers,
>
> Anatole
>
>
>
>
>
>
>
>
>
>
>
> 2014-04-28 12:34 GMT+02:00 Werner Keil <werner.keil@...>:
>
> All,
>
>
>
> Looking at the GitHub branch and comparing it with master, the recently
> introduced Generic timestamp seemed a bit irritating. Given almost every
> type in the "convert" package is a final class, not interface, without any
> (generic or not) time reference currency conversion won't work.
>
>
>
> I could not see a similar branch for RI or TCK, so the "working" in the
> branch refers to a Maven build only, or are there working examples and
> implementations, too?
>
>
>
> Cheers,
>
> Werner
>
>
>
> On Mon, Apr 28, 2014 at 11:34 AM, Werner Keil <werner.keil@...>
> wrote:
>
>  Anatole,
>
>
>
> Thanks for the update. I'll have a look when I can access Google Docs
> later. The API must not have any reference to 310 which is only one (fairly
> isolated) part of Java 8, there are at least 2 or 3 other Date/Time APIs in
> Java now, and 2 others have been either newly introduced (JavaFX) or
> significantly improved (including Date/Calendar) so fragmentation is
> inevitable. Not to mention it'll never work in the environment with the
> broadest adoption (ME;-)
>
>
>
> If an implementation RI is tweaked in ways that use either of these
> competing Date/Time APIs, why not. A UTC timestamp is still the way actual
> users will get their data, in most cases from a reliable time server. Those
> servers don't know or care about JSR 310, so let's not overengineer the API
> or make it hard to use and memory-wasting where real world scenarios
> require simple and interoperable solutions.
>
>
>
> Regards,
>
> Werner
>
>
>
> On Mon, Apr 28, 2014 at 10:24 AM, Anatole Tresch <atsticks@...>
> wrote:
>
> Hi all
>
>
>
> so I reviewed your feedback and also made a simplification proposal:
>
>    - *Remove all timestamp references from the API*, since we have *contexts
>    *in place to pass parameters for conversion, exchange rates etc. we do
>    not need to expose timestamps explicitly in the API and therefore could
>    avoid the conflicts about 310 types...
>    - Let formatting be configured by a *AmountFormatContext*. This
>    replaces the former AmountStyle, but is also more flexible and would
>    allow to support any further use cases as pointed out in the LJC feedback
>    more easily and naturally. Additionally implementation of the SPIs is
>    getting simpler (2 spis could be even removed completely).
>
>  You can find a complete branch of the API project here:
>
> https://github.com/JavaMoney/jsr354-api/tree/LJC-working
>
>
>
> Find all details, including the very detailed and helpful feedback from
> LJC here:
>
>
>
>
> https://docs.google.com/document/d/1ibRbGWxSxM7eRlARuiQqqsBsjlEaEKLpGiiVGzCFQ5Q/edit#heading=h.yong8ng796pl
>
>
>
> So please have a look at the document. I do some proposals for API changes
> (simplifications). so you are invited to give feedback, too ;-)
>
>
>
>
>
> Regards,
>
> Anatole
>
>
>
>
>
>
>
>
>
> 2014-04-27 23:02 GMT+02:00 Tresch, Anatole <
> anatole.tresch@...>:
>
>
>
> Sent with Good (www.good.com)
>
>
> -----Original Message-----
> *From: *Daniel Bryant [daniel.bryant@...]
> *Sent: *Sunday, April 27, 2014 05:01 PM
> *To: *Tresch, Anatole (KGVX 42)
> *Cc: *Robert Annett; James Gough; Martijn Verburg; Ben Evans
> *Subject: *LJC JSR 354 Feedback
>
> Hi Anatole,
>
> I hope that you are keeping well, and that the work on JSR 354 is
> progressing nicely? Thanks again for sharing the VM image with me in
> JavaLand, and this has prompted some great discussion within the LJC.
>
> I've included a link to a Google doc below, which contains feedback from
> the LJC. This has been primarily compiled by Robert Annett (cc'd), who has
> spent quite a bit of time reviewing the specification, and has formed some
> great comments and questions. The rest of us on the address list have also
> been involved with the discussion, and are happy to offer help where we can.
>
>
> https://docs.google.com/document/d/1svKJVxihMSWq1NsY5LQDrQ-OE0rsL9M8e1ErSh8wMmU/edit
>
> As Martijn has already mentioned, we would be happy to help organise a
> hackday over here in London within the LJC, and so the next thing to do is
> to attempt to pick a date that works best with everyone involved. If we are
> all in agreement, I can create a Doodle poll for this - I assume a weekend
> would be the best day (and Robert I appreciate you won't be able to make it
> up to London on a weekend, but perhaps we can Skype you in for a brief
> chat?)
>
> Please do let me know if you have any problems accessing the document, or
> if you have any comments or questions.
>
> Best wishes,
>
> Daniel
>
>
>  --
> *Daniel Bryant  |  Software Development Consultant  |  www.tai-dev.co.uk
> <http://www.tai-dev.co.uk/>*
> daniel.bryant@...  |  +44 (0) 7799406399  |  Twitter:
> @taidevcouk <https://twitter.com/taidevcouk>
>
>
>
>
>
> --
>
> *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/
> <http://javaremarkables.blogspot.ch/>*
>
>
> *Google: atsticks Mobile  +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>
>
>
>
>
>
>
>
>
> --
>
> *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/
> <http://javaremarkables.blogspot.ch/>*
>
>
> *Google: atsticks Mobile  +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>

Attachment: 338.gif
Description: GIF image



[JSR-354] Re: LJC JSR 354 Feedback

Anatole Tresch 04/28/2014

[JSR-354] Re: LJC JSR 354 Feedback

Werner Keil 04/28/2014

[JSR-354] Re: LJC JSR 354 Feedback

Werner Keil 04/28/2014

[JSR-354] Re: LJC JSR 354 Feedback

Werner Keil 04/28/2014

[JSR-354] Re: LJC JSR 354 Feedback

Anatole Tresch 04/28/2014

[JSR-354] Re: LJC JSR 354 Feedback

Werner Keil 04/28/2014

[JSR-354] Re: LJC JSR 354 Feedback

Tresch, Anatole 04/29/2014

[JSR-354] Re: LJC JSR 354 Feedback

Werner Keil 04/29/2014
 
 
Close
loading
Please Confirm
Close