I wonder if the JCP rules allow JDK 7 to be called "Java"? Sun appears to think so since the JDK 7 page is entitled "jdk7: Java SE 7". Apache Harmony meanwhile will presumably avoid calling itself "Java" until it can obtain and pass the JCK. Does this make Harmony the true guardian of Java? ;-)
On this topic, Danny Coward recently referred to a limited form of operator overloading specifically for BigDecimal. Good to know this is still in Sun's thinking.
I'm continuing to look for users and companies who are willing to back the requirement for decimal syntax in Java, regardless of whether this is via limited operator overloading or decimal-specific support, so if anyone is interested, I'm all ears.
As mentioned previously, I'm keen for Java to provide nice syntax for BigDecimal types. Someone asked me whether I was trying to sneak full operator overloading into Java through the back door. It's a reasonable concern.
Much as I like some other features of C++, I was very comfortable that Java omitted general operator overloading. So I am definitely not suggesting that BigDecimal syntax be introduced along with general operator overloading.
Of course, if these syntax improvements go ahead, Sun are free to add them via a limited form of operator overloading mechanism, but that's an implementation choice from my perspective and certainly not part of the requirement.
Today's JSIG meeting on OSGi and JSR 291 in London was well worth the commute.
I met beforehand for coffee with three guys from Paremus: Richard Nicholson (CEO), Mike Francis (Sales and Marketing Director), and Robert Dunne. They described their 'Infiniflow' product built, you guessed it, on top of OSGi. It runs on Knopflerfish and Equinox, although they hope to support Felix in due course. They ship the product's base layer, Newton, as open source. Newton provides basic services and is responsible for propagating SCA components, known as composites, around a network according to defined declarative specification documents.
I wondered if they might have to overcome IBM's perennial problem of creating software "by PhD's for PhD's", but they assured me there were simple use cases which made it easy for application programmers to get started.
The JSIG meeting was well attended with Alex Blewitt, the EclipseZone editor (on the left below), presenting and Neil Bartlett (on the right), running live demo's to illustrate the theory.
Alex explained the problem that OSGi solves and gave details of the key framework features. (I'll forgive Alex for the stunning slide transitions courtesy of Neil's Mac. Is he on commission?)
Neil's demo's were coded and built using NetBeans and included a Swing application to emphasise the point that OSGi is far from just 'an Eclipse thing'. He used Knopflerfish to run the demo's as it has an excellent GUI for installing bundles and starting and stopping them, etc.
They promised to dump the presentation and code on the JSIG website.
The audience, of around 30-40, seemed fairly lively and there were lots of questions, some of which were quite searching. It was good to bump into a former colleague of mine from Hursley. Sunny Chan worked on the initial version of the shared classes support we put into IBM's Java 5. He now seems to be enjoying working for an investment bank maintaining Java environments.
Afterwards I had lunch with Neil and Benoît Xhenseval of ObjectLab. The conversation centred on OSGi, although the need for decent decimal syntax in Java financial software came up again without my prompting. Must follow that up.
There was some mention of the various modularity JSRs throughout the day. It's amazing to see how different things look to complete outsiders (to the JCP). There seems to be a general bewilderment over JSR 277. Also, since some of these guys have only recently stopped supporting Java 1.3, Java 7 seems eons away from being the default platform for deployment.
The lasting impression of the day was how incredibly useful OSGi is for underpinning various kinds of commercial software. It seems that the OSGi Alliance has created the start of a potentially enormous value network which provides business opportunities for framework and middleware vendors, such as Paremus and ObjectLab, as well as to 'real' customers.
There's increasing interest in what might go into Java 7. The spec. lead has given some hints in his blog and a recent presentation.
However, Alex Miller's Java 7 page seems to be the definitive collection of candidate items.
I'm particularly interested in:
One of the candidate items for Java 7 helpfully listed by Alex Miller is BigDecimal operator support. I'm keen to see this go in as it would really help customers who use decimals.
Mike Cowlishaw's General Decimal Arithmetic page is a rich source of information on this subject. It contains an example 'telco' benchmark coded in Java and C# which provide a helpful comparison when thinking about syntax support for BigDecimal.
Take the following sequence (massaged a little for display here) from the Java version:
b = p.multiply(basetax);
b = b.setScale(2, BigDecimal.ROUND_DOWN);
sumB = sumB.add(b);
t = p.add(b);
if (calltype != 0) {
d = p.multiply(disttax);
d = d.setScale(2, BigDecimal.ROUND_DOWN);
sumD = sumD.add(d);
t = t.add(d);
}
b = p * basetax * 100;
b = Decimal.Truncate(b) / 100;
sumB = sumB + b;
t = p + b;
if (calltype != 0) {
d = p * disttax * 100;
d = Decimal.Truncate(d) / 100;
sumD = sumD + d;
t = t + d;
}
