 |
|
Download: Solaris 8 Migration Assistant
Rapidly move your Solaris 8 application environments to new systems running Solaris 10 with the Solaris 8 Migration Assistant. Reduce migration risk while taking advantage of increased performance, reliability and security of the latest SPARC hardware platforms and Solaris 10 OS. Click here
»
|
 |

 |
|
|
Generate Revenue Through IT Using Business Service Management
Sponsored by HP
Making sure that your business applications are available to their end users is an important part of running your business smoothly. Business operations have evolved to where IT must now broaden its focus to help the company attract, retain and grow customer relationships and increase customer satisfaction. Business service management (BSM) helps lay the foundation by managing services in dynamic support of business requirements. »
|
|
Managing the Modern Network
Sponsored by HP
Networks are more than vehicles to transport e-mail and Web pages. In a global economy where information crosses the globe in an instant, and where Web-based applications power business, it's more important than ever to ensure your network is safe from threats and optimized to deliver the data your business needs. »
|
|
Storage Networking 2, Configuration and Planning
Sponsored by HP
In Part 1, we discussed storage area networks (SANs) and fibre channel. In Part 2, delve into best practices and cover the general concepts you must know before configuring SAN-attached storage. The most critical, sometimes tedious, part of setting up a SAN is configuring each individual disk array. This guide examines configurations for SAN-attached servers and disk arrays, and also includes a look at the future of IP storage.
»
|
|
Is Your Disaster Recovery Plan Good Enough? Get Disaster Recovery Right
Sponsored by HP
Preparing for a disaster is more often than not part of the storage planning process, and without question it is one of the most difficult task, since it includes local hardware and software, networking equipment, and a test plan to ensure that you can recover from the disaster. Learn how to put your organization on the proper disaster recovery plan, now. »
|
 |
|
  |
|
|
|
|

BREW & J2ME: Let's Be Friends!
By Radu Braniste
Go to page: 1 2 3 4 Next
Abstract
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.
Go to page: 1 2 3 4 Next
Previous article: For Brew Developers, There Are New Kids in Town: IThread & IRscPool, Part 2
|