March 5, 2021
Hot Topics:

BREW & J2ME: Let's Be Friends!

  • By Radu Braniste
  • Send Email »
  • More Articles »


This series targets mobile developers more accustomed to J2ME than BREW or even BREW developers interested in lighter and more efficient code production. Largely inspired by the Java GUI model, the present BREW_J2ME framework deals with what's known in J2ME as a "high-level interface." It is far from being an exact J2ME match—reasons will be discussed in the article—but exhibits a similar domain abstraction.

We will begin by quickly discussing the gap between BREW and J2ME and how we can narrow the distance, by providing insight into the design process. A thorough presentation of the framework follows.

An Overview

Since the beginning, Qualcomm tried to position BREW as language neutral, with C/C++ as the best choice—other options being always available for application development [1]. From a technical standpoint, the theory is perfectly plausible—a new language can be always implemented as a static extension, wrapping native BREW functionality. As an added bonus, being an extension, it can immediately reap all the benefits of BREW Distribution System (BDS). This is on the bright side. But what's left in the shadows?

Such an implementation will be inherently slower (all the OS calls are mediated by BREW) and bulkier than the same implementation directly on top of the OS. Now, speaking of J2ME: BREW offers much more functionality than standard MIDP (even 2.0)—meaning that probably a non-standard API will be offered to fill the gap.

But, of course, choosing one language over another is mostly a business decision and there is no point in comparing their merits. What's more attractive is to offer Java developers a more familiar way of writing BREW applications using C++. Obviously, this endeavor implies knowing the limits and differences between J2ME and BREW from the point of view of development.

Some differences stem from the Java vs. C++ architectural debate—for example, memory manipulation, multiple inheritance, type safeness, generics, and so forth. There is another category derived mostly from BREW limitations—prominent examples are lack of support for static variables, level of support for C++, cooperative multitasking, developer not insulated from watchdog activity, and the like. Of course, Java on top of BREW means that somehow Java has to absorb all these differences. A third group of dissimilarities is due to a basic design decision such as event model, components, and so forth. And of course, as mentioned before, J2ME is a platform-independent set of specifications with no counterpart for some BREW functionality.

Page 1 of 4

This article was originally published on December 4, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date