Java vs. C++ on Palm OS

By Theodore Beisler

Abstract

            As mobile computing becomes more pervasive the need to program mobile devices becomes more apparent.  Deciding on the appropriate programming platform for a new development effort is both a crucial first step and difficult decision.  Here we will reconcile the differences between two popular programming platforms for the Palm OS. 

This document will concentrate on free tools highlighting their use as well as differences in CPU and Memory benchmarks.  It will discuss the limitations of both platforms as well as their strengths. 

 

Palm OS Highlights

            Programming on Palm OS devices is different than programming on almost any other computer.  This reflects the design goals of these devices.  Devices that run Palm OS are small handheld computers, otherwise known as personal digital assistants (PDAs).  Palm devices were designed to be an extension of a more powerful computer: as a satellite viewer of a desktop program and as a mobile input device.  They were not designed as a standalone machine.

            To make the extension of the desktop idea seamless, HotSync® technology was developed.  Every handheld includes a cradle that attaches to a PC.  This cradle has a single button that when pressed backs up the handheld to the PC.  The HotSync® technology also allows the data to be updated and synchronized with the desktop program's data.

Palm OS devices have several distinctive physical features.  Some of these features impose limits on how the devices are programmed.  They all work together towards the design goals mentioned above.

The user interface is small and lacks a keyboard on most devices.   Typically the screen size has been 160x160 pixels but recent models have added both color and screen depth.  Some are up to 320x320 pixels with 8-bit color.  User interaction is also different.  The user interacts with the PDA by tapping, and sliding a stylus along a touch sensitive screen.  Palm OS devices also include Graffiti ®, which is a text-input system that uses predefined, easy pen-strokes as an alternative to handwriting recognition.

The Palm operating system is stored completely in ROM.  Some devices have flashable ROMs that allow for upgrading of the OS.  Most do not have this feature.  Extensions of the operating system can be made through what are generically called hacks.  The OS implements a series of system traps.  These are services that allow a programmer to intercept an operating system event and have user code affect a change in the event's behavior.

There is no traditional filesystem.  Palm devices do not have a hard drive.  They just have memory and the memory that they do have is limited.  The earliest devices had 128k but now there are some devices that have as much as 32MB of memory.

Memory is broken down into two areas, dynamic memory and storage memory.  The dynamic memory is used for programs, variables, the program stack and certain operating system functions.  The dynamic portion ranges anywhere from 12K to 184K.  The storage memory is broken down into databases.  Databases are somewhat analogous to a file in a traditional file system. 

These devices are battery powered.  They run on low power processors that do not have a lot of computing power.  Most devices run on Motorola Dragonball processors from 16MHz to 33MHz.  Newer devices will support ARM processors, which promise greater speed and larger memory sizes.

 

C++ Language Issues on Palm OS

            Programming in C is the de facto standard for programming on Palm OS.  In fact, Palm OS itself was written in C.  Subsequently, all of the documentation on Palm OS focuses on C programming.  There is a wealth of information available freely from Palm and also on the Internet.  Transitioning to C++ seems like it would be a natural progressive step.  However, due to the overhead involved in object-oriented programming and the small amount of memory available the task is actually a bit more challenging. 

            To compound this, the Palm OS Programmer's API is at a very low level.  One must understand well how the operating system manages memory, processes events, and how to implement the graphical user interface.  The API is also quite large and therefore increases the slope of the learning curve.

            Since memory is small on Palm OS devices, C++ programmers must learn to code for memory efficiency.  Random Access Memory is partitioned into two portions, a storage and dynamic area.  Each area is called a heap. 

The storage area of memory is nonvolatile and can be likened to a file system.  The storage memory is broken down into databases.  Databases are broken down into records.  Records have a size restriction of 64Kb.

Programs on the Palm OS are resource databases.  They differ slightly from regular databases in that they have an index by Resource ID.  Resource databases include resources that range from forms and bitmaps to code resources.  Due to the physical 64Kb limit for a record in a database, the physical size of a program's code can only be 64Kb without splitting the application into multiple code resources or creating shared libraries.

            Another physical limitation to programming on a Palm OS device is a maximum 32Kb relative jump size.  Function calls and method invocations are translated into relative jumps by the compiler by default.  If a method's code and the calling function are too far away, a compilation error will result.

            There are a couple of ways to rectify this problem.  You can write what are called "Island Functions" which are placed in between calling functions that make two hops to get to the function, or you can rearrange the linking order of your code.

            The dynamic heap is broken into two parts, a program stack and dynamic memory.  The program stack is very small.  Sizes range from 2.5Kb on older devices to 3.5Kb on newer devices.  The size of the stack can be increased on Palm OS 3.0 and above, but it eats into the dynamic memory area. 

