To Java Bluetooth will go?

I'm beginning to wonder if ZDNet's readers know more about Bluetooth wireless technology than the folks at the Bluetooth Special Interest Group.

After I suggested last week that one way to simplify the Bluetooth mess is to engage the Java Community Process (JCP) in a series of projects that result in some freely distributable Java-based Bluetooth applications, Bluetooth SIG executives reacted as if they thought that was a good idea. But they never mentioned that work on Bluetooth is already taking place at the JCP. In response to a recent column, however, some of ZDNet's readers did.

Setting aside any problems with Bluetooth's underpinnings and the way different implementations could run into technical interoperability obstacles, Bluetooth would be easier to work with--and users would be faster to adopt it-- if there was an extremely consistent user interface from one device to the next.

Why does Bluetooth even need a user interface when other network types such as Ethernet or 802.11 (Wi-Fi) don't? Unlike other network types that let the applications at the edge determine how the underlying transport protocol is used, Bluetooth is hard-wired to specific applications by a series of profiles. For example, there's a profile called Object Exchange (OBEX) that first surfaced with infrared technologies like IrDA. There are profiles for printers, input devices like keyboards and mice, and the sorts of communications that previously took place via an RS-232 serial port. For any of these or other applications to work over Bluetooth, the sending and receiving devices must have corresponding profiles.

Whereas a printer might have nothing more than a printing profile, the PC that connects to it may support printing, connection sharing, file exchange (via OBEX), and mice and keyboards---and each of these profiles requires some degree of end user oversight to get the devices working properly and securely. For example, the user of a PC that supports OBEX has to decide how that profile should be configured. Should the PC be able to receive files? If so, into what directories should those files be transferred and who or what devices should have the authority to do so? What about the retrieval of files? Should other OBEX-enabled devices be able to browse the file system, or only a part of it?

Prior to any of these decisions being made, using a process called "Bluetooth pairing," a relationship must be established between any two Bluetooth-enabled devices that are expected to talk to each other. Pairing has a separate user interface that depends on another interface that's responsible for discovering what Bluetooth radios are close enough to pair with.

Here's the problem: From one Bluetooth-enabled device to the next, the user interfaces that cover these various profile configurations are very different. Vendors of Bluetooth gear see this as an opportunity to differentiate their wares. But lack of a common user interface between implementations can do little more than confuse users. Confused users will do what some of ZDNet's readers have done when they got confused: return the devices. From the vendor point of view, it would make more sense to standardize on the interface. Doing so might minimize returns and stimulate faster growth of the Bluetooth ecosystem, which in turn would greatly increase the value of each vendor's slice of the pie. It's short-sighted to think that they might get a bigger piece of the pie if they come up with a better user interface for something destined to become a commodity anyway.

As I posited in my last column, one way to come up with a standard user interface would be to give the Java Virtual Machine access to the Bluetooth radio in a way that allows Bluetooth SIG to develop a freely distributable set of Java-based Bluetooth utilities. Provided users used these utilities, they would see a consistent user experience from one computer to the next (regardless of operating system), from one phone to the next (again, regardless of the operating system), from one PDA to the next, and so on. The only requirement for each would be the presence of a Java Virtual Machine (a given for many devices already, and freely downloadable for many of those that don't have it).

When I presented this idea to the folks from the Bluetooth SIG, there was no mention that a project of this nature was already well underway. After receiving two letters regarding the existence in the Java Community Process (JCP) of a Java Specification Request (JSR) for Java APIs for Bluetooth (aka JSR 82, I contacted C Bala Kumar, the Specification Lead for the JSR. Kumar also bears the title of Distinguished Member of Technical Staff at Motorola.

According to Kumar, work on JSR 82 is completed and is currently at version 1.0. The specification applies to both J2ME (found in phones and handhelds) as well as J2SE (found in desktops, notebooks, and a few handhelds).

Kumar described JSR 82 this way: "We wanted to provide a layer of abstraction to the radio and the basic Bluetooth stack so that programmers didn't have to bother with the minute details of getting Bluetooth to work. This way, it doesn't matter whether you're developing a profile for printing, a data transfer application that uses OBEX, or if you are developing a game that you wanted to play with other people over Bluetooth. All the facilities are there to do all of the above and more. One reason we developed this is so that the vendors of Bluetooth-enabled devices like printers didn't have to write different client software or drivers for every device that was expected to access those printers.

"There's no reason the Bluetooth SIG couldn't develop one application for managing the printer profile and let all of the printer manufacturers distribute it. The Bluetooth SIG could very easily write the Java applications to the JSR 82 API."

It's an interesting idea. But if such a standard set of applications is going to become available, my guess is that it will have to come from Sun rather than from the Bluetooth SIG, which has to remain neutral and can't appear to favor any one particular platform. Developing and distributing Java-based applications might be perceived as creating a hostile environment for Microsoft, and then things could really get messy. (Mike Foley, chairman of the Bluetooth SIG's Board, is also a wireless architect at Microsoft.) Sun, on the other hand, has no such conflicts of interest and would even benefit from providing a free set of Java-based Bluetooth applications.

"To really demonstrate the power of JSR 82," said Kumar, "we just need more devices that are enabled for both Java and Bluetooth, and I think you'll see some extremely exciting demonstrations at next month's JavaOne event."

Wish I could be there, but I won't. Hopefully, instead of hearing about the demonstrations, I'll get to see JSR 82 in action one day because it, or something like it, will have to be deployed across a lot of devices before we can expect the confusion to end.

Do you have your own prescription for how to eliminate all the confusion over Bluetooth? Share your ideas and thoughts with your fellow readers using TalkBack. Or write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.