Skip to main content

[JSR-354] Re: LJC JSR 354 Feedback

  • From: Anatole Tresch <atsticks@...>
  • To: Jsr 354 JavaMoney Public Mailinglist <jcurrency_mail@...>
  • Subject: [JSR-354] Re: LJC JSR 354 Feedback
  • Date: Mon, 28 Apr 2014 13:40:01 +0200

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: atsticksMobile  +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: atsticksMobile  +41-76 344 62 79*


[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