As mentioned in the separate reply to Jez/Stephen's conversation, taking the part that's mostly in "temporal" of java.time in an appropriate manner for money and currency (hence a possible draft is an interface like Monetary or the current form MonetaryAmount and CurrencyUnit, that also driven by the existing JDK class) as inspiration.As you may know, the "format" module is much more inspired by JodaMoney anyway, so it shows quite some similarities.
One aspect 310 is simply missing and Date/Time needs in far less cases except "show me a year in seconds" is conversion between monetary units. While concrete implementations may be restricted to a monetary type provided with such RI, like the suggested Money class, and ISO currencies, the general contract of conversion at least along the lines of what's identified so far should be there, too. Without predicting how modular SE 9 will be in the end, this could be an "optional" module of a future JDK, but except for maybe the part that sits on top of java.util.Currency used across a vast majority of other APIs I would say even formatting could be optional or at least modular here.WernerOn Mon, Jan 28, 2013 at 11:52 PM, Werner Keil <werner.keil@...> wrote:
Thanks a lot for starting that thread.
As mentioned in the SPI discussion once or twice, it's not all black or white in SE either. The whole ServiceProvider mechanism is the best example beside other SE frameworks like Collection API.
As a matter of fact, the final Currency class internally makes heavy use of: http://docs.oracle.com/javase/6/docs/api/java/util/spi/CurrencyNameProvider.html
It may just be badly documented, but theoretically one could add another implementation if you handle classloading the right way.
E.g. I provided a drop-in translation for JDK's Swing by adding resource bundles in the right place like jre/lib/ext (haven't tried that in a long time, but according to StackOverflow it still exists for Java 7: http://stackoverflow.com/questions/8773081/should-putting-a-jar-file-in-lib-ext-work-instead-of-using-a-classpath-on-window)
So it's a question of good API design whether you allow this or not. Even 310 has a few extension points. Not as many as people who want e.g. to deal with working days vs. bank holidays may wish, but e.g. the "calendar" package contains out of the box extensions to "Chrono" while the abstract base class allows other cultures to add further calendars. Not everything is final and inflexible in SE either, and Java 9 with aim for modularity will demand even more of that.
The real question is not SE vs. EE, but having the RI under an Umbrella like SE as opposed to a standalone RI.
The timeframe of SE 9 is relatively predictable, some time around 2 years from now.
EE 8, which could benefit from a standalone implementation (let's leave ME and CLDC 8 aside, as they are not real Umbrella JSRs, but effectively it would be similar) isn't likely to come out right next year either to be quite honest. If you look at EE 6, that went public in December 2009, so it was roughly 3 years ago, and 3 1/2 years before the projected EE 7 release timeframe this spring. It is unlikely even with a drastically reduced scope, that EE 8 will launch more than 2 years from now either.
Making up the mind about the preference inside the EG is a good idea, while the ultimate decision about where they feel they want to include such JSR is up to Umbrella JSR Spec Leads of either EE or SE. It's probably a good idea to seek their input, too.
When Victor last spoke about that, I believe he had some conversation with Brian, Mark or others, mainly signalling, that given stuff that's already been deferred to SE 9 and the progress of the JSR they would not consider it for SE 8, as the proposal stated.
Given the modular nature of SE 9, it could be a good idea to ask them. Even before modularity, Swing by far isn't the only "javax" package. What's considered SE 7 is full of it: http://docs.oracle.com/javase/7/docs/api/ There are more main packages under javax. thatn java in all of that.
JSR 6, javax.print is a good example, also defines both interfaces like Doc and concrete implementations like SimpleDoc, a final class, but for a good reason there is an interface defining the behavioral contract and allows extensions, despite those kinds of JSRs having been a part of the Java SE platform almost forever.
Am 28.01.2013 21:43 schrieb "Anatole Tresch" <atsticks@...>:
Dear all!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, soin 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
[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED