Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Press and Success
Success Stories

BluetoothTM Developers and Implementers Can Succeed with JavaTM Specification Request (JSR) 82
JSR 82

JSR 82 Timeline

From start to finish, JSR 82 took nearly one and a half years. The Executive Committee approved its proposal October 2000. The original 14-member expert group took shape the next month, and seven additional members were added in July 2001 after the spec lead's talk at the JavaOneSM Conference. The community reviewed the spec in November, with public review following in December, and the final draft was proposed in January. On March 4, 2002, the final specification was approved by the Executive Committee.

By 2004, consumers won't need to carry quarters to purchase a coke from a vending machine. They won't need to hail the waitress for a check. They won't need plastic to pay for groceries. The common means of payment for purchases large and small will change for those who own a JavaTM technology-enabled BluetoothTM handheld device such as a mobile phone, pager, or PDA. So predicts C Bala Kumar, Distinguished Member of Technical Staff for Motorola's Wireless Software, Application and Services group, and the specification lead for JSR 82 in the Java Community ProcessSM (JCP) Program.

Behind such a prediction lies the 10th century story of a certain King Harald Bluetooth, a Viking who united Denmark and Norway and professed the new Christian religion. Taking a page from history, the Bluetooth standard introduced in 1998 unites the two industrial kingdoms of telecommunications and computing, replacing infrared connectivity with the Bluetooth short-range (10-100 m) radio link.

But Bluetooth has a cavity, a painful hole visible to implementers, developers, and consumers. To enable constant universal connectivity, a Bluetooth stack, radio, and applications must be installed on myriad devices, each of which represents proprietary hardware and a specific operating system. Implementers such as Motorola, Nokia, and Ericsson understand that the Bluetooth-enabled phones they offer won't entice hoards of consumers if few applications are available for them. However, a Bluetooth programmer can't be bothered to create even a simple multi-user tic-tac-toe game if it's necessary to rewrite the application for each unique device.

JSR 82: Java APIs for Bluetooth lays a clean foundation for Bluetooth hardware implementers, makes development easy for application writers, and ultimately fuels the interest in devices that consumers simply must have.

Guiding Principles in a Nutshell

Recruit diverse experts.
Have no sacred cows.
Disagree but commit.

In driving JSR 82 through the JCP Program, spec lead Kumar adhered to three principles. First, he actively recruited diverse experts related not just to Java technology but to Bluetooth hardware and software. The original 14 members included Brad Threatt, Ericsson, Extended Systems, IBM, Mitsubishi Electric Corp., Motorola, Nokia Corp., Parthus Technologies PLC, Research In Motion LTD, Rococo Software, Sun Microsystems, Symbian LTD, Vaultus, and Zucotto Wireless. Midway through the project, seven more organizations clamored to be admitted into the expert group. While most expert groups typically refuse to admit this many new experts so far along in the project, Kumar and his fellow experts felt strongly that on a project of this scope it was imperative to solicit the widest possible range of input. So membership swelled to 21.

With these additional voices came suggestions for revisions to the work already accomplished. Again, many groups might refuse such retrofitting, but Kumar and his colleagues agreed with a second principle, to have no sacred cows; they were willing to make radical revisions whenever the need for them became apparent. Even after public review, Kumar made major changes to JSR 82 in order to address new ideas. The experts had to review each change, but they were willing to do so when the effort yielded a more robust and elegant specification. Even those outside the expert group praised the late changes, emailing kudos to Kumar: "The API is looking very good -- easily the best Bluetooth API I've seen in any language." and ". . .the JSR-82 is well structured and good to understand."

Kumar began each meeting with a restatement of his third principle that members be permitted to disagree but commit. On numerous occasions an expert would state an opinion clearly not shared by the group, then voluntarily add, "I think this is the time when I'll have to disagree but commit." And the conversation would continue productively building toward consensus.

The specification targeted Java 2 Micro EditionTM (J2METM) high-volume mobile devices for several reasons. First of all, building on the Java language permits Bluetooth application developers to write once and run over any J2ME enabled Bluetooth radio-equipped handhelds. Moreover, it's important to address the area of greatest demand first, and low-end J2ME devices will probably be the first Bluetooth devices to sell in high volume to consumers. It's also efficient to pave the way for future products. J2ME devices represent a technical challenge, with their small footprint and limited memory, so whatever works under these constraints can be adapted later fairly easily to work with Java 2 Standard EditionTM (J2SETM) computing devices such as laptops.

To aid in the implementation (and ultimate J2SE adaptation) of the spec, JSR 82 fit the Generic Connection Framework (GCF), which is part of the Connected Limited Device Configuration (CLDC). Organizations that build J2ME phones are already familiar with this framework, and the Java APIs for Bluetooth are just an extension of that. If a group employs the same Bluetooth stack used in the Reference Implementation (RI) created by Motorola, they can simply license it, run the Technology Compatibility Kit (TCK), and achieve compliance. However, there are many Bluetooth stacks available, so those who employ alternative solutions can use the RI as an example, then build their own.

The team was concerned more about making the process easier for developers than for implementers. They knew the implementers wouldn't mind adding complex Bluetooth capability into the phone as long as developers were able to create the games and applications that would become the phone's selling point. Kumar says, "In writing the API, some individual members would stray from our goal of simplicity, but during cross-checking others would challenge them about being too complicated. To keep focused, we would think of a guy writing a simple tic-tac-toe program to be played over Bluetooth between two phones."

"It's tricky to fit Bluetooth, an immature technology that is still growing and changing, into the more mature, well-defined Java technology. The need for this API has not changed at all since we started. In fact, there is even more demand," says Kumar. In fact, over thirty percent of the handsets sold in 2003 are likely to be Java technology-enabled, and many are expected to have Bluetooth capability. As soon as the spec was made available for public review, at least two companies outside of the expert group began building product based on it. Later in 2002, three expert group members are expected to launch their implementations.

For more information on JSR 82 see: http://jcp.org/en/jsr/detail?id=82