I started adding comments but it’s getting late so I’m going to print it off and read tomorrow. Will give you feedback then.
From: Anatole Tresch [mailto:atsticks@...]
Sent: 28 January 2013 21:26
Subject: [JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
hereby I also forward hereby the link to the EDR working document:
Many of the things therein may render obsolete or may be adapted, but in the first part there is a small section about use cases (the list is most probably not yet complete).
Would be nice if one or another can comment on the use cases (perhaps directly within the document should be possible).
2013/1/28 Anatole Tresch <atsticks@...>
For me it is crucial that we really know what for a SE targeting JSR is really required by Oracle. Whereas in an EE context decoupling is absolutely crucial, so interfaces are really the better way accessing "things", we have to discuss these things in a SE context obviously. Personally if it is really required as described by Stephen (which I guess is the case, thanks Stephen), I am asking me, also having a in mind the complexity of use cases seen, if we are not better to target both EE and SE, or even EE without SE.
Let me explain a bit my considerations:
Variant 1: Separation into a SE and EE part:
In the SE part:
- we define the interfaces for a simple CurrencyUnit, and adapt the java.util.Currency class accordingly. We keep the interface simple and stupid (no historization, no attributes or extensions), just supporting one single namespace (ISO-4217).
- we define the interface for MonetaryAmount and provide an implementation based on BigDecimal, with all the of(XX) factories on it and what else is required. I assume BD is currently a feasible way to go, though we know that it is not sufficient for all usage scenarios.
- we define the arithmetics and the precision handling and the serialization format.
As we know already that will fit well for simple usage scenarios, the more complex ones must be defined outside of SE, since it makes not sense to build these aspects in stone, so
in the EE part:
we define the other (extended) things, such as
- API/SPI for multiple numeric representations.
- API/SPI for custom currency support
- API/SPI for currency historization
- API/SPI for currency exchange
- API/SPI for extended formatting
- API/SPI for extensions (if needed at all)
Or we throw away completely the SE restrictions and focus directly on...
Variant 2: Leaving SE for EE:
GO for an EE specification leaving SE as is also has its advantages:
- the current JDKs classes can easily be adapted (as they are adapted in our current RI), so we can introduce the concepts here for several JDKs, e.g. starting from JDK 7.
- the main behaviour can be modelled and defined by interfaces as of now, leaving much more details to the implementations. This would us also allow to easily provide the flexibility that has shown to be required by many of the real world use cases (see attachment).
At a first look, this looks like a complete off-topic. But when a think about our sometimes really ugly discussions here, it may be worth to think about. Both variants would allow as to focus on the requirements specific to SE/EE. Also since we have seen that it is very difficult to create one-fits-it-all solution, we perhaps have to abandon the objective of creating a SE implementation that is exactly doing that.
All variants would us also easily allow to keep in mind (not targeting) as a side-effect (indirectly, not explicitly) ME. In all scenarios I do not see this JSR will directly be able to provide the ME part by itself. The ME colleagues (and Werner ;-)) may open their own JSR and use the stuff defined in our JSR as a starting point ;-) When done well the API may look quite similar, though it was defined in two separate JSRs.
We have to agree on this aspects, since this is really crucial! So, all EG members are invited to give their opinions on this!
[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
|Tresch Anatole (KFSC 225)||01/29/2013|