This size restriction makes recursion almost out of the question.  Also, the allocation of local variables goes onto the stack so a simple line like:

 

            int array[5000];

 

in a method will cause a stack overflow.

            Changing a line like that to be static will place the memory in dynamic memory instead of on the stack.  This has repercussions as well.  When it is declared static it will remain in the dynamic heap through the life of the program just like a global variable.  There are also certain situations where a global or a static local variable is unavailable.

            Palm OS is a multi-threaded operating system, but using multi-threading is restricted to the operating system.  Developers are not allowed to use it.  Palm programs are typically written in a progressive state fashion, allowing a non threaded environment to feel like it is multithreaded.

Interprocess communication is achieved through launch codes.  A program can launch another application with a specific launch code to ask it to do something.  When an application launches another application a full context switch is not performed by the operating system.  The dynamic heap remains the heap for the calling program.  The called programs global and local static variables are never allocated and thus unavailable for the duration of the launch.  Programmers need to be aware of this if they intend to handle launch codes other than the sysAppLaunchCmdNormalLaunch code, because any global or static variables will not work.

            A good example of a non-standard launch code is the global find utility that is provided by the operating system.  The global find utility launches each application on the PDA with a launch code of sysAppLaunchCmdFind and a text string to find.  The application is responsible, if it wishes to participate in global find, to find and respond with its appropriate records.  A programmer writing for such a function must be careful not to access any static or global data when doing such find since they won't be available.

            The dynamic heap is relatively small.  Newer devices have up to 256Kb of dynamic heap.  The size available to the programmer is considerably less.  The program stack takes up space, the operating system uses some space for its variables and the TCP stack also takes up more room.  Even with 256Kb of dynamic heap one can only realistically expect to be able to use 184Kb.  To program for backward compatibility, then one should only use less than 32Kb.

            In C++, memory management is up to the programmer.  The new and delete keywords are readily available for use as well as object constructors and destructors.  There is a situation where using standard C++ memory routines can cause some trouble.  When using and freeing up a lot of memory, you run the risk of fragmenting the dynamic heap.

The new keyword allocates a locked memory pointer for the object's data.  If objects are spread throughout the contiguous heap and the heap is therefore fragmented, then there may not be a large enough contiguous chunk for a new allocation.  Fortunately, Palm OS includes memory management routines that can help prevent this type of situation.

The concept of a handle is important in Palm OS programming.  A handle is different than a memory pointer.  A memory pointer is simply an address location in memory.  A handle is a reference to a movable chunk of memory.  Actually, it is a pointer into a reference table that the operating system keeps.  When the operating system needs to free up contiguous space, it can move these chunks around and change the pointer in the reference table.

Using a handle in a C++ program is pretty straightforward.  One must allocate a chunk of memory and get its handle.  When one wants to read or write to that portion of memory, simply lock it so the OS doesn't move it while you are using it, then unlock it when you are done.  The Palm OS routines for doing this are MemHandleNew, MemHandleLock, MemHandleUnlock and MemHandleFree.

            Another noticeable difference for programming C++ on Palm OS is the lack of standard libraries available.  The operating system has built in functions to replace many of the standard C libraries but nothing has been done with C++ libraries.   That means that, for instance, there is no string class available and no iostream either. 

 

