PersonalJava and EmbeddedJava Development Tools

Print-friendly Version

• Tools will be written in Java, allowing development on the platform of choice.
• Platform-independent PersonalJava and EmbeddedJava code can be written and tested before the RTOS is selected or target hardware is available.
• Major third party Java development tools will include support for creating PersonalJava and EmbeddedJava applications.
• Tools add value within the entire development process from writing PersonalJava or EmbeddedJava code to producing a final device ROM image.
• Easy-to-use graphical user interfaces will make the interactive tools user friendly.
• PersonalJava and EmbeddedJava tools are simple to integrate with RTOS tools.

There are two general categories of users of these tools: device developers and application developers. Both of these types of users will be able to use some or all of the tools provided as part of the following process:

1. PersonalJava or EmbeddedJava code development
2. Converting all Java code to ROM format
3. Converting auxiliary files to ROM format
4. Producing the final ROM image

Not all the phases are required in all cases. For example, to produce a PersonalJava application that can be loaded over a network, only the first step is necessary. Or, to create an application which does not open auxiliary files such as HTML, images, or sounds, the third phase, "Converting auxiliary files to ROM format," could be eliminated.

The following sections detail each of the four development phases and the tools provided to assist developers within each phase.

1) PersonalJava or EmbeddedJava code development

There are several tools used in this phase: javac and JavaCheck.

The Java compiler, javac, is the same regardless of which Java Application Environment (JAE) is being used. This is why leading developers were able to produce PersonalJava and EmbeddedJava devices before the final JAEs were available. As is always the case for Java development, javac takes a Java source code file (.java) as input and produces a class file (.class) as its output.

JavaCheck is a tool that ensures that applications and applets will be compatible with Java platforms and can therefore run on many types of devices. It does this by testing whether Java class files used by an application or applet conform to a particular Java platform API specification. The recently released 2.0 version of JavaCheck provides support for the PersonalJava Specification.

JavaCheck reads platform specification files. These are encoded text files (SGML compliant) for a particular specification with the file extension .spc. JavaCheck reads these .spc files in order to represent a Java platform in memory. The JavaCheck 2.0 version provides .spc files for the PersonalJava platform allowing compliance testing to this platform. Platform specification files are created by Sun Microsystems for use with official Java specifications.

JavaCheck is available both as a command-line tool and as a graphical-user-interface-based tool. Both versions of JavaCheck give as output a listing of errors and one of three messages: does conform, may conform, or does not conform. The graphical tool provides additional features such as interactive sorting of errors and error level filtering. These features simplify tracking down disallowed classes.

2) Converting all Java code to ROM format

JavaCodeCompact takes java class files as input and converts these to platform independent C language source files. These files can then be compiled into ROM format.

As the first step of this phase, JavaCodeCompact is used to combine and compact all Java code that will be included in the device ROM. In addition to combining all PersonalJava or EmbeddedJava code written specifically for the target device, the JAE-base classes and optional classes are also included. The input to JavaCodeCompact can be any combination of class and multiclass files. The critical requirement at the end of this step is that there is only one multiclass file which contains all Java code. JavaCodeCompact than converts this platform- independent multiclass file to a platform independent C language source file.

The output from JavaCodeCompact is assembled by the standard assembler provided by the RTOS vendor to produce an object (.o) file. This object file will ultimately be linked into the ROM image.

Thus JavaCodeCompact bridges the gap between Java class files and device-independent multiclass files, and between multiclass files to system-dependent assembly files.

3) Converting auxiliary files to ROM format

This phase of the development process uses two tools: JavaDataCompact and an assembler.

From a tools perspective, JavaDataCompact is conceptually very similar to JavaCodeCompact in that both produce platform independent C language source files as output. The difference is that while JavaCodeCompact only accepts a single multiclass file as input, JavaDataCompact provides the means for including files such as HTML, images, and sounds in the device ROM. JavaDataCompact handles all data file types since it is simply copying the data from the input file without interpreting or understanding it.

Although seemingly similar, JavaCodeCompact and JavaDataCompact serve different purposes. JavaCodeCompact prepares all Java bytecodes to be linked to the Java Virtual Machine*. JavaDataCompact places data files into ROM so that they can be opened and read by the PersonalJava or EmbeddedJava applications.

The output from JavaDataCompact is assembled using the standard assembler for the target system. At the end of this process, one or more object (.o) files containing auxiliary data will be available for the final processing phase.

4) Producing the final ROM image

In this final phase, all files are linked together using the standard RTOS development tools so that a device ROM can be burned. Since other tools have already converted all of the various intermediate files into object files (.o), no Java-specific tools are required.

The standard RTOS linker combines multiple object (.o) files and produces a single executable file (a.out). No modification of the RTOS linker is needed to include PersonalJava, EmbeddedJava, or other auxiliary data files.
For the sake of this discussion, there are five types of object files which are combined by the RTOS linker:

• Java bytecodes
• Data files
• C or assembly Native Methods
• Java Virtual Machine code
• RTOS code

The Native Methods are created using the standard assembler or C compiler provided by the RTOS vendor. Typically, the RTOS code and the Java VM object files are provided by the RTOS vendor.

From the perspective of the RTOS linker, the object files which contain the Java bytecodes and Data files contain data tables. These object files can be linked to produce the executable image, the standard tools provided by each RTOS vendor can be used to burn a ROM from this executable image