Posted: February 03, 2012 20:02 by vgrazi
February 3, 12 Meeting Minutes JSR-354
Scot Baldry – Goldman Sachs
Matthias Bucker - Credit Suisse
Raj Mahendra – JUG Chennai
Tony Jewel – Credit Suisse
This is our first meeting as a group since we filed the JSR.
Victor Not sure why we are getting so many bounce messages – will talk to java.net admins.
We reviewed the requirements on the Wiki - http://java.net/projects/javamoney/pages/Home
Stephen – For Electronic Trading and Low Latency apps people probably won’t be using Java.
Victor – At Credit Suisse, we do use Java for LL.
Scot – Also at Goldman.
Scot – We shouldn’t target Low Latency but let’s try to accommodate. Low Latency would be a niche market for us, the wording on the wiki is good
“There is a question whether to include Low Latency such as Algorithmic Trading applications. We will not specifically target these but will try to keep performance in mind to accommodate such applications.”
Stephen - Those concerned with low latency would probably use primitive, mutable classes anyway, so build for 80-90% use case
Raj – Numbers such as 99,99,99,123.00 are used in India to represent numbers in general, not just currency.
Stephen - Java today doesn’t do it today, so how does India work with it?
Raj - They just use the existing standard
Also, Crores and Lakhs, ( sometimes uses C & L), in India, currently just use Millions etc.
Stephen - The Math is not that complicated, we can implement it outside the JDK
Werner – JSR 310 has this in common, using existing formatter, but encouraged to migrate to new when it exists.
Our Formatter will be immutable
JSR-310 Instance and duration classes are the same because seconds and milles
Needed if you need to go to say 9 decimal places
BigDecimal provides infinite precision, but slow)
Stephen - Single long, 9 decimals is probably not unusual, so the biggest you could accommodate is 2Billion
Scot – operations on operations, requires fine precision
Stephano – Calculating some risk based on value, can’t predict in advance what the precision would be
Stephen – against a factory because I want to know what ValueType I am using
(A ValueType is any object that is small and well defined, formed only of other vt’s and primitives, sb immutable, toString should fully repr state, cacheable, to and from string)
Scot – also reluctant to factory, should feel very natural, if use factory will feel like an add-on.
Joda uses BigDecimal internally but should be swapped out
Money should be long or 2 longs.
Having 2 representations may be confusing
Decimal class should wrap the 2 longs
(Other choice is to encapsulate them in the money class)
Decimal class is good because it can be swapped out
Object creation time could outweigh calculation time – Ask Kirk Pepperdine
We want a 128 bit primitives, literal for decimals built into Java
Agree we need 2 longs, and come up with the scalar and decimal arithmetic
Raj – can provide Indian requirements
Stephen – other open source projects have found that it is better to be talking: start with a ref impl that is on-going, and have people comment on it.
Tony – Start carving API and provide Javadoc, then implementation will come later
Create stub classes as opposed to interfaces, for the purpose of generating the Javadoc.
Stephen - Start with Joda and delete all the implementation.
Scot – to clarify, are we going to check out Joda, strip out the implementation, and check that in as our starting point.
GitHub is important, as opposed to Git on java.net. That’s where the community and the tools are.
Werner – do they have mirrors for Java.net?
Stepehen – most of our projects are on source forge, but keeps the vc in git hub
Victor – start a git hub project
Can we permission this correctly? Yes
Werner - Grails currency has already done a lot of what we need to accomplish, search on github (developer from Costa Rica, recalling name)
All agreed on Friday 9AM EDT for monthly meetings
If the Credit Suisse MeetingPlace is created from Switzerland it will include a dial in for Germany