Skip to main content

Compatibility and the Java™ Platform

1. Introduction

Java™ Platform, Micro Edition (Java ME) is the most ubiquitous application platform for mobile devices across the planet. It provides a robust, flexible environment for applications running on a broad range of embedded devices, such as mobile phones, PDAs, TV set-top boxes, and printers. The Java ME platform includes flexible user interfaces, a robust security model, a broad range of network protocols, and extensive support for networked and offline applications that can be downloaded dynamically.

The Java ME platform is deployed on millions of devices, supported by leading tool vendors, and used by companies worldwide. As of June 2006, there were more than 1.2 billion Java Powered brand mobile phones (source: Ovum) supported by over 180 network operators and carriers around the world, with tens of thousands of existing applications and a thriving developer community built around the Java Community Process(JCP) program.

Figure 1: Java Platform Success Stories
Figure 1: Java Platform Success Stories

All this success has not come without some challenges. A commonly discussed topic in the industry and developer community is fragmentation. By fragmentation, people usually refer – in a generic fashion – to any situation in which the Write Once, Run Anywhere™ value proposition fails to provide an uniform execution platform on all the devices and systems. The most common examples of fragmentation are when an application refuses to run on all the intended target devices, or when the same application exhibits different behavior on different devices.

Application developers, content providers and distributors, network operators and device manufacturers are all affected by fragmentation. When a Java application is written, it should ideally run on all the intended target devices without any additional porting or testing. However, in practice the application often has to be ported and manually customized to run on different devices and platforms, and then tested explicitly on different device and platform combinations. Given the large number of possible target devices, this is very costly and adds complexity to the entire Java ME platform ecosystem. As a result of fragmentation, Java application developers cannot create and deploy mobile applications as easily and cost effectively as they ideally would.

Fragmentation is a complex topic that cannot be summarized briefly without taking a deeper look at the various factors that contribute to its occurrence. For instance, in many ways fragmentation is a natural consequence of a rich, thriving, evolving ecosystem in which the platform vendors, device manufacturers and network operators are allowed to innovate and differentiate their products. This is in contrast to some other software platforms that require every vendor to use precisely the same platform without any or little differentiation. In this white paper, we take a deeper look at fragmentation and intend to dispel the myths surrounding this topic. We start by looking at the evolution of the Java ME platform and by providing some common definitions for fragmentation. We then summarize the solutions that Sun and others offer to address fragmentation.

2. Some History: Evolution of the Java ME Platform in the Wireless Market

The evolution of the Java Platform, Micro Edition for wireless began in early 1998 at Sun Labs in the form of a small two-person research project. After the official introduction of the Java ME platform (earlier known as the Java 2 Platform, Micro Edition (J2ME)) in 1999, interest in the platform grew very rapidly. Nowadays, dozens of device manufacturers across the world are shipping Java Powered brand devices, at the combined rate of several million devices per day.

From the commercial viewpoint, three distinct stages can be identified in the evolution of the Java ME platform in the wireless marketplace (illustrated in Figure 2):

Phase 1 – 2000-2003: CLDC 1.0 & MIDP 1.0 devices

  • The first versions of the Connected Limited Device Configuration 1.0 and Mobile Information Device Profile 1.0
  • Very limited memory and processing power available
  • Very rapid adoption of the Java ME platform: From zero to 100 million devices shipped in a few years

Phase 2 – 2003-2006: MIDP 2.0 & Java Technology for the Wireless Industry devices

  • New version of the Mobile Information Device Profile standard (MIDP 2.0)
  • New version of the underlying Connected Limited Device Configuration standard (1.1) with floating point number support; however, CLDC 1.0 still continued to be used widely
  • The Java Technology for the Wireless Industry (JSR 185) specification groups together other key APIs to create the first “umbrella” standard with rich multimedia and communication capabilities
  • Improved device capabilities and interoperability
  • Very rapidly growing device base: From 100-200 million to over 1 billion devices shipped
  • Rapidly growing number of Java ME technology specifications above and beyond Java Technology for the Wireless Industry

