ince its inception, "write once, run anywhere!" has been the mantra and rallying cry for many architects and software engineers trying to convince their enterprises to move to or stay with Java. The phrase was particularly useful when talking about building software applications for mobile and wireless devices.
If you are involved in J2ME development, the write once, run anywhere or "WORA" battle cry may have lacked some luster in recent years. Sure it sounds good and logically makes sense. Java was extremely successful in assisting developers write software applications that run on a number of operating systems (Windows, Unix, Linux, Mac OS, etc.). It would seem to follow that Java is also suited to help support application development on the multitudes of cell phones, personal digital assistants (PDAs), and other consumer electronic and embedded devices. Unfortunately, it turns out the diversity of devices is too much for J2ME and perhaps any software platform to handle. If you have tried to write an application that runs on a couple of types of cell phones (let alone trying to cover the millions of J2ME-enabled phones or other electronic devices) you are probably dealing with this problem. It has a name and it is called device fragmentation.
Defining Device Fragmentation
Device fragmentation is the problem of having to write separate or custom software for devices on which you want your application to execute. In other words, it is writing and managing a separate code base for the same basic functionality just to meet individual device capabilities/features. The worst-case scenario is being forced to write a separate code base for each and every device you what to supportcertainly a WORA kill-joy. Device fragmentation turns the idea of creating and mass distributing that "killer app" you have in your head and want to develop into an almost insurmountable problem.
What does the problem stem from? There are many reasons why devices do not avail themselves to WORA. Some of the problems relate to device capabilities such as screen size, available memory, storage space for your code, and processor speeds. Other problems relate to the diversity and capabilities of the underlying operating system of the devices. Finally, the choice of J2ME profile/configuration (example: MIDP 1.0 vs. MIDP 1.1) and JVM, adherence to the standards for that JVM, and availability and implementation of the various J2ME APIs (like the Mobile Media API or J2ME Web Services) makes for many other obstacles that must be overcome to provide true application portability.
In order to give those that have not had to address device fragmentation a taste of these issues, simply go to Sun's listing of J2ME supported devices. First, take a look at the various screen sizes supported by the devices. You will see everything from 95x65 to 640x200 pixel resolution and one to eighteen bits of color depth. Imagine trying to write a J2ME game application given that type of variety in user interfaces? Next, take a look at the "Software" column listing the J2ME profile, configuration, and J2ME optional APIs that each device supports. Remember that a simple change from CLDC 1.0 to CLDC 1.1 in J2ME means the difference between having something as simple float point numbers or not. By the way, a vendor's interpretation of J2ME standards like MIDP means that running an application on devices that each support MIDP to the 1.1 level, for example, does not guarantee consistent behavior. Finally, take note of the number of manufactures and models of devicesover 170 different devices in this list and many with their own OS and unique device capabilities. Nokia (the world's number one manufacturer of mobile phones) alone has two major operating systems (Nokia and Symbian) on the J2ME phones listed. Can you imagine your test plan to check all the features of your application against a major chunk of these devices? Ouch!
Some Defragmentation Help
Not a pretty situation, but you have to at least acknowledge that Java and J2ME have offered hope to hopelessness. The JVM on millions of phones provides the basis for running a large portionprobably 80 percent in most situationsof an application without issue. And before you are ready to abandon J2ME and decry WORA dead, know that there are some tools that help. Specifically, using the NetBeans IDE in conjunction with the NetBeans Mobility Pack can help you address some of these device fragmentation issues.