Porting Java 2D package from J2SE to J2ME CDC
Introduction
Consumer electronics has become more sophisticated and user-friendly with the advent of embedded technologies. Java has been the language of choice in the area of embedded software development. Sun Microsystems, keeping in mind diverse development needs, has provided three different Java Technologies, depending on the environment that the application is targeted to run on.
The first technology, Java 2 Platform, Enterprise Edition targets applications that are developed to run on Enterprise Servers. The second, Java 2 Platform, Standard Edition targets desktop and Internet applications that run on Personal Computers. Finally, Java 2 Platform, Micro Edition targets applications that are developed to run on resource constrained and embedded devices.
Java 2 Platform, Micro Edition
Java 2 Platform, Micro Edition technology specifically addresses the needs of a wide variety of consumer electronics and embedded devices ranging from pagers, mobile phones, and Personal Digital Assistants (PDAs) to screen phones, TV set top boxes, etc.
The specification of J2ME also allows customization of the applications through the use of personal profiles specific to a particular kind of device, in order to meet the device's own requirements.
Configurations and Profiles
The J2ME Architecture is based on two fundamental elements :
- Configuration
- Profile
Together, these elements deliver a specification that consumer electronics and embedded device manufacturers can implement on their products.
Configurations
A "Configuration" is a Virtual Machine and a minimal set of basic class libraries and Application Programming Interfaces. A configuration specifies a generalized runtime environment for consumer electronic and embedded devices.
Java 2 Platform, Micro Edition provides two basic types of Configurations based on Memory requirements and resource constraints. These configurations are:
- Connected Limited Device Configuration
- Connected Device Configuration
Connected Limited Device Configuration
The Connected Limited Device Configuration [CLDC] is used in small, resource-constrained devices, and is composed of K Virtual Machine [KVM] and a minimal set of class libraries that can be used on a variety of devices.
The KVM is a highly portable Java Virtual Machine designed for resource-constrained and network-connected devices with very less memory.
CLDC is targeted at devices with
- 160 to 512 KB of memory
- Limited power, often a battery
- Limited connectivity to the network, often through Wireless, and
- Extremely constrained Graphical User Interfaces
Connected Device Configuration
The Connected Device Configuration is composed of the C Virtual Machine and a minimal set of class libraries and APIs that are needed to get the system up and running.
The CVM is a bluebook of the full Java 2 Platform Virtual Machine for high-end network connected devices.
CDC is targeted at devices with
- Minimum 512 KB ROM
- Minimum 256 KB RAM
- 2 MB or more of total memory, including RAM and ROM
- Connectivity to a network
- Support Complete JVM Specification, and
- Relatively constrained Graphical User Interfaces
CDC Class Library
The CDC class library is the minimal set of APIs needed to support a virtual machine. In general, CDC contains the minimal Java packages from Java 2 Platform, Standard Edition to build and run a Virtual Machine.
The basic Java packages for CDC are:
- java.lang - Virtual Machine system classes
- java.util - Underlying Java utilities
- java.net - UDP Datagram and File Input/Output
- java.io - Java File Input/Output
- java.text - Bare minimal support for I18n (ex. error messages)
- java.security - Minimal fine-grain security and encryption for object
Profiles
A "Profile" is an industry-defined specification of the Java APIs used by manufacturers and developers to address a specific type of device.
J2ME currently provides:
- Foundation Profile, for use with Connected Device Configuration
- Mobile Information Device Profile, for use with Connected Limited Device Configuration
Foundation Profile
The Foundation Profile is a set of Java APIs that, together with the CDC, provides a complete J2ME application runtime environment targeted at consumer electronics and embedded devices.
In general, the Foundation Profile contains the basic Java packages from J2SE, except that the Graphical User Interface dependencies on java.awt are removed.
Mobile Information Device Profile
The Mobile Information Device Profile is a set of Java APIs that, together with the CLDC, provides a complete J2ME application runtime environment targeted at mobile information devices such as cellular phones and two-way pagers.
Custom Profiles
In addition to the profiles mentioned above, applications can use their own custom-designed profiles to be used with the specific type of targets that need specific functionalities.
These profiles should be built very carefully so that only a limited set of APIs is included in order to achieve the required functionality.
Deprected API Removal
The CDC and Foundation Profile make corrections to the J2SE technology-based API library by removing all non-critical, deprecated APIs. The J2SE technology-based deprecated APIs are removed because:
- A clean start with the correct set of APIs is needed.
- Deprecated APIs do not have to be supported and maintained anymore.
- Each deprecated API has an equivalent new API. In all cases, the equivalent API is cleaner and more correct.
Need for Porting Java 2D Package
Currently, there is no AWT and Java 2D support for the Java 2 Platform, Micro Edition CDC. For devices that support Graphical User Interfaces, such as Screen phones, the functionality must be provided by a customized profile built on top of the Foundation Profile.
Porting Strategy
Java 2 Platform, Micro Edition CDC is available from Sun Microsystems through a Community Source licensing program. The Connected Device Configuration includes all the source code necessary for building a C Virtual Machine.
In addition to Configurations, Sun Microsystems has also provided a foundation profile for use with the CDC, which should be included when building the CVM.
Sun Microsystems currently provides implementations for two target platforms, namely:
- VxWorks
- Linux
This paper focuses only on the VxWorks platform. Building the implementation for VxWorks target platform requires a Host Development environment, typically a Sun Solaris machine running on SPARC platform. The Tornado development tool for the specific host development environment is required to build the CVM. The CVM that is built is then downloaded to the target platform running VxWorks.
The Implementation is built using the gnu make utility that is present with most of the Unix distributions. The gnu make utility is also provided with the Tornado development tool.
Our approach to achieve the porting is summarized as follows:
- Build the CVM without any porting effort
- Build Requirements
- Port the Makefiles to Windows Environment
- Tornado / VxWorks Build Procedures
- Identify appropriate Graphics Driver for use with VxWorks
- Initialize Graphics Driver through JNI call from Java application
- Identify Java 2D and required AWT classes
- Customize the Java 2D profile
- Rebuild the CVM with Java 2D profile
- Test the CVM with sample Java 2D applications
Build the CVM without any porting effort
The Implementation provided by Sun Microsystems has to be built without any porting effort in order to ensure that the C Virtual Machine is built properly. The C Virtual Machine can be tested to check if it was properly built with the test classes provided along with the Implementation.
Build Requirements
The implementations of the CVM are developed, compiled, and linked on a build system, also called the Host development system. The resulting output is then moved onto a target system for execution.
- VxWorks requires a Host Development environment having Tornado 2.0 to build the CVM. The CVM generated is then downloaded to the target machine running VxWorks.
- The Host development environment for VxWorks implementation has been Solaris Operating environment running on SPARC platform. However, we proceeded with our build using Windows 2000 Professional as the Host development environment.
- Building the CVM requires GNU Toolkit and other utilities that are provided as part of the Tornado 2.0 software.
Host Development Environment
- Solaris 7 Operating Environment or later [ note : We used Windows 2000 professional]
- SPARC Hardware [ note : We used x86 ]
- Tornado 2.0 development system
- Java 2 SDK, Standard Edition, v1.3 or later
- 500 MB available disk space
- 128 MB RAM (256 Recommended)
Target Environment
- VxWorks 5.4 Operating system
- PC with Pentium Hardware
- 8 MB RAM minimum (32 MB Recommended)
- 3COM 3C905CTX pci ethernet 10/100 10 base T
- 1.44 MB Floppy drive
- Must be on the same network as the host development environment
Porting the Makefiles to Windows Environment
Building the C Virtual Machine for VxWorks target platform using Windows as the Host Development environment involves a considerable amount of editing in the makefiles.
The following discussion assumes that
- The base directory of Tornado development tool for VxWorks is C:/Tornado.
- The base directory of J2ME CDC source code is C:/J2ME/cdcfoundation.
The hierarchy of folders and the makefiles present in the J2ME CDC source code that includes the foundation profile and that is of interest to us is given below:
C:
J2ME
cdcfoundation
build
share vxworks
defs.mk config_vxworks.mk
defs_cdc.mk defs_cdc_vxworks.mk
defs_foundation.mk defs_foundation_vxworks.mk
jcc.mk defs_vxworks.mk
rules_cdc.mk GNUmakefile
rules.mk rules_vxworks.mk
testgc.mk target
target
PC-boot PC
config.h Makefile
confignet.h
Makefile
Hierarchy of directories and makefiles present in J2ME CDC with foundation profile
As seen above, most of the makefiles reside in the directories
- C:/J2ME/cdcfoundation/build/share, and
- C:/J2ME/cdcfoundation/build/vxworks
The definitions and rules common to the different target platforms are placed in the "share" directory and those specific to the VxWorks target platform are present in the "vxworks" directory.
As the makefiles contain Unix specific commands, MKS Toolkit for Developers is used to emulate Unix environment in Windows. The "make" utility is run from the MS_DOS prompt from the directory C:/J2ME/cdcfoundation/build/vxworks.
The following edits were made in the makefiles to make them work with the Windows environment:
- Checking for conditions using "if-fi" conditional construct was not found to be mandatory and has been commented out.
- Redirecting the output of "echo" command has been modified to work with the Windows environment.
- Reading the file names from the list file in Unix environment has been done using "cat " command inside backward quotes. This was changed to use the @ symbol preceding the name of the list file.
- The "romjava" files were created using a sequential logic since the "for" construct used to iterate through the list file did not work.
- Use of "sed" editor required some editing to create the dependency files.
- Separate rules and dependencies were added to resolve the case insensitivity of file names in Windows environment.
- Creation of boot image for VxWorks required some editing in the "rules_vxworks.mk" file.
- Additional macros definitions were added as and when required in implementing our logic.
The hierarchy of folders and the makefiles present in the J2ME CDC source code that includes the foundation profile and that is of interest to us is given below:
build
vxworks classes.jcc
bin
cvm.o
btclasses
buildtime classes
cdc_classes
cdc class files
generated
cni
flags
jni
offsets
javavm
empty.mk
lib
cdc.jar
obj
object files
dependency files
testclasses
target
PC
default
vxworks
vxworks.sym
PC-boot
btclasses.zip
testclasses.zip
Hierarchy of directories and files created by build
Tornado/VxWorks Build Procedures
On the Host system, before building the implementation, we need to edit build/vxworks/config_vxworks.mk file to provide the following information :
- Target IP address
- Host IP address
- Host name
- Base directory for Tornado software (WIND_BASE)
We also need to create a .rhosts file in the home directory and add the target system name to the file.
To build CDC without the Foundation Profile, complete the following steps:
Step 1
On the host system, change directories to build/vxworks, and enter the following command:
make CVM_DEBUG=true
This may produce some compiler warnings about incompatibilities of argument lists for some system library functions. These may be ignored.
The products of this step are the files :
- build/vxworks/bin/cvm.o, which is a re-locatable file to be bound into the VxWorks kernel, and
- build/vxworks/lib/cdc.jar, which is a JAR archive to be used for the CVM's bootclasspath. The default bootclasspath is ../lib/cdc.jar.
- The build also produces build/vxworks/testclasses.zip, a collection of simple tests.
Step 2
In build/vxworks, enter the following command:
make CVM_DEBUG=true download_image
Note:Steps 3 through 5 assume the presence of a floppy drive on Solaris / Windows system. If your system does not have a floppy drive, you need to review the steps involved in the make targets "boot_disk" and "boot_rom" in the file build/vxworks/rules_vxworks.mk and adapt them to your host system. Once you have created the boot disk, proceed with step 6.
Step 3
For Solaris
- Insert a diskette into the floppy drive of your host system. Format the diskette using fdformat. The diskette is automatically ejected when formatting is done. Reinsert the diskette.
For Windows
- Insert a diskette into the floppy drive of your host system. Format the diskette using format.
Step 4
For Solaris :
- In build/vxworks, enter the following command:
make boot_disk
- The diskette is automatically ejected after the command is carried out. Reinsert the diskette.
For Windows :
- Skip this step.
Step 5
In build/vxworks, enter the following command:
make boot_rom
To build the Foundation profile, which will include CDC as well, modify the first step above to use the J2ME_CLASSLIB option:
make CVM_DEBUG=true J2ME_CLASSLIB=foundation download_image
This will produce build/vxworks/cvm.o and build/vxworks/lib/foundation.jar and set the default bootclasspath accordingly.
The CVM generated should be tested with the Test Classes that were provided to ensure that the CVM was built properly.
Step 6
Insert the diskette into a floppy drive on the target system, and boot the target system.
Note:For convenience, you may want to edit your home/.wind/startup file ( where home is your home directory) on the host system to add the commands in steps 7 and 8.
Step 7
On the target console, enter the following command:
cd "top_dir/build/vxworks/bin"
Step 8
On the target console, enter the following command :
runJava "-Djava.class.path= top_dir/build/vxworks/testclasses.zip HelloWorld"
This step should print a Hello world to the screen indicating a successful build.
Identify appropriate Graphics Driver for use with VxWorks
The Standard Drawing Library provided by Raster Graphics Inc. supports the VxWorks real time operating system. It can be considered for use with the VxWorks.
However, the Standard Drawing Library does not currently provide support for drawing graphics in windows.
Another Graphics Driver of interest may be Microwindows, which supports performing graphics operations in windows that use message queues as the communication mechanism.
Currently, Microwindows supports only the Windows Win32/WinCE GDI and Nano-X APIs. However, the driver could be modified to use the Standard Drawing Library provided by Raster Graphics Inc. while preserving the capability of the driver to draw graphics in windows.
This functionality is essential for porting Java 2D package, as all Java applications require a container such as a Frame to perform Graphics operations.
Initialize Graphics Driver through JNI call from Java application
Java Classes were written to initialize Graphics, provide implementation of primitive graphics operations and to exit graphics. The Java Classes uses JNI methods to perform these operations. The JNI methods in turn call the library routines of the Standard Drawing Library to initialize graphics and perform primitive graphics operations.
A Sample Java class file and its native implementation are given below :
Identify the Java 2D Classes and required AWT Classes
In order to port the Java 2D package, we need to identify the Java 2D Classes and the necessary AWT Classes that need to be ported.
The following list contains all the packages and classes included in the Java 2D API.
- java.awt.color
Provides classes for color spaces and color profiles based on the ICC Profile Format Specification. - java.awt.font
Provides classes and interfaces relating to fonts and support for representing Type 1, Type 1 Multiple Master, OpenType, and TrueType fonts. - java.awt.geom
Provides classes for defining and performing operations on two-dimensional geometric objects. - java.awt.print
Provides classes and interfaces for printing two-dimensional objects and includes support for specifying document types, controlling page setup and page formats, and managing job control dialogs. - com.sun.image.codec.jpeg
Provides classes for encoding and decoding JPEG images. - ava.awt.image.renderable
Provides classes and interfaces for producing rendering-independent images.
The java.awt and java.awt.image packages also include classes that are part of the Java 2D API:
java.awt
Contains classes for generating user interfaces and painting graphics and images. The following awt classes are part of the Java 2D API.
java.awt.image
Provides classes for creating and modifying images, as well as image producers, consumers and filters for configuring image processing. The following image classes are part of the Java 2D API.
Customize the Java 2D Profile
The Prime objective in building any customized profile for Java 2 Platform, Micro Edition is to keep the amount of APIs and methods that need to be ported to the least minimum.
The Classes and interfaces that form part of the Java 2D package in turn import classes and interfaces from the AWT package. In order to build the Java 2D package these AWT classes and interfaces should also be included in the build, which may in turn include other classes and interfaces and so on.
Thus, a careful analysis is needed to remove certain classes and interfaces from the included list of AWT classes that are not actually needed by the Java 2D classes.
This can be accomplished by,
- Removing certain import statements from classes and their corresponding references.
- Removing the methods and the corresponding Class references that are not needed by Java 2D APIs.
- Removing the Deprecated APIs from the included list of classes.
The customization of the Profile also requires re-implementing certain classes and JNI methods that are specific to the operating environment.
Rebuild the CVM with Java 2D Profile
The C Virtual Machine is then rebuilt with the inclusion of the Java 2D profile in the build. This is accomplished by adding the definitions and rules specific to the Java 2D profile in a separate makefile, and including them in building the C Virtual machine.
It also requires modifications of some macros and rules in other makefiles as well.
Test the CVM with sample Java 2D applications
The C Virtual Machine should then be tested with simple Java 2D applications to check if it is built properly.
Summary
The Java 2 Platform, Micro Edition CDC is an emerging technology and has been specified by Sun Microsystems to meet the requirements of the next generation consumer electronics and embedded devices.
The use of Java 2D package as a separate profile with the J2ME CDC would greatly change the look and feel of the graphical user interfaces of emerging consumer electronics devices like Screen phones, Personal digital assistants, and the like.
References
- The Java 2 Platform, Micro Edition CDC can be downloaded from www.java.sun.com/j2me
- The Java 2 Platform, Micro Edition CDC documentation and Porting guide can be downloaded from www.java.sun.com/j2me/docs
- The Java 2 Platform, Standard Edition SDK version 1.3 can be downloaded from www.java.sun.com/j2se
- The Tornado 2.0 development environment for VxWorks 5.4 can be downloaded fromwww.wrs.com
- A one-month evaluation version of the MKSToolkit for developers, can be downloaded from www.mks.com
- The Standard Drawing Library from Raster Graphics Inc. can be downloaded from www.rastergr.com/software.htm
- The Microwindows Graphics driver can be downloaded from www.microwindows.org