Phase 3 – 2006 onwards: MSA devices

  • New Mobile Service Architecture (MSA, JSR 248) umbrella standard groups together 16 key Java ME technology specifications to form the new Java ME platform base.
  • A new wide interoperable base; however, at the same time the rapidly growing number of new APIs creates additional fragmentation challenges
  • Increased adoption of the more capable CDC configuration also in the wireless industry; new Mobile Service Architecture Advanced (MSA Advanced, JSR 249

Figure 2: Evolution of the Java ME platform in the wireless market
Figure 2: Evolution of the Java ME platform in the wireless market

3. Types of Fragmentation

In analyzing fragmentation, it is possible to identify several different types of fragmentation, depending on the primary source of the interoperability problems. The three most common types of fragmentation are:

  1. Platform fragmentation
  2. Implementation fragmentation
  3. Device-level fragmentation

Platform fragmentation. Platform fragmentation is a generic term that refers to devices supporting a different set of Java technology APIs. This type of fragmentation is commonly also referred to as API fragmentation or API-level fragmentation.

There are multiple reasons for platform fragmentation. One reason is the history and evolution of the Java ME platform, as described in the previous section. The existence of devices from different evolutionary phases of the Java ME platform means that application developers and content providers will inevitably have to take into account the presence of devices with different APIs. Other common reasons for platform fragmentation include the presence of:

  • manufacturer-specific APIs and extensions,
  • optional or 'conditionally mandatory' components such as Bluetooth or location services,
  • different versions of the same API on different devices, and
  • new Java ME platform specifications that not yet part of any “umbrella” standard yet.

One important reason for platform fragmentation is the broad range of supported target devices. The Java ME platform supports a much wider range of target devices than most other software platforms, ranging from wireless phones and PDAs to TV set-top boxes and printers. Given the different needs in different market segments, all these devices cannot be supported with a single set of APIs. The Java Community Process (JCP) program standardization process provides a mechanism for Java technology to grow and adapt to different market needs. To accomplish this, Java ME platform allows product designers to specify and choose from a set of configurations, profiles, and optional packages to create a Java runtime environment for a specific vertical market segment.

To a large degree, platform fragmentation is caused by the major success of the JCP program in creating new Java specifications for different needs. There are currently approximately 40 Java ME platform specifications that have been completed through industry collaboration using the JCP program. In addition, about 20 Java ME technology specifications are currently in progress in the JCP program.

More fundamentally, platform fragmentation is caused by a tradeoff between fragmentation and innovation (or differentiation). Unlike with some other software platforms, which do not allow vendors to innovate and differentiate their product offerings, in the Java ME technology marketplace vendors can choose to add their own licensee-specific classes and include additional APIs created thru JCP program in the devices that they ship, above and beyond those APIs that belong to base standards such as Java Technology for the Wireless Industry or MSA. Platform fragmentation is often also caused by time-to-market issues, since the vendors cannot always afford to wait for official standards to be created and released thru Java Community Process program.

As already mentioned earlier, in many ways fragmentation is a natural consequence of a rich, thriving, evolving ecosystem in which the platform vendors, device manufacturers and network operators can innovate and differentiate their products. It can even be claimed that without such innovation, the Java ME platform would not have been as incredibly successful as it is today. Many standards that are part of the core Java ME platform today were initially created as “value-add” extensions or licensee open classes. If such an innovation had been prohibited, it is quite possible that the evolution of the Java ME platform would have been much slower, or that many useful APIs would not have been developed at all.

One important reason for platform fragmentation is the broad range of supported target devices. The Java ME platform supports a much wider range of target devices than most other software platforms, ranging from wireless phones and PDAs to TV set-top boxes and printers. Given the different needs in different market segments, all these devices cannot be supported with a single set of APIs. The Java Community Process (JCP) program standardization process provides a mechanism for Java technology to grow and adapt to different market needs. To accomplish this, the Java ME platform allows product designers to specify and choose from a set of configurations, profiles, and optional packages to create a Java runtime environment for a specific vertical market segment.

To a large degree, platform fragmentation is caused by the major success of the JCP program in creating new Java specifications for different needs. There are currently approximately 40 Java ME platform specifications that have been completed through industry collaboration using the JCP program. In addition, about 20 Java ME platform specifications are currently in progress in the JCP program.

More fundamentally, platform fragmentation is caused by a tradeoff between fragmentation and innovation (or differentiation). Unlike with some other software platforms, which do not allow vendors to innovate and differentiate their product offerings, in the Java ME technology marketplace vendors can choose to add their own licensee-specific classes and include additional APIs created thru JCP program in the devices that they ship, above and beyond those APIs that belong to base standards such as Java Technology for the Wireless Industry or MSA. Platform fragmentation is often also caused by time-to-market issues, since the vendors cannot always afford to wait for official standards to be created and released thru Java Community Process program.

As already mentioned earlier, in many ways fragmentation is a natural consequence of a rich, thriving, evolving ecosystem in which the platform vendors, device manufacturers and network operators can innovate and differentiate their products. It can even be claimed that without such innovation, the Java ME platform would not have been as incredibly successful as it is today. Many standards that are part of the core Java ME platform today were initially created as “value-add” extensions or licensee open classes. If such an innovation had been prohibited, it is quite possible that the evolution of the Java ME platform would have been much slower, or that many useful APIs would not have been developed at all.

Figure 3: Adoption of new features into the core Java ME platform
Figure 3: Adoption of new features into the core Java ME platform

Figure 3 illustrates the overall process in adopting new features into the core Java ME platform. New value-add APIs and features are usually developed on top of the existing base platform ahead of official standardization. Over time, the new value-add features are standardized thru the Java Community Process program, and the features then migrate to the core platform to become an essential part of all the Java Powered brand devices.

Implementation fragmentation. The second common form of fragmentation is implementation fragmentation. Implementation fragmentation refers to the general situation in which Java ME platform devices implement the same APIs differently, usually accidentally rather than intentionally. This type of fragmentation is sometimes also referred to as quality fragmentation or implementation-level fragmentation. Common sources of implementation fragmentation include the following:

  • Incomplete or ambiguous specifications. Specifications are not always complete or detailed enough to guarantee full implementation-level compatibility. In many situations, specifications are ambiguous, leaving too much room for interpretation when implementing the specification.
  • Insufficient TCK test coverage. Technology Compatibility Kits (TCKs) do not always provide enough test case coverage to guarantee 100% compatibility of all the devices implementing a specification.
  • Insufficient quality assurance/quality testing. Implementation fragmentation is commonly also caused by implementation bugs and other quality issues. Since TCKs have tests only for compatibility testing, running a TCK successfully does not alone guarantee a high-quality implementation. Rather, in addition to compatibility testing, additional quality testing is always necessary in order to guarantee a high-quality implementation.
  • Insufficient interoperability testing. Incompatibility problems are often caused by various implementation- and device-level differences between devices that are beyond the reach of industry-wide specifications (e.g., proprietary network configuration settings, variances in security policies, legal requirements in different countries, etc.). Additional interoperability testing is usually necessary to guarantee compatibility across devices with different characteristics (See the device-level fragmentation discussion below.)
  • Time-to-market issues. A typical general source of implementation-level fragmentation is time-to-market. Most vendors are under a constant pressure to ship new products and new features. In certain situations, there is simply not enough time to ensure that all the features are implemented correctly.
  • Differences in deployment infrastructure and deployment policies. Refer to the “Deployment infrastructure and policy fragmentation” discussion later in this section.

Subtle implementation differences can be very annoying to application developers and users. From the application developer's viewpoint, implementation fragmentation means that various workarounds and device model specific customizations are necessary. This seriously undermines the Write Once, Run Anywhere value proposition, and can add significant costs to the application development process.

Device-level fragmentation. The third common form of fragmentation is device-level fragmentation. Device-level fragmentation arises from the different characteristics and features of the devices supporting the Java ME platform. There are numerous factors causing device-level fragmentation:

  • different screen sizes and color schemes,
  • different keyboard layouts and supported keys and/or pointer operations
  • different CPU speeds,
  • different amounts of RAM and storage memory,
  • the presence or absence of a file system
  • support for external and/or removable memory cards
  • different messaging and network options supported (e.g., Bluetooth, Infrared, MMS messaging),
  • different media capabilities such as the presence of a camera, audio/video recording, and add-on media codecs
  • hardware 2D/3D graphics accelerators, floating point libraries,
  • differences in Digital Right Management (DRM) support, etc.

Figure 4: Three different types of mobile devices
Figure 4: Three different types of mobile devices

Device-level differences can cause applications to behave in an incompatible way even though the underlying platform implementations would otherwise be 100% compatible. Device-level differences can also cause considerable degradation in application usability. Consider, for instance, the three different types of mobile devices depicted in Figure 4. Even though these devices may have exactly the same underlying hardware characteristics and software platform, the different screen sizes and usage models (one-handed, two-handed, or stylus-operated usage) of these devices makes the behavior and usability of the applications challenging. If an application was initially designed to be used on a device with a keyboard and a horizontal screen, the application developer cannot expect that the application would automatically behave very well on a stylus-operated devices with a vertical screen, unless the different user interaction models have been explicitly taken into account by the application developer.

The example above only scratches the surface of challenges caused by device-level differences. In the real world, it is very difficult to build a software platform that would work well on a wide variety of different types of devices with so many different variations in features and other device characteristics.

As is the case with platform fragmentation, device-level fragmentation fundamentally boils down to a tradeoff between fragmentation and innovation. While it might be possible to eliminate fragmentation – at least theoretically – by mandating a single device type with a single screen size, keyboard, form factor and other characteristics, in practice this is impossible without dramatically stifling innovation in the industry. Especially when it comes to consumer devices such as mobile phones, consumers have grown to expect a lot of choice and a vast array of models that have been customized for the different tastes and needs.

Other forms of fragmentation.

In addition to the three most common forms of fragmentation summarized above, there are additional forms of fragmentation that can also cause compatibility issues.

  • Standards fragmentation. For historical reasons, there are different standards in use in different parts of the world. For instance, early on in the history of the Java ME platform, a different standard called iAppli was developed for the Japanese market. Likewise, in the Korean market the currently used WIPI standard – albeit derived from the global Java Technology for the Wireless Industry standard – is somewhat different from the rest of the world.
  • Deployment infrastructure and policy fragmentation. To some extent, fragmentation is also caused by variances in the underlying network and backend infrastructure. For instance, different security policies adopted by network operators can sometimes prevent a Java application from working properly in certain networks, e.g., if access to certain network protocols is prohibited. Network bandwidth limitations and latency issues can cause variances in application behavior. Various downloading restrictions and differences related to application discovery, gateway support, etc. are also common. These kinds of policy issues or sometimes business issues are beyond what can be addressed by global standards.
  • Localization fragmentation. These days, applications will usually have to be written for users who are located in different countries and who use different languages and linguistic conventions. The process of customizing an application for different languages and conventions is commonly referred to as localization. For instance, if an application is intended for European markets, support for at least English, French, Italian, Spanish and German versions of the application will usually have to be included. Localization is a complex topic that is not limited only to the language of the textual strings that are presented to the user by the application. Some languages such as Russian, Chinese, Vietnamese or Japanese use a very different character set. The conventions, e.g., for number formats, currencies, dates and times can vary considerably from one country to another. The fragmentation problems in this area are somewhat similar to device-level fragmentation (e.g., screen size issues) in that localization can have a significant impact on the placement of icons, user interaction models, and other usability features. Even if a single worldwide application development standard exists, true Write Once, Run Anywhere remains a fallacy as long as localization issues are not explicitly taken into account while writing the application.

4. Addressing Fragmentation

By now it should be clear that fragmentation is a complex issue that cannot be solved easily once and for all. In general, except in the most trivial cases, applications cannot be 100% portable and compatible across a broad spectrum of devices in different market segments and countries, unless the application developer himself or herself has put at least some effort into ensuring the portability of the applications. In general, Write Once, Run Anywhere is not a magic bullet or a free lunch that would happen automatically.

Nevertheless, Java applications are generally far more portable than applications written for any other mobile application platform. Especially compared to systems in which applications are distributed in binary form, the portability of Java applications is superior. Many of the fragmentation problems observed in the Java ME technology industry today arise from the far greater popularity and widespread acceptance that the Java ME platform enjoys across different device manufacturers and various types of devices and hardware platforms.

That said, Sun is collaborating with key industry players and working in multiple areas to address the fragmentation problems and to generally improve the Write Once, Run Anywhere premise. These areas and solutions can be categorized broadly as follows:

  1. Addressing fragmentation through industry-wide JCP program efforts
  2. Addressing fragmentation through testing and verification initiatives
  3. Addressing fragmentation through optimized implementations and engineering services
  4. Addressing fragmentation through open sourcing
  5. Addressing fragmentation through improved tool support
  6. Addressing fragmentation through developer education and best practices
  7. Addressing fragmentation through continuing improvement the Java Community Process (JCP) program

Each of these areas is discussed in more detail below.

Addressing fragmentation through industry-wide JCP program efforts. One of the most important ways to address fragmentation in the Java ME technology marketplace is to create industry-wide JCP program standards and initiatives that establish a common base platform for the entire industry. The best examples of such activities in the past few years in the mobile device area have been the Java Technology for the Wireless Industry initiative (JSR 185) and the more recent Mobile Service Architecture (MSA) effort (JSR 248 and JSR 249).

The Java Technology for the Wireless Industry and MSA Specifications define industry-wide base platforms that are intended to serve as common standards across the entire mobile device industry. Java Technology for the Wireless Industry has been extremely popular, with several hundred million devices shipped so far, and the more recent MSA platform is expected to reach at least a comparable level of popularity within the next two years or so.

Industry-wide JCP program efforts address fragmentation primarily from two different viewpoints:

  • Reducing platform fragmentation. First, by defining a common set of component APIs that all compatible devices must include, these efforts establish a “lowest common denominator” platform, thereby guaranteeing the minimum level of functionality that all the devices across the industry will have. Second, platform fragmentation can also be reduced by minimizing the amount of optional and 'conditionally mandatory' features (see the discussion below).
  • Reducing implementation fragmentation. By defining additional clarifications and requirements that elucidate the behavior of the component specifications, these specifications eliminate errors, ambiguities, unclear details and other possible misunderstandings that the component specifications would otherwise have. Over time, such additional clarifications and requirements will migrate to the maintenance releases of the component specifications.

In general, the primary design goal of the industry-wide JCP program standards is to minimize fragmentation of mobile Java technology environments by defining a predictable and highly interoperable application and service environment for developers. To achieve this goal, the specifications define the minimum set of supported component APIs (building upon existing JCP program standards), additional clarifications, additional requirements and recommendations for implementers.

A common goal of the industry-wide specifications is also to try to minimize the amount of optional and 'conditionally mandatory' features (e.g., features that depend on a presence of a particular hardware device or feature such as Bluetooth or a global positioning device). Optional or conditionally mandatory features can sometimes degrade application portability significantly, since the application cannot assume that certain APIs would always be available or functional.

Addressing fragmentation through testing and verification initiatives. As already mentioned before, Technology Compatibility Kits (TCKs) alone cannot guarantee high quality of an implementation of a specification. Since TCKs focus only on compatibility and conformance aspects, additional testing measures are usually needed to help validate the completeness and performance of all the specified functionality. In general, functional testing, quality testing, performance benchmarking and other important issues need to be addressed through additional efforts separately from TCKs.

Sun has created a number of initiatives (some of them in collaboration with other companies) in the testing and verification area to minimize implementation fragmentation. These initiatives include:

  • Java Device Test Suite
  • Unified Testing Initiative
  • Java Verified™ Program

Java Device Test Suite. Today's service providers and device manufacturers face a variety of challenges when creating products to meet the increasing demand for mobile devices that take advantage of Java technology. The growing complexity and diversity of devices – with their varying operating systems, processors, and memory configurations – increases the need for thorough testing to ensure customers will be satisfied. At the same time, service providers and manufacturers face the challenge of managing – and, if possible, lowering – internal costs caused by excessive engineering overhead, disorganized development of test cases, or the impact of new data services on support operations.

Java Device Test Suite simplifies quality assurance and reduces time-to-market for Java ME platform implementations by providing comprehensive tests and a robust test manager. These enable suite users to evaluate, validate, and verify the quality of implementations of the Connected Limited Device Configuration (CLDC) and the Mobile Information Device Profile (MIDP) on a particular device.

In addition to comprehensive tests for all facets of Java ME platform implementation quality such as functional, stress, performance and robustness tests Java Device Test Suite also includes a (De)Fragmentation Profile to detect variances in Java ME platform stack implementations across different devices that support the same API. This suite is based on the thorough analysis of Java ME platform applications and feedback from Java ME platform content developers community to identify the functional areas in Java ME platform that are key for portability and consistent user experience. A wide acceptance of the Java Device Test Suite among Java ME platform device manufacturers and service providers helps to detect and prevent implementation defects and differences in spec interpretation among devices. Being an industry standard quality verification and analysis tool for Java ME technology, the Java Device Test Suite helps device manufacturers and service providers to reduce the fragmentation while maintaining the diversity among platforms and to ensure their reputation for quality, while building customer satisfaction and loyalty.

More information on Java Device Test Suite is available at: java.sun.com/products/javadevice.

Unified Testing Initiative (UTI). The Unified Testing Initiative (UTI) is a cooperative effort formed by Sun Microsystems and mobile device manufacturers Motorola, Nokia, Siemens, Sony Ericsson, Vodafone Group and LG Electronics. These industry leaders have streamlined their various mobile Java application testing programs into a single, comprehensive program that provides application testing, promotion and distribution support for developers.

As a cooperative effort, the UTI is open to new members throughout the mobile Java ecosystem. Members may come from the ranks of mobile device manufacturers, wireless network operators, Java technology providers, publishers/developers, managed service providers, and other firms with interests in furthering the success of the mobile Java technology platform.

The UTI has developed specific testing requirements related to the operating characteristics of Java applications for mobile devices such as handsets. These testing requirements are known as the Unified Testing Criteria. The goal of the UTI is to grow supply and demand for mobile Java applications by driving the development, promotion and distribution of high-quality mobile applications for the Java platform. This is achieved by providing a comprehensive test arsenal – defined by mobile Java ecosystem constituents – against which mobile Java application developers can test their applications.

More information: http://www.javaverified.com/about_uti.jsp

Java Verified™ Program. The Java Verified Program provides a streamlined testing process for mobile Java technology applications, enabling developers and wireless operators to confidently develop, deliver and monetize mobile applications. Java Verified Program is an open, industry-driven effort that utilizes the testing framework developed by the Unified Testing Initiative launched by Motorola, Nokia, Siemens, Sony Ericsson,Vodafone Group, LG Electronics and Sun Microsystems.

More information on the Java Verified program is available at: http://javaverified.com

Addressing fragmentation through optimized implementations and engineering services. As mandated by the JCP program process, each specification is accompanied by a Reference Implementation (RI), i.e., a sample implementation that exemplifies the correct implementation of the specification. Most reference implementations are intended for illustrative purposes only, i.e., they are not intended to be used in the actual (released) products and devices.

In the early days of Java ME platform evolution, each company in the industry maintained their own product implementations of the Java platform stack, including implementations of all the core specifications. This diversity in the implementation (basically: separate source code bases for each company) contributed to the implementation variances and bugs that we still see in the industry today.

One way to alleviate implementation fragmentation is to use a single source code base, i.e., a common “golden stack” implementation, across different manufacturers and other vendors. To this end, Sun offers customized implementations of all the key Java ME platform standards in the form of optimized implementations that can be licensed from Sun. Optimized implementations include various features that focus specifically on product quality factors such as performance, footprint, portability, extensibility, full implementation-level compatibility, and easier code maintenance. In addition to optimized implementations, Sun also offers engineering services and licensee support that are available in case additional customization is still desired by a customer.

Addressing fragmentation through open sourcing. One important way to significantly reduce fragmentation is open sourcing. By opening up the source code of the Java platform implementation to the development community, it is possible to encourage the entire industry to adopt a common “golden stack” implementation that is maintained collaboratively by the industry.

Addressing fragmentation through improved tool support. Even if the Java ME platform implementations in every single device were identical there would still remain differences between different targets (screen size, button layouts, etc.). Therefore, the savvy application developer must accept that one binary will not be sufficient for meeting the needs of all users. With this in mind, several tools have addressed this issue by adding support for preprocessing.

The preprocessing approach allows developers to create multiple versions of the application all from one source file, without requiring a huge binary file bloated with conditional statements. Instead, using tools such as the free, open-source NetBeans Mobility Pack, developers can create as many “if-then” scenarios they need within one master source file, then create all of their target builds with the click of a button. These conditional statements can address all manner of differentiation in the Java ME platform space including:

  • Using or not using an API depending on device support
  • UI tweaks depending on physical device discrepancies
  • Optimizing for specific processor or memory constraints
  • Workarounds for known issues and bugs
  • Account for localization
  • Custom branding for operators, distributors, etc.

Tools are additionally helpful for coping with fragmentation by providing emulators for different devices or implementations. Developers can use these to troubleshoot and design applications for different targets without having to acquire every single device and cope with the vagaries application provisioning during the early stages development and testing process.

Addressing fragmentation through developer education and best practices. Fragmentation problems – especially at the application level – often reflect insufficient understanding or unrealistic expectations about application portability. As discussed earlier, non-trivial applications cannot usually be entirely portable and compatible across a diverse range of devices unless the application developer has put extra effort into ensuring the portability of the applications. Even in an ideal world without any platform or implementation-level fragmentation, many of these issues would still remain.

This is really a developer education issue; to have realistic expectations about portability; to know what it takes to write a truly portable application; to know about techniques, conventions and design patterns that can be used to, e.g., take into account different screen sizes, layouts and user interaction models, or behavioral variances caused by localization or different processor speeds (e.g., so that the gaming experience does not suffer on devices with extremely slow or fast processors).

The most important lesson here is to ensure that application logic is separated from the user interface during development. By taking the time to design applications for portability, the return on investment down the line is significant. More information on best practices and Java ME platform coding is available at the Sun Developer Network site.

Addressing fragmentation through continuing improvement of the JCP program. The JCP program is one of the most popular and successful standards bodies in the software industry, with over a hundred specifications created so far and dozens of specifications currently in development. The JCP program defines a common process and framework for Java technology standards work, and a sets the minimum level of expectations and requirements for all the Java technology standards. For instance, one key characteristics differentiating the JCP from many other standards bodies is that JCP requires every specification to be accompanied by a Technology Compatibility Kit (TCK) and a Reference Implementation (RI). For further information on the JCP program, refer to the JCP program web site.

Criticism has been leveled at the Java Community Process program because it has not managed to curb fragmentation in the industry as much as it ideally should have. This kind of criticism is not entirely unexpected.After all, the JCP program is a flexible process that leaves a lot of detail in the actual specification process up to the discretion of the Specification Lead. For instance, the decision-making processes can vary from one Java Specification Request (JSR) to another considerably. The style and format used for the specification itself can vary substantially. Likewise, the test coverage requirements for a TCK are not defined very clearly, and therefore the test coverage of TCKs across different JCP program standards can vary considerably.

The Java Community Process program itself is an evolving process that takes into account the feedback and experience from the past and ongoing Java platform standardization efforts. It has a governance organization (the JCP program Executive Committee) that is continually taking into account the feedback from previous JCP program efforts. New versions of the JCP program process are created periodically to refine the JCP program so it can better address fragmentation issues.

Summary

This paper discussed the main causes for fragmentation and what Sun and the industry is doing to address it at various levels – figure 5 summarizes possible remedies.

Figure 5: Summary of fragmentation and its solutions
Figure 5: Summary of fragmentation and its solutions

 
 
Close
loading
Please Confirm
Close