C++ Tools

            This section will describe the tools used to create the programs in C++ for the benchmarks and comparison sections of this document.  As a companion to this document, the source code for all of the programs will be available as well as a set of base classes that can be used as a skeleton program.  The base classes include wrapper classes for a good part of the graphical user interface on the Palm OS.  The idea was to have a set of classes to easily create a graphical interface so language issues and writing comparison programs could be focused on by this document.

            All tools were used on a Windows platform.  Unix tools are available as well and their use is very similar, but they will not be highlighted here.

            Palm OS SDK 4.0 – Palm publishes a software development kit for C programming.  It includes headers for calling operating system routines and using system structures.  No programming tools such as compilers are provided with the SDK.  The most current version for the Palm OS SDK is 5.0.  However, that version has been released only for use with Code Warrior up to this point.

            Palm OS Emulator – Palm has a software emulator program that runs on a desktop computer.  Various skins are available to make it look like most of the various Palm devices and other 3rd party Palm powered devices.  The emulator allows the mouse to be used like a stylus and also allows for keyboard data entry.  A ROM image is needed to run the emulator.  The emulator does not include ROM images.

            ROM Images – ROM images are available if you own a Palm powered handheld or if you are a registered developer at Palm.  It is easy to register as a developer and it is free.

            Cygwin – Cygwin is a Unix shell for Windows users.  This needs to be installed as a base environment for the most of the tools.

            PRC-Tools – PRC-Tools is a package of tools for programming in C and C++ on Palm OS.  It includes the Gnu Compiler Collection, assembler, linker and symbolic debugger as well as several other tools useful for Palm programming.

            PilRC for Win 32 – PilRC converts resources described in a script file into a binary resource file.  Used for creating a Graphical User Interface via a script.

            PilRCEdit – This tool is optional, but it makes life much easier.  PilRCEdit is a graphical user interface editor that produces PilRC script files.  It is written in Java.  PilRCEdit provides for many of the standard GUI objects.  Some manual editing of the script file is still necessary for unimplemented objects such as menus.

 

Using the C++ Tools

            The graphical interface is built using two tools, PilRC and PilRCEdit.  It could be done with just PilRC but PilRCEdit makes it a lot easier.  PilRCEdit allows you to create forms and alerts in a WYSIWYG environment.  Simply place buttons, fields, labels, etc on your forms and then assign each an identification number.

            Every resource should have a unique ID within the program.  This is not strictly required but it may save some confusion when debugging an application.  Every resource within a resource type such as control or form definitely need to have unique IDs.  Resource IDs are usually defined in a header file with a unique name. That header is then included in the resource file created by PilRCEdit and in the main program.

            Any text editor can be used to write source code.  The source code is then compiled and linked using the gcc compiler included with PRC-Tools.  The command for the compiler is
m68k-palmos-gcc. 

            There are several compiler switches that are useful to know.  Exception coding in C++ adds a considerable amount of overhead because of the libraries that get linked in.  Also, Real Time Type Identification (RTTI) adds similar overhead.  Adding the compiler flags
–fno-exceptions and –fno-rtti will dramatically reduce the size of your executable.  In one test without these options a simple program compiled to a size of 25,636 bytes.  With these options the same code compiled to 5655 bytes.  This is a significant difference when there is a 64Kb limit for a code segment. 

            When either the keywords new or delete are used, a similar bloating of the executable occurs.  This is because the libraries involved were compiled with exception handling and the linker brings in additional code to support it.  Add the –lnoexcept flag to the linker line to reduce your file size.  If you think that you really want to use exceptions then you should take note of the following line from the PRC-Tools FAQ page: "If you are wanting to use exceptions, you should note that actually throwing an exception is probably currently broken anyway, due to a bug in prc-tools."

            To actually create a program that is able to run on a Palm OS device, you need to compile your program using gcc, create a binary resource file using PilRC and then use the build-prc tool included with PRC-Tools to put it all together.  Using a Makefile is recommended to script this process.

            Once the program is created it can be tested on the Palm OS Emulator or even a real device.  It is recommended to run a program on the emulator for the first time.   Programming in C++ allows a programmer to read and write into memory areas that are not "owned" by the running application.  A runaway program could clobber another program or its data.

            The Palm OS Emulator has some functions built into it that aid in debugging.  Debug-ROMs are available that give warning messages when problems are perceived by the operating system.  As an example, the operating system of a debug-ROM might tell you that it detected memory leaks in your application, or it might warn you when the stack is nearly full instead of crashing when it is full.

There is also a version of the emulator that supports profiling.  By profiling your code you can really see what is happening within your program.   You can graphically view your runtime with popular tools such as KProf or Proview.  To make you profiling data readable you must include the -mdebug-labels switch to you compile line.

            To actually step through and debug a program, PRC-Tools includes a version of gdb.  The debugger is invoked with the command m68k-palmos-gdb.  The debugger then needs to be connected via a tcp port to the emulator.  The command to accomplish this is:

            target pilot localhost:6414

