Skip to main content

[JSR-354] Re: LJC JSR 354 Feedback

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Cc: Daniel Bryant <daniel.bryant@...>, Ben Evans <benjamin.john.evans@...>, Martijn Verburg <martijnverburg@...>, Robert Annett <robannett@...>, Jim Gough <jpgough@...>, "Tresch, Anatole" <anatole.tresch@...>
  • Subject: [JSR-354] Re: LJC JSR 354 Feedback
  • Date: Mon, 28 Apr 2014 12:34:42 +0200

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>*
>>
>
>


[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