Alex's mention of the release of Eclipse driver 3.3M5eh (Canadian for "3.3M5a") reminds me to mention that the 3.3M5 version of Equinox is the current candidate for a Reference Implementation for JSR 291.
Download it here if you want to try out any of the new features mentioned in the PR draft.
Note that Equinox hasn't changed between 3.3M5 and 3.3M5eh.
Thanks to Tom Watson for another interpretation of "eh".
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.
I've noticed a couple of references which have hinted at Geronimo being based on OSGi, so I wanted to clarify the current situation for the benefit of those not closely involved.
While we were extending the Equinox OSGi framework in parallel with the spec. work for the modularity improvements in OSGi R4, my colleague Simon Burns had a crack at modularising Geronimo to make sure there were no obvious gotchas. This was way before WebSphere Application Server had exploited OSGi, so I was keen for Simon to try this out to smooth the path for WAS.
Simon posted a brief summary on the Geronimo dev list, but we didn't follow up as the Geronimo team was undecided about whether they wanted to exploit OSGi or extend the Geronimo GBean technology.
Of course, I would love eventually to add Geronimo to the list of application servers based on OSGi...
For anyone who's interested, I contributed a strawman module system interoperation framework to Apache Felix for discussion there and in the Expert Groups of JSR 277 and JSR 291. I hope we can make these module systems work well together...
See a post to the JSR 291 EG mailing list and docs/README in the JAR attached to the JIRA issue for some technical background.
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.
In spite of the recent debate on SOA and OSGi, the SOA digest just published news that the OSGi Alliance has some new members: BEA Systems, IONA Technologies, Jayway AB, Eclipse, and Interface21 (the Spring guys).
The more the merrier!
Next month's EclipseCon features an OSGi track for the first time.
One of my close colleagues, Tim Ellison, will be talking about Apache Harmony, including its use of OSGi.
Another close colleague, BJ Hargrave, is co-leading a seminar on Spring-OSGi integration.
BEA are presenting their experiences of using OSGi to underpin the microService Architecture, while JBoss are presenting on their thoughts for how they could use OSGi.
All in all, sounds fascinating...
There's a heated debate in Markus Voelter's blog on the relationship of OSGi to Service Oriented Architecture (SOA). I must confess to having thought of OSGi as an example of a SOA until now.
One of the big benefits of SOA is a standardised way of lashing together myriad legacy (and new) systems. You may have seen the 'circuit diagrams' some organisations draw to illustrate the problems they face.
Wikipedia discusses SOA and quotes an OASIS definition:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
Neil Bartlett's excellent article on Eclipse Extensions versus OSGi Services touches on an interesting issue. OSGi services are always potentially dynamic - they can come and go when you least expect it.
Some developers may prefer always to use services to interface between bundles, but that is probably not a winning strategy for larger systems.
An ideal structure for such systems, IMO, is to group bundles into subsystems and have subsystems interact with other subsystems via services. Subsystems are not a formal OSGi concept, but they are an important concept in the mind of the designer.
Within a subsystem, bundles can depend on each other more tightly, e.g. by sharing classes. They could even use require-bundle for really tight coupling, although importing and exporting packages with a suitable attribute is sufficient to prevent subsystems from interfering with each other while maintaining the benefits of a somewhat looser coupling.
The benefit of tighter coupling in a subsystem is that there are fewer failure modes (types of error that can arise) due to bits of a subsystem coming and going when other bits of the subsystem least expect it.
In the example above, bundle a1 will not resolve unless its package import can be resolved. So by the time any code in bundle a1 runs, it can be sure that the dependency on a2 has been met and will not break for the lifetime of a1.
A new site for OSGi enterprise users (not just members of the OSGi Alliance) appeared the other day. More background on EclipseZone.
Neil Bartlett recently published the first of a series of EclipseZone articles on OSGi programming.
Since most OSGi users I've talked to are implementers of the bowels of Eclipse, I'll enjoy seeing how Neil uses OSGi.
If you don't use Eclipse, don't be put off. Implementing and running the bundles in these articles will require only an editor and a command line shell (or two).
The recent announcement of Nuxeo Enterprise Platform v5 on Freshmeat hinted that they had adopted an Eclipse-like extension mechanism based on OSGi. The Nuxeo homepage made me wonder if this was just buzzword compliance. But it seems not.
Eric Barroca's blog describes the use of OSGi in a little more detail. Nuxeo exploits OSGi when it is available and mimics it otherwise. I wonder why they didn't bundle an existing OSGi framework?
It'll be interesting to see whether JBoss decides to bundle an existing framework...
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:
Thanks to some Australian OSGi users for providing a nice link to a Knopflerfish OSGi tutorial.
My example of how to create an OSGi bundle in under 10 minutes still takes some beating for simplicity (or triviality, if you prefer), but I do believe in giving beginners a really easy way in. If they're smart, they'll soon catch on.
Pierro's excellent summary of open source OSGi implementations includes the three long-standing projects, but also mentions Osxa.
Osxa seems to have started recently given its relative incompleteness and also the state of its web site. If you know about the objectives of Osxa, I'd love to hear from you.
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;
}
I'm grateful to Eric Newcomer for an encouraging summary of the recent OSGi Enterprise Expert Group kick-off meeting. I toyed with going and decided my attendance wasn't essential. But it certainly sounded like a lot of fun.