Also, the –g switch must be set during compilation and linkage for gdb to be usable.

 

JAVA on Palm OS

            Programming in Java on the Palm OS is very different than programming in C++.  It is very much like programming Java on any other platform, only smaller.  Since Palm devices run on a limited amount of memory and have slower processors than today's desktops, this isn't surprising.  Here we will specifically focus on the Java 2 Micro Edition even though there are several other third party virtual machines available.

            The Java 2 Micro Edition is Sun's development platform for small devices.  The J2ME is partitioned into Configurations and Profiles.  A configuration details a particular virtual machine, along with a hardware platform size range that it can be ported to.  It also details minimum set of APIs that is expected to be available for the configuration.  Currently there are two configurations.  They are the Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC).

            The CLDC is the configuration that includes Palm OS devices.  Other devices that fall into this category are mobile phones, pagers, and small retail payment systems.  Devices that fall under the CLDC all have the following general characteristics: 160 to 512 kb memory available to the Java platform, a 16 or 32 bit processor, low power consumption, often a battery, and connectivity, possibly intermittent, to some kind of network.

            There are two virtual machines that are specified in the CLDC.  The one that has been ported to Palm OS is the Kilobyte Virtual Machine (KVM).  The KVM is a small footprint, low power virtual machine.  It takes up 585KB on a Palm Device.  This is small compared to a full version of the JVM.

            Built on top of configurations are profiles.  Profiles add APIs to a configuration to make applications work on a set of devices.  Currently, only the Mobile Information Device Profile (MIDP) is available for Palm OS.  There is a Personal Digital Assistant Profile (PDAP) currently being developed through the Java Community Process (JSR 75) which is expected for release soon.

            It is important to mention some of the things that were removed from the J2SE when creating the CLDC.  For instance, there is no floating-point support.  Types of float and double can not be used in any CLDC program.  There is no Java Native Interface.  This means that Java programs will look and feel like Java programs, not Palm OS programs.  There is no support for reflection, RMI or object serialization.  Also error handling is limited.  The CLDC specifies only three classes for handling errors.  Most errors are left to be dealt with by the underlying device error handling system causing either an application abort or a system reset.

            MIDP programs are called MID-lets.  All applications are instances of the javax.microedition.midlet.MIDlet class.  MIDlets can be packaged into MIDlet suites for grouping similar programs.  Java uses its own terminology.  What Palm OS called Databases, Java calls RecordStores.  They are not the same things, however.  A Palm OS database cannot be accessed by Java and a Palm OS program written in any other language can't easily access a Java RecordStore.

            The MID Profile defines the API for the graphical interface.  MIDP's user interface classes are in the javax.microedition.lcdui package.  This package contains two different ways to go about creating a graphical user interface.  They are the Screen and Canvas classes.  The Screen class is used to create high level abstract user interfaces and the Canvas class is used to create interfaces such as game interfaces at a much lower level. 

            Also defined by MIDP is a set of classes defined in javax.microedition.rms for accessing persistent storage.  The classes in the javax.microedition.rms package work similarly to Databases in Palm OS.

            MIDlets were designed according to the "sandbox" model, which is a pivotal part of the Java security model.  That means that MIDlets are stuck in their own little world and can't have any interaction outside of their sandbox.  MIDlet suites are actually the basic unit of this model.  Take for instance record stores in persistent memory.  A MIDlet is allowed only to access record stores created by itself, or by other MIDlets in its suite.  MIDlets Suites on the same device can't interact with each other.

            The KVM has some basic system requirements.  It only runs on Palm OS 3.5 or higher.  Also, devices must have at least 4MB of memory to run the KVM.  These requirements preclude a large market share of older devices from the production target.  However, most devices sold today have more than the base system requirements and memory will only grow in the future.

            Most Java Virtual Machines include a full bytecode verifier that makes sure classes are safe to be run on the virtual machine.  Because of the bulkiness of the bytecode verifier, it was broken into two parts.  The two steps are a thorough one on the compiling machine, and a smaller step on the mobile device. 

            The first step is called preverifying.  Classes are checked to see if they are safe to be run and then arranged so that a second smaller pass can be done on the KVM side.  The KVM will reject any classes that have not been preverified.  It will run a second lightweight step and then run the code.  This whole process adds an extra small step in the development process but it also has some security implications.  A class file could be manipulated so that the KVM thought it had been preverified and still contain malicious code.

            There are some very nice features available with Java on the Palm OS.  There is the ability to program multiple threads.  Also, it has a garbage collector to free the burden of searching for memory leaks from the shoulders of the programmer.  It also has the great advantage of code portability.  The "write once, run everywhere" philosophy of Java is fully ingrained in MIDP.  Your programs will be able to run on any other MIDP device.

 

