Brewing Hot Java

Qualcomm (www.qualcomm.com) took a stab at Java devotees with its launch of the Binary Runtime Environment for Wireless, or BREW, which was formally announced in January.

“The name was rather interesting,” said Kristopher Tyra, HiddenMind (www.hiddenmind.com) CTO. “Think about the market they were attacking, and they called their product BREW. BREW and Java — the names tell you a lot about the war. Names are real important in the wireless industry. And they're hard to come up with, let me tell you.”

Specifically, BREW is competing as a wireless-application-development platform with Java 2 Micro Edition, or J2ME (www.sun.com).

Rob Chandhok, Qualcomm senior business development manager for BREW, thinks of BREW as an API, not a platform.

“It's a framework with which to develop quality applications,” Chandhok said. “On top of that execution environment, there's the important part of it that manages downloading (applications) securely and robustly, or other pieces of executable code, to the handset so that it won't jeopardize the carrier network, and at the same time so that it will monetize the network. It's not just technical, it's a business model that allows carriers to derive revenue from their networks.”

Platform or API, the reality is J2ME and BREW claim to offer similar capabilities to carriers and others using them for development.

On the issue of making money for carriers, Chandhok is clear about Qualcomm's goals and market projections: “We will make (BREW) a common layer that's designed from a software standpoint to be very thin.” Drawing a comparison with the Palm OS, he said BREW is a more viable mass-market product.

“There will be millions of BREW-enabled handsets very soon,” he said. “That's not economically feasible with Palm. The business model is better.”

Critics have targeted Qualcomm's Achilles tendon — exclusive commitment to CDMA — as a major reason BREW may not achieve mass-market success.

Addressing that point, Chandhok said Qualcomm has plans to make BREW available on non-CDMA chips.

“The Spinco division is even putting together tri-mode offerings that will be CDMA-GSM to support global roaming,” he said.

Chandhok also said “most data traffic around the world is … CDMA. CDMA networks just work well for data. They were built that way.” GSM carriers disagree.

Another crucial aspect of platforms is processing power. Current-generation handsets are weak when thought of as small computers. Newer phones will, however, have far more computational ability than the earliest desktop PCs.

Chandhok said BREW takes a minimalist approach and will cost 50 to 100k, “whereas a J2ME implementation generally is around 500k, in addition to performance issues.”

Although interoperability always is talked about in the wireless world, it has been achieved infrequently. Even with BREW and J2ME, there's talk of meeting in the middle.

“There is value in having J2ME implementations with BREW on the same handset,” Chandhok said. “They can co-exist. There are always trade-offs in any deployment. You can still do the downloading of the Java applications wrapped up in the BREW framework.”

If standardization is the goal, two frameworks or platforms doing the same thing in two different languages is not the best route to take.

“Java is a great tool,” Chandhok said. “The other piece of this is — and it's a distinction in philosophy, and it could come down to a near-religious war — can this be standardized? Can you get that level of expertise (in J2ME) and have every developer out there able to do things, too. My concern is that now, if you look at J2ME, it doesn't give you that ability in the right cost ratio, like BREW does.”

Although Java originated with Sun Microsystems, the Java of today is less tied to that corporation. Rikard Kjellberg, CTO of Ellipsus Systems (www.ellipsus.com), a mobile Internet middleware company, addressed the “religious war” percolating between BREW and J2ME.

“They are both aiming to provide one common development and execution platform for mobile applications,” Kjellberg said.

As the number of device types increases, it becomes imperative to find a common denominator on which applications can be developed and executed, he said. Meanwhile, the carrier would like to offer the same service to as many consumers as possible, regardless of device type.

Both approaches target the “executable” Internet rather than the “browsable” Internet, which WAP did. Applications developed using J2ME or BREW are executed within the legacy infrastructure of an enterprise, as well as on the handset itself, he explained.

“Impact of latencies in the network, limited bandwidth and intermittent connectivity can be minimized, which results in more efficient interaction and improved user experience compared to the browser model,” Kjellberg said.

Because wireless applications must be integrated with existing computer systems and software within the enterprise, Kjellberg said Java — with a longer history in the software developer community — is the better choice.

“Java is a mature technology with an extremely strong foothold within the enterprise market,” he said. “With the introduction of Java 2 platform Enterprise Edition (J2EE), a complete application-server environment has been defined as a standard. Examples include BEA, IBM and iPlanet. It is a natural development that J2EE is also extended to the mobile and wireless environment via J2ME. So, for the enterprise, there are several advantages with J2ME over BREW.”

Key among those advantages, in his opinion, are the following:

• J2ME is a homogeneous application platform based entirely on Java and, thus, will keep support and development costs to a minimum.

• J2ME, unlike Brew, is not dependent on bearer networks. Although BREW is said to have future support for GSM, the current support is restricted to CDMA developed by Qualcomm.

• Although J2ME is supported by several device manufacturers, BREW will be supported only by those manufacturers that use Qualcomm chipsets on their devices. Therefore, it is likely that J2ME will have a quicker path to market and earlier availability for the enterprise as a mobile solution.

HiddenMind's Tyra said there are reasons that run deeper than functionality why BREW may not be adopted by the developer community.

The issue with BREW is that it's not based on anybody's standards, he said, adding that the major players in the wireless space are not using standards. For example, Aether and Broadbeam still are using C++ proprietary applications, no standards. BREW is just another prime example of a non-standard model, Tyra said.

“I haven't seen BREW accepted by developers,” he said. “That's where things get traction — when the platform is accepted.”

The developer looking out for his career will ask himself whether he is going to get a job as a BREW developer or as a Java developer, Tyra said. On the other hand, BREW really is going after the customer base, which doesn't care how the application is written.

“The customer's just looking at ROI,” Tyra said. “And the wireless industry has tried to concentrate on ROI. I don't think they've been successful. It's a combination of developer support and ROI. In some regards, Qualcomm is saying, ‘All you have to do is hook (BREW) up, and you have instant ROI.’”

The battle continues …