evice fragmentation is an issue that plagues the mobile application developer. With the thousands of devices on the market, it is difficult to know which devices can host a new application. Even when targeting only a few devices, it is difficult to determine the lowest common denominator of features and capabilities that the set of devices support. This makes building applications to that set very difficult. (For more information on understanding the various issues related to device fragmentation see Damith C. Rajapakse’s Web page.)
While device fragmentation has always been?and may always be?a troublesome issue in Java Platform Micro Edition (ME) development, at least Java ME developers now can look forward to some defragmentation in SDKs. At the end of 2008, Sun released the early access edition of the Java ME SDK version 3.0. This kit brings together in one SDK the Java ME developer tools (runtime, emulator and code editors) for:
|Figure 1. Installing Java ME SDK 3.0 Early Access: Installing the SDK requires you pick a destination for the install as well as specify the location of the required Java 1.6 environment, which should be automatically detected by the install program.|
- Connected Limited Device Configuration (CLDC)
- Connected Device Configuration (CDC)
- Blu-ray Disc Java (BD-J)
Although it carries the “3.0” moniker, don’t go looking for the 1.0 or 2.0 SDK versions. This is the first release of this tool. Presumably, it bases its version number on the fact that two previous major versions of the Sun Wireless Toolkits for CLDC (WTK) already existed. However, this tool also incorporates the tooling found in the Sun Java Toolkit for CDC (version 1.0), as well as integrated tools and libraries for BD-J and the Lightweight User Interface Toolkit (LWUIT).
Download and Setup
You can download the early access version of the Java ME SDK 3.0 from java.sun.com. According to Sun’s web page on the product, your development machine must be either a Windows XP or Vista (32 bit) system with a minimum of 200MB of disk space, 1 GB of RAM, and a 1GHz Pentium CPU. Additionally, the SDK requires Java 6 (a.k.a Java 1.6). Additional software and/or libraries may be required depending on the type of application you develop and test.
The SDK downloads in a single 55+ MB executable file that you must install. When downloaded, execute the sun_java_me_sdk-3_0-ea-win.exe file on your system. Installation couldn’t be easier. Simply specify where to install the SDK, and indicate where the Java SDK (Java 1.6 or better) is located (see Figure 1). You may also choose whether to have the software check for automatic updates, which is probably prudent given that this is an early access product.
It Looks Like NetBeans!
|Figure 4. The Open Project Dialog in Java ME SDK: The SDK recognizes Java ME projects among other NetBeans shared projects and identifies them with a special icon.|
In fact, the SDK is based on the NetBeans platform. The SDK and NetBeans share a project system that allows development to go back and forth between the SDK and NetBeans (for use with the NetBeans Mobility Pack). I had a number of Java ME applications that were built in NetBeans. All I had to do to use the same NetBeans projects in the SDK was to use the Open Project option in the File menu of the SDK and point the SDK to my old NetBeans projects. The SDK’s Open Project dialog window even helped identify the Java ME projects from other types of projects in my NetBeans project folder by placing a little Java ME SDK icon next to the folder containing Java ME code (see Figure 4).
For those with projects in the WTK or CDC Toolkits, these projects can be imported/converted into the new toolkit through the New Toolkit dialog. Simply select New Project from the SDK’s File menu, and a dialog window will take you through the steps for converting the projects to the NetBeans/Java ME SDK project system (see Figure 5 and Figure 6).
So, what does this new SDK have to offer? How does it differentiate itself from other tools? Listed below are some of the notable features in the Java ME SDK 3.0.
Locating and removing potential performance bottlenecks and memory issues can be an extremely difficult task in any type of application. While the JVM manages memory, you can inadvertently create Java objects that are referenced long beyond their usefulness in an application, creating a de facto memory leak. In Java ME applications, where resources are often very limited, these types of issues can turn catastrophic quickly.
Profilers are tools that let you monitor many aspects of an application as it runs , such as heap, threads, memory consumption, and performance, in order to avoid resource issues in deployed applications. The SDK comes with a profiler that you can use to monitor CLDC/MIDP applications. Again, the profiler is based on the NetBeans profiler that, in turn, uses Visual VM, which is the Sun-provided profiler shipping with Java SE 6.
You must enable the profiler for each device emulator. When you have created an application and it is successfully running on a device emulator, right-click on the device in the SDK’s Device Selector window and select Properties. In the device’s Properties window, enable profiling by checking the Enable Profiler check box. While there, you may also want to check the location of the file where the profiling data will be collected (see Figure 7 and Figure 8).
|Figure 9. Location of Profiling Data: As the application exits, the SDK will inform you where the profile data is stored in the Output window.|
With the device set to profile, simply run an application on the device emulator to test the code for which you want to collect execution data. Profile data is collected until the application exits. As you exit the application, check the Output window. The location of the profile file will again be listed in the Output window (see Figure 9).
With the profile data collected, select Import Java ME SDK Snapshot… from the Profile menu on the SDK. In the resulting window, enter the location of the profile data as specified in the Output window when the application completed running. A window will display the CPU snapshot taken during the execution of the application (see Figure 10 and Figure 11). The various tabs and granularity settings (package, class and methods) allow you to dig into method invocations and times in order to root out potential issues.
Device Database Search
Device fragmentation is not going away, but the Java ME SDK can answer questions such as “Will my app work on product X?” and “What devices support the following platform specifications?” The Device Database Search engine built into the Java ME SDK provides a quick-to-access, searchable repository of over 3,000 devices. The Device Database Search capability utilizes data and tools from the Wireless Universal Resource File.
The device data comes from a community-maintained XML file (wurfl.xml) that contains, as stated on the WURFL website, “info about all known Wireless devices on earth.” A search engine on top of this file allows developers to quickly locate devices that meet specified criteria. To access and search the WURFL data, select Device Database Search from the Java ME SDK’s Tools menu option (see Figure 12).
|Figure 12. Start a Device Database Search: To search for mobile devices that might meet your application criteria, select the Device Database Search from the Tools menu of the SDK.|
|Figure 13. The Device List: To see all the devices listed in the WURFL database, uncheck the Use Filter option and click the Search button.|
To see all the devices in the database, uncheck the “Use Filter” checkbox and click the Search button (see Figure 13).
Device characteristics such as device vendor, screen resolution, color depth, graphical image support (jpeg, gif, etc.), Wi-Fi support, and heap size, as well as support for the various Java ME configurations, profiles, and APIs, are available for each device. The filter allows you to search the device database for devices that meet specific parameters (such as device-supported APIs, vendor, screen resolution, and so on ). For example, if you need to know which devices support MIDP 2.0/CLDC 1.1, the Java ME 3D API, and also have screens that support at least 256,000 colors, simply use the filter, specify the filter properties as shown in Figure 14 and Figure 15 and click the Search button. The answer, by the way, is eight devices.
The Lightweight User Interface Toolkit (LWUIT) is a UI library for creating richer and more portable Java ME user interfaces (see my previous DevX article for an introduction to LWUIT). As a recent add-on to the Java ME environment, you must manually incorporate the LWUIT libraries into most development environments.
The SDK 3.0 supports LWUIT out of the box. Simply right click on any project in the SDK’s Projects view and request the project’s properties. In the properties window, click on the Libraries & Resources option and add LWUIT to the project’s libraries (see Figure 16 and Figure 17).
Java ME SDK provides the ability to build, test, and create the image to be burned onto a Blu-ray disc. Because of licensing restrictions, the SDK does not come with this capability out of the box; BD-J stubs and a Blu-ray player are required to build and test your BD-J apps. However, the SDK can locate and utilize ArcSoft’s TotalMedia Theatre player out of the box, and you can configure it to use other players such as WinDVD and PowerDVD.
Bruce Hopkins has written two excellent how-to pages on the Sun Developer Network on the use of Java ME and Blu-ray technology. In the second of the two pages, he demonstrates the use of the new Java ME SDK to author, edit, and compile a sample BD-J application.
Emulation and On-device Debugging
As all Java ME developers know, an emulator often doesn’t provide a true indication of how the application will behave when deployed to the device. Therefore, the SDK also supports on-device deployment and debugging. In addition to its prepackaged emulators, the platform also allows for integrating other third-party emulators. In fact, the SDK comes with a CAB file that serves as a CLDC/MIDP emulation environment for Windows Mobile devices (see Figure 20). You can install the CAB file on a Windows device or emulator, which turns the Microsoft mobile device into a Java ME platform.
|Figure 20. Windows Mobile Emulator: You can deploy and run the CAB file that comes with the Java ME SDK on a Windows Mobile (ARM processor), providing a CLDC/MIDP environment on the device.|
Future versions of the SDK will bolster on-device capabilities by offering on-device profiling, memory and network monitoring.
JavaFX Support Not There Yet
The early access release of the Java ME SDK does not contain JavaFX runtimes or emulators, but according to Najman the final release will. In fact, at least two of the emulators will be JavaFX enabled. Having a single SDK to test all aspects of a Java ME application, including the JavaFX Mobile parts, will be an important feature.
Although the Java ME SDK will provide a testing environment for JavaFX, it is not intended to be the development platform for JavaFX. The JavaFX SDK (version 1.1 was released in February) is the tool Sun recommends for JavaFX development.
Under the Covers
Unlike the features listed so far, some of the features in the SDK 3.0 cannot be seen. Under the covers, the new toolkit sports a new virtual machine. The WTK used the KVM (Kernel-based Virtual Machine), which according Najman is “deprecated and close to End of Life.” Therefore, Sun replaced the KVM with its CLDC Hotspot Implementation Virtual Machine (CLDC HI VM) in the SDK. This virtual machine should provide substantial performance improvement over the KVM.
The CLDC HI VM is open source (find more information through the PhoneME project). As a result, “it gives an option to PhoneME developers and others to use SDK as a platform and plug-in custom runtimes into the SDK” states Najman.
The SDK also supports CLDC 1.1 and MIDP 2.1 applications. It also contains support for new Java ME JSRs such as the Mobile Sensor API, XML API for Java ME, and Java Binding for OpenGL ES. In fact, Sun claims this is the first Mobile Service Architecture 1.1 (JSR 248)-compliant stack.
Early Release Issues and Future Development
Because this is an early access release of the Java ME SDK 3.0, it contains some bugs and limitations. Examine the “Known Issues” list found in the Release Notes that come with the product, especially if you run into something that doesn’t appear to be working correctly.
The documentation also is?predictably?somewhat limited. In particular, testing on the device can be a little tricky to set up and usually requires some trial and error to get it right. However, the sample applications provided with the SDK help demonstrate almost all of the major new and improved features of the environment.
So when should you expect a final release? According to Radko Najman, the final release will be available by the JavaOne 2009 conference (June 2-5, 2009). Beyond the forthcoming final release, future Java ME SDK releases will extend on-device tooling and the Java ME SDK team will provide updates through the update center. In fact, the SDK team hopes to use the autoupdate feature to release the latest tools sooner than the usual release cycle allows. The hope is that other device vendors, network carries, and so forth will also be use autoupdate to deliver their specific features through and to the SDK platform.