To point 2)
The specification REQUIRES explitly that <T> T asType(Class<T>) must support also java.lang.Number (and ubstypes) and java.math.BigDecimal. This will also must be tested by the TCK.
So the only thing is that it not modeled explicitly similar to the methods already in place.
Basically, JIRA is good place, since it allows to focus on different area and is for sure more organized than a mailing list ;-)
Now also I have admin access on it and will create according components, so also features/requriements/tasks can be organized accordingly.
CREDIT SUISSE AG
Information Technology | Java Core Framework & Support, KSXK 23
Zollstrasse 20/36 | 8070 Zürich | Switzerland
Phone +41 44 334 03 89
Thanks for your follow-up.
1) Timestamp Modelling
My feeling is that SE/EE only is a reasonable price to pay for usable temporal types, and my personal feeling (gazing into the crystal ball) is that the capabilities of SE embedded type devices will continue to grow in many domain. For Java prior to 8, I would be willing to accept a (not 100% compatible) backport of the RI.
I guess the driver behind my original thought is that we only directly expose floating point types as complete (exported) representations, or the discrete components, otherwise you are dependent on the implementation capabilities (for BigDecimal) not the specified API. I guess in part this comes down to how much we want to scale down to embedded again. I guess we need to form a definitive point of view on this. For me general purpose usability trumps the embedded case (consistent I think with our low-latency financial is not a core concern starting position)
Quite of the few of the other points look like they could be logged to Jira to be considered when the Java core becomes stabilised? Is this the right approach?
Thanks for the message.
On Wed, Jan 30, 2013 at 12:13 PM, Anatole Tresch <atsticks@...> wrote:
As already mentioned Chris Pheby has added some valuable comments and questions, which are worth to be discussed also here:
1) Timestamp Modelling:
Java Batch JSR has exactly the same decision regarding Minimum Java Version to support, for backward compatibility of the standalone version (aside from taking part in the Java EE 7 Umbrella) with earlier Java versions, they decided NOT to use features of SE 7 like AutoCloseable (allowing try-with-resource from SE 7)
We have to ask exactly the same question, and maybe Anatole/CS know that best, if SE 7 or even 6 should still work with JSR 354. The way(s) it'll be distributed even on the SE/EE side are not yet written in stone, and unless an SE 9 JEP or sub-project is accepted, this is still a "standalone" JSR anyway.
So do we want to have the Minimum Version of SE 8 (and SE/EE only, at the moment, there is no evidence, 310 will ever even make it into SE Embedded due to its size and anti-modular design) or be open to at least SE/EE 7, too? If so, 310 is an absolute No-Go, and only java.util.Date and similar objects acceptable.
JSON JSR had a similar conflict, but there most values are driven by the underlying datatype, so it doesn't reproduce most of BigDecimal/Number methods, but have a bigDecimalValue() if the data type is BigDecimal or a longValue(), probably a Long class, not primitive, for other types, e.g. Integer vs. Floating Point Decimal.
I would not do this, otherwise a getValue() or similar method returning BigDecimal seems better
(at least for SE, the Spec should probably say Number or <N extends Number>, and the final value class can override it with BigDecimal, works perfectly fine and does not force an incompatible type into the abstract interface, if you are in SE, then referencing a variable directly by the "Money" type would be acceptable in many cases, also see java.util.Currency)
Having all the primitive getters and a BigDecimal one degrades primitives to "convenience methods", essentially for a BigDecimal based SE (RI) class these would simply return BigDecimal.longValue(), which you can also do yourself in your app if you need it.
The dozens of redundant methods in 310, e.g. getInMillis(), getInNanos() beside get(TemporalUnit) or similar are a point of critique from Oracle Architects they are likely to remove those from SE 8, so we should not add too many variations or convenience methods here either.
So the options are
If RoundedMonetary like LocalizedMonetary was an extension to base interfaces like Monetary(Amount) we use here as discussion basis, I am not sure, if the "composition over inheritance" paradigm may not be violated by having to many "behavioral extensions" to such base interfaces?
Without too much peeping into 310, one could easily extend Temporal and add isWorkday() or something similar to such sub-interface. Of course, the Temporal implementations like DateTime may not work, but if people started with custom-implementations of "java.time.temporal", this sure would
Similar with Region which ICU4J already adopted following regular updates to the Unicode Standard.
SE 8 does some Unicode adjustments for Unicode 6, but as of now, I doubt, they plan a java.util.Region in addition to java.util.Locale.
IMHO this really would have to go with the i18n team at OpenJDK. Either enhancing Locale beyond what they already tried so far, or proposing a type like Region, Country or whatever. I would try to keep that out of the "Spec" and only use it in implementations where e.g. Java 8 makes it available.
I am not entirely sure, if the static facade will remain. If value classes like Currency (or an equivalent for now) or Money are more relevant, then the facade idea similar to what e.g. BeanValidation JSR has, could become irrelevant. And factories for CurrencyUnit or MonetaryAmount mainly end up in those classes like
Money.valueOf(), Money.of() (for Money we'd be free to adopt naming patterns, 310 first introduces into the JDK, for Currency we must remain compatible to what's already there, thus getInstance() with e.g. alternate arguments like namespace is likely the only way to go, I don't want to see confusion by 3 different patterns in 1 class, and neither does Oracle)
Whether we like it or not, this may replicate at least 2 aspects of Rounding, JDK already has. One older set of numeric constants in BigDecimal, and the new RoundingMode enum, intended to replace those, but for backwards compatibility, we probably still see them in Java 11
Not entirely sure, if a JEP for that might be desirable, but at least Victor initially had that in mind.
Especially the RoundingIds seem somewhat similar to RoundingMode, probably more discussion is helpful here, where this is best placed, java.math (if feasible) or elsewhere.
There should be a good reason, interfaces in public APIs like 310 and others don't simply extend Serializable, nor others like Comparable.
The Temporal JavaDoc probably shows how this could look like for both:
This interface places no restrictions on implementations and makes no guarantees about their thread-safety. All implementations must be
Putting something similar, also with Serializable where we find it to be relevant (and every implementation of 310 Temporal also does implement it) into JavaDoc seems the best way to go, but if even "value object" JSRs like 310 in the JDK don't add it to the common interfaces, there seems to be no need in the Spec.
Precision and exchange rate modelling may in come areas have influence on the Spec and Public API, but on many others there are specific to RI. Either here in the mailing list, or start creating JIRA tasks for areas we agree should be tackled, this should be differentiated.
JIRA (I can help you Anatole with config if needed, there are other JSRs or cases where I need to work with it a lot) has the notion of "component", this is a perfect place where we can tell "Spec/API", "RI/Implementations" or "TCK" apart.
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather
Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* Nordic Java NightHacking: January 31 2013, Copenhagen, Denmark. Werner Keil, JCP Executive Committee Member welcomes Stephen Chin's "Nordic NightHacking Tour" in Copenhagen
* Social Media Week: February 18 2013, Hamburg, Germany. Werner Keil, JCP Executive Committee Member, Agorava Co-Founder will present "Enterprise Social using Open Source Frameworks like Agorava"
[JSR-354] Re: General Questions raised by Chris Pheby
[JSR-354] Re: General Questions raised by Chris Pheby
|Tresch Anatole (KFSC 225)||01/31/2013|