JSR 82 brainstoming with Sean O'Sullivan
This is my first entry in 2008 and I wish an amazing year for everybody!
Sean O'Sullivan, the CTO of Rococo Software, is going to present a session called "Past, Present and Future of JSR 82 (Java Bluetooth APIs)" in Mobile & Embedded Developer Days. Don't miss that, registration is still open! If you, unfortunately, won't be able to travel to California and be in the event, check the live broadcast as well.
He lovely gave us an email interview/preview... here we go:
As the CTO of Rococo, Sean drives the company's technical strategy and vision. Background is in middleware and distributed systems. From a technical perspective, his interests are distributed systems, embedded software, and the space where the web meets the plain old telephony system.
Rococo was founded in 2000, and began exploring potential product applications in the (then new) Mobile Java arena. Focused on Java and Bluetooth at the end of 2000, and then applied for and was accepted as members of the JSR82 Expert Group. We then helped work on defining JSR82 in the standards group, following the JCP process, while in parallel, we worked on creating a set of tools that supported the standard, as well as our own OEM, licence-able version of the standard.
Our short set of milestones since then:
Mar 02: Launched our Bluetooth Simulator on the same day the JSR82 standard was completed at Java World
Jun 02: Released our Linux DevKit
Q4 02: Launched our Technology Licensing Kit (TLK) - OEM source-code product for companies wishing to add JSR82 support to their devices.
Q1 2003: First commercial deal for our TLK with Ericsson Technology Licensing (a big deal for us - ETL was then the leading Bluetooth Stack Provider in the world!)
Q3 2003: Licensed TLK to Aplix to include JSR82 in their Java Virtual Machine - another big deal for us, due to their penetration in the mobile handset industry
Q3 2005: Licensed to Esmertec to include JSR82 in their Java Virtual Machine - another key milestone, demonstrating growing acceptance for JSR82 in the Java Virtual Machine business, and JSR becoming a requirement in mid-range handsets
2006-2007: Large scale deployments of Rococo's JSR82 technology via our licensing deals, sees our software ship on Motorola, Sony Ericsson and other handsets. Shipments grow to over 100 million units.
2008: Rococo now investing more in JSR82 technology, porting to new platforms, and proposing potential follow-on standards to JSR82
Why Bluetooth? Why Java?
When we analysed the technology back in 2000, we very much liked it's potential ubiquity. By virtue of its design goals, and the vision of the SIG, Bluetooth was always intended to be a short-range wireless standard that could be in many, many devices "close to us" : phones, sensors, set top boxes, home gateways, cars, watches etc. We thought this was very exciting, and had the potential to unleash a significant wave of innovation for applications and services that work "around you" - in the home, in the car, amongst "your stuff". I think we're only really seeing that come to pass now in 2008. And if you look at the new stuff in Bluetooth (low power and high bandwidth in UWB), I think we'll see some fantastic applications arrive in the shops over the next 12-18 months.
With Java - we bought its potential as an application delivery and execution platform that could go "anywhere". We studied it, and - even accepting the potential limits of the "write once run everywhere" vision, we believed it would be one of the only standards-based platform technologies to really penetrate devices, machines, consumer electronics.
We thought the combination of both technologies was potentially a great fit. And so the focus on JSR82 was natural for us, and has been a niche in terms of focus, but a good niche! :-)
What do you think about possible improvements into the current JSR 82?
There are many areas in which JSR82 could be improved. To be fair to it - it was originally designed to provide some basic, core APIs for Bluetooth in Java, and to quite an extent, it slavishly followed the existing Bluetooth Stack functionality, and stayed away from trying to ad ease-of-use, or higher level abstractions for developers etc. In a way - this was a good thing - it didn't try to do too much - it just focused on getting an initial, functional and useful set of APIs delivered and adopted in the market. That's now happened, and it's time to take a look at what else could be added or provided as enhancements to the core standard. I think there are potentially three main areas for consideration:
1) Admin/housekeeping/helper classes
2) APIs for common application areas
3) New APIs to expose some of the new functionality coming available with the new capabilities in Bluetooth (UWB, ULP, NFC etc)
In the first case, for example, as you have done with the Marge project, you have provided some really useful ease-of-use abstractions for common things that most developers need to do when using JSR82. These are exactly the kinds of higher level services that might be appropriate in a new version of the standard, or in a follow-on standard that builds on JSR82.
In the second case, I think there's scope for some common APIs to cover, for example, gaming (scoreboard management, player join and leave, in-game communication,) medical (APIs for sensing, storing, sharing specific health care data acquired by a local device), automotive (OSGi integration plus other common automotive specific APIs) and metering. These are just some of our thoughts - I'm sure other people can suggest some other compelling application-specific APIs, which could be defined and significantly lower the bar for new application development in these areas.
Finally, it's definitely time to take a good look at what the Ultra Low Power (ULP ) and Ultra WideBand (UWB) developments in Bluetooth could mean for application developers. With these capabilities, we're seeing Bluetooth move into Set Top Boxes, Machine-2-Machine (M2M) and sensor-based areas, among others. It's like that we could define new APIs that enable developers to take maximum advantage of the new capabilities becoming available in Bluetooth, and now is the time to start planning and defining those APIs.
How do you see the future of Java/Bluetooth integration and JSR 82?
Right now - we're pleased with the extent of the deployment of JSR82, primarily in phones. Rococo also has seen its implementation used in well over 100 million phones to date.
We're now beginning to see it also being used in these new areas: M2M communication, Set Top Boxes and Home Gateways, and in medical applications and in the car. I think the potential for the standard, and any follow-on, is very strong, as the number of devices that will have both Bluetooth and Java on-board is only going one way : up! :-) Any time both technologies are present of the same device, there's a pretty strong case for including JSR82. If you look at the general market dynamics for Java (especially mobile Java) and for Bluetooth, I think it's clear we're only at the early stages of the potential deployment and usage of the Java/Bluetooth standard.
You are going to present a very interesting session in Developer Days, how will be that? What your audience can expect?
Yes - I'm still writing my slides at the minute - so ask me later! :-)
Seriously: we were delighted to be accepted to give a talk at the conference - it's a brilliant line up of talks over the few days. We're going to just cover some background to JSR82, to explain a little bit of history to the standard, and then talk about where JSR82 might go down the line. I'll probably cover some thoughts on what's good and what needs improvement in the standard, and maybe mention Android if there's time. As I say - ask me later :-)
Anything else you may want to say?
Thanks for the opportunity to say a few words. Your blog is always excellent - and we're fans of the work you guys have been doing with Marge!
Wow!!! Great content! Don't forget to keep an eye in Rococo's Weblog too.