Java Tools

            Sun offers a plentiful supply of software development tools for their Java language.  They have some that are specially designed for the small device wireless world.  Most notably is the Sun One Studio 4, Mobile Edition.

Sun One Studio 4, Mobile Edition (optional) – Sun One Studio 4, Mobile Edition is a nice, easy to use IDE.  It streamlines the production of Java programs for the Palm OS.  It also includes and integrates the J2ME Wireless Toolkit.  Its debugger is invaluable.  Everything except writing the code is done for you here.

The interface takes a little getting used to.  Everything in it is context sensitive.  Each command can react differently depending on what is actually highlighted and in focus.  For instance, if you were just editing one of your classes and that window is active, pressing F6 to execute will cause the IDE will try to run your class, instead of your MIDlet, that it is a part of. You must explicitly highlight your MIDlet or MIDlet suite before running it and make sure that it is highlighted in the window that has focus.  However, once you figure out what is going on, development with this tool is a breeze.

            J2 SDK SE 1.3 – The Java 2 Software Development Kit version 1.3 is the minimum requirement, although version1.41 is now out.  This provides the framework for your Java programs.

            J2MEWTK 1.0.4 - The Java 2 Micro Edition Wireless Toolkit contains a preverifier, a packaging tool, and various emulators for MIDP devices.  There is even an application profiler, which unfortunately does not work with the Palm OS Emulator.  You can always profile your code on one of the other emulators.  The core of the toolkit is the KToolBar that groups all of the tools together for easy access. 

             MIDP for Palm OS – MIDP for Palm OS is the runtime environment for Palm OS devices.  It includes documentation, the Kilobyte Virtual Machine, demo programs, and a desktop MIDlet to .PRC file converter (which is also included in the J2MEWTK).

Palm OS Emulator – Palm has a software emulator program that runs on a desktop computer.  Various skins are available to make it look like most of the various Palm devices and other 3rd party Palm powered devices.  The emulator allows the mouse to be used like a stylus and also allows for keyboard data entry.  A ROM image is needed to run the emulator.  The emulator does not include ROM images.

            ROM Images – ROM images are available if you own a Palm powered handheld or if you are a registered developer at Palm.  It is easy to register as a developer and it is free.

 

Using the Java Tools

            The tools for programming Java on Palm OS are very good.  They are easy to use, and well documented.  They install easily and a relatively experienced Java programmer can be programming on a Palm OS device in a matter of hours.  The Sun One Studio gives a consistent interface to all phases of producing MIDP applications.

            To create a MIDlet or a MIDlet suite, you can use the studio's wizards to create your base program and started coding right away.  Running your application is a menu item.  The studio, compiles, preverifies, and packages your program and automatically runs the Palm OS Emulator with your code.  Debugging is as easy as running your program.

            The wireless toolkit is a bit more difficult to use.  Write your programs in your favorite editor and then use the KToolBar to separately preverify and run your MIDlets.  Again, the emulator will automatically pop up with your program running in it.

 

Benchmarks

            To compare the two programming platforms, I wrote a suite of benchmark tests for each one.  The intention was to determine how much slower Java was to native code and whether it was actually fast enough to be bearable.  There were four tests all together.  Below is a screen capture of the emulator running each program.  The Java program is on the left, and the C++ program is on the right.  Both programs work by selecting a test to run from the popup selection list and pressing the go button to get a result.


            Both sets of programs were run on the Palm OS Emulator and on a real device for test results.  The real device was a HandSpring Visor Platinum with 8MB of memory.  The Emulator ROM was actually transferred from the HandSpring device to be used in testing the programs.  All tests except for the stack test were run 5 times on both the emulator and the real device and then averaged.

 

Stack Test

The first test was a simple Stack Test.  This test simply runs a recursive function until the stack fills up.   It displays the recursive depth on the Result line at each step.  Running this test illustrates several points about the differences between C++ and Java programming.

            What happens when it actually runs?  The C++ program runs and fills up the stack.  On the emulator, a message pops up that the stack is getting full.  Pressing the "continue" button a few times actually causes the stack to fill up.  The only option is to reset the device.  On the real device, the stack fills up and the screen displays a gibberish pattern.  Again, a reset is needed.

            The Java program runs until its memory fills up.  There is no "stack" in the KVM, just a dynamic heap, and therefore the program runs a lot longer.  If you recall, the stack is under 4Kb and the Java Dynamic heap is up to 64Kb (user settable).  The difference is quite surprising between the two.

Results:  (higher is better)

Java

2014 frames

C++

83 frames

 

            Sieve Test

            The second test is runs an algorithm that calculates all of the prime numbers less than 16384.  This algorithm was originally conceived by the Greek mathematician and Astronomer Eratosthenes (276-196 B.C).  The Sieve of Eratosthenes is a very quick algorithm for computing small primes.  It is used frequently to benchmark test integer arithmetic.

            This algorithm works by allocating an array that is big enough to encompass one byte for each integer you wish to test.  Each byte represents the number that is its index.  You then initialize the array by flagging all of the possible numbers as being prime.  In other words, simply set each array element to a 1.

            Start with the number two.  Set to zero every multiple of two in the array to a zero because they are not prime.  Then find the next number larger than two that has is prime, that is, still has a one set in its array element.  Next set its multiples to zero.  Continue in this fashion until you have reached a number greater than the square root of your array size.

            The programs for this example actually ran the sieve algorithm ten times before returning a result.

 Results: (lower is better)

           

Emulator

Java

38.0558 Seconds

C++

  2.0066 Seconds

Real Device

Java

25.089 Seconds

C++

  1.009 Seconds

 

            MemSwap Test

            The third test is a memory-swapping test.  It takes an array of size 16384 shorts on the dynamic heap, and reverses the order of the array ten times.  It does this from the center of the array so the distances between memory element's averages to about half the size of the array.

Results: (lower is better)

Emulator

Java

20.028 Seconds

C++

  0.084 Seconds

Real Device

Java

13.042 Seconds

C++

  0.043 Seconds

 

            MemSwapDB Test

            The fourth test tests persistent memory use for each of these platforms.  The test program creates a database of 2048 records and initializes it.  The program then randomly swaps 2 records 2048 times.  The database is then closed and deleted.  The difference in running times here is fairly extreme.

            This algorithm was the most difficult to try to make similar between the two platforms.  This is because of the API differences between the javax.microedition.rms.RecordStore class and the Database Manager in Palm OS.  I used similar functions instead of taking advantage of some features in the Palm OS API that may have made the C++ algorithm more efficient.

Results: (lower is better)

Emulator

Java

6 minutes, 6.409 Seconds

C++

12.050 Seconds

Real Device

Java

5 minutes, 39.649 Seconds

C++

11.096 Seconds

 

 

Comparative Analysis and Conclusion

            The stack test illustrated a few important features for Java.  In Java, recursion can be used more freely than in C++.  Even with an empty function with no arguments, and no variable declarations in the function's body, C++ could only recursively call itself through 83 levels.  This means that recursive programming is severely limited in C++. 

This test highlighted the difference in programming difficulty between the two languages.  Divide and conquer algorithms can be written iteratively but they are usually much easier to understand and implement in a recursive fashion. 

The difference in programming difficulty isn't limited to just recursion.  Every aspect of programming in C++ on the Palm OS is at a lower level than Java.  One has to understand many aspects of the operating system in order to code in C++ successfully.  The Palm OS API is also much larger than the MIDP API, making it more difficult to learn.  By programming in Java you are protected from much of this by its higher-level language nature.

The stack test also illustrated error-handling differences between Java and C++.  The KVM stopped running when the memory was exhausted, but you could still press the exit button to get back to a menu.  In contrast, the stack test on C++ when run forces you to get out a paperclip and press the reset button on the back of the Palm Device.

I have only hinted at the graphical interface so far in this document.  The abstract nature of the Java Screen class seemed too limited to produce a quality user interface and the Canvas class seemed suited to game programming and not much else.  After using the Screen class a bit more extensively, my opinion changed.  One can create basic decent user interfaces that would be appropriate for many programs.  One can play tricks with the objects on a form to get them to line up the way you want once you know how the KVM lays them out on the screen.  These tricks wouldn't be suited to other MIDP devices such as mobile phones.

Also note here that once the PDA Profile comes out, graphical interfaces will be able to use a subset of the Abstract Window Toolkit.  Once this is available graphical interfaces should be much more flexible.

C++ will probably always be better suited to programs that need fancier graphical interfaces.  One has nearly full control over all of the resources of the device.  Every event can be intercepted and acted upon.  The price is programming time.  It takes a lot longer to set up a user interface from scratch in C++ than in Java.  In fact, with the benchmark programs 95% of the time was spent actually writing the C++ base classes that would make the GUI easy to manipulate.

  An important feature that C++ has that Java doesn't is the support of floating point math.  Support for floats and doubles is built into the operating system.  The M68k processor that is in all of the Palm devices up to this point doesn't do floating-point math but it is done in software (ROM).  In Java, ones only recourse is to write your own floating-point emulation.

C++ is much more flexible than Java.  Its ability to interact with the operating system makes it an attractive choice when programming with add-on features such as GPS devices, memory cards, or expansion cards with virtual file systems.  Also the interaction with other programs on the system gives C++ a big advantage.  Java will address some of this in the future with PIM (personal information management) classes in the PDA Profile.

            The Sieve algorithm illustrates the difference in number crunching speeds between C++ and Java.  Another thing to consider, along with computational speed is battery life.  Java is obviously using more CPU time and therefore more battery power.  After running all of the benchmark tests for this paper, the real device's batteries had run down about a quarter.  Programmers writing applications that are both computationally expensive and there is a concern over battery life should avoid Java.

            Network connectivity is another issue for discussion.  Both Java and C++ have the ability to connect via tcp-ip to a network.  Java does not have any facility for server side sockets.  They also both have libraries for using http easily.  It is hard to find any clear advantage here.

            The MemSwap benchmark leads us to a discussion of memory.  The device that ran these benchmarks has approximately 184KB of stack space.  The Java KVM limits you to a maximum of 64KB.  C++ programming allows you to better utilize all of the space available.  However, having a garbage collector is really nice.  Almost all of the bugs in the benchmark programs were memory management issues.

            Database versus Recordstore, which is better?  The Database Manager in Palm OS is very robust and certainly much, much more efficient.  But is efficiency all that important? 

The MemSwap DB algorithm was deliberately not a sorting algorithm.  Palm OS and javax.microedition.rms both have sorting facilities built into their structure.  They work by keeping the database/recordstore sorted as items are inserted.  How often does one swap memory in large quantities other than for sorting?  On a small device, this sort of efficiency is much less likely to be an issue.  Also, with threads, you can hide some of Java's memory latency.

Threads are a nice feature that Java has, which C++ doesn't on the Palm OS.  Heavy use of threads should be cautioned against if battery life is an important factor.  Both the KVM and the C++ EventWait routine put the device to sleep when there is little activity.  Extensive use of threads could prevent this battery saving feature.

All in all, Java and C++ both have their strengths and weaknesses.  Though Java is the obvious winner for rapid application development and quick startup time, it comes at a pretty heavy cost.  C++ overall is the better development environment for the Palm OS.  It is more flexible in terms of native functionality, much faster computationally, the graphical interface options are superior, and it is easier on your batteries.

References

           

 

Wireless Java: Developing with Java 2 Micro Edition – By Jonathan B. Knudsen, June 2001.

JSR-000037 Mobile Information Device Profile (MIDP) – Available from http://www.jcp.org

JSR-000075 PDA Profile for the J2METM Platform – Draft available from http://www.jcp.org

Palm OS Programmer’s Companion, vol. 1 – Available from http://www.palm.com

Palm OS Programmer’s Companion, vol. 2 - Communications – Available from http://www.palm.com

Palm OS Programmer’s API Reference – Available from http://www.palm.com

Using Palm OS Emulator – Available from http://www.palm.com

Palm OS User Interface Guidelines – Available from http://www.palm.com

The Palm OS Programming FAQ – Available at http://tangentsoft.net/palmfaq/

PRC-Tools FAQ – Available at http://prc-tools.sourceforge.net/faq/