JAVA ON HANDHELD DEVICES COMPARING J2ME CDC TO JAVA 1.1 AND JAVA 2

Transcription

1 JAVA ON HANDHELD DEVICES COMPARING J2ME CDC TO JAVA 1.1 AND JAVA 2 Mikko Laukkanen Abstract: The current trend is towards having Java applications run on handheld mobile devices. Sun Microsystems, Inc. has addressed this trend by specifying an edition, namely Java 2 Micro Edition (J2ME), of the Java environment for handheld devices. J2ME divides into two configurations: Connection Limited Device Configuration (CLCD) and Connected Device Configuration (CDC). This paper focuses on the latter, which is targeted at nextgeneration embedded devices, such as handheld computers. Sun Microsystems, Inc. has released CDC specification, a white paper and a reference implementation, which are our main references for this paper. We will give an overview to J2ME and especially CDC, and take a practical view to CDC by testing the reference implementation using several test cases. We also compare CDC to Java 2 and Java 1.1 standard editions. Java 2 is chosen, because according to Sun, CDC should comply with Java 2, except Swingclasses. For this reason, we do not take Swing into account in our tests. Java 1.1 on the other hand is taken into account, because most of the today s JVMs on handheld devices are based on Java 1.1 functionality. 19

2 20 1 INTRODUCTION The Java 2 Micro Edition (J2ME) is a Java platform targeted at consumer electronics and embedded devices. The J2ME technology consists of a Java Virtual Machine (JVM) and a set of APIs for providing a complete runtime environment for the target device. The J2ME technology has two primary kinds of components configurations and profiles. A configuration is composed of a low-level API and an optimized JVM. At the time of writing, two configurations are available: Connection Limited Device Configuration (CLCD), which is targeted at environments, where Kb of memory is available for the Java environment and applications and Connected Device Configuration (CDC), which is targeted at environments, where more than 512Kb, usually about 2Mb, of memory is available for the Java environment and applications. A profile is a specification that details the Java technology APIs, which are built on top of a configuration. Profile utilizes the underlying configuration to provide a complete runtime environment for a specific kind of device. Figure 1 illustrates, how the configurations and profiles in J2ME relates to each other. On the bottom there is the target device and its operating system, which the configuration is specifically built for. The lowest layer of the configuration is the JVM, of which there are two choices based on the configuration used; K Virtual Machine (KVM) is meant for CLCD and C Virtual Machine (CVM) for CDC. The upper layer of the configuration is composed of a core class library, which includes the classes needed to get the JVM up and running. On top of configuration there are profiles, which add the functionality needed to get applications running. For CLCD there are currently two profiles, Mobile Information Device Profile (MIDP) and Personal Digital Assistant (PDA), whereas in the case of CDC all the profiles are built by extending the Foundation Profile. Personal and RMI Profile are the two options for CDC currently. With Personal Profile the CDC is compliant with the PersonalJava specification [1]. RMI Profile adds the support for Java RMI to the CDC. In this paper we concentrate on CDC and the Foundation Profile. CDC includes CVM, which can be thought as being a small-footprint version of Java 2 virtual machine. For a complete runtime environment, CDC uses the Foundation Profile, which is a set of Java APIs that provide the same APIs as the Java 2 environment. Sun Microsystems, Inc has released the CDC specification [2], a technical white paper [3] and a reference implementation [4], which we will use as main sources of information in this paper. In these references Sun claims many optimizations in both performance and footprint. In this paper we take a practical look at CDC by running various test cases on it and thereby verifying if the claims hold. Various aspects of CDC are studied, such as static and dynamic memory footprints and runtime performance. We also compare CDC to Java 2 and Java 1.1 standard editions. Java 2 is chosen, because according to Sun, CDC should comply with Java 2, except Swing-classes.

3 21 MIDP PDA Personal RMI Foundation Profile libraries CLDC Libraries KVM CDC Libraries CVM Configuration libraries JVM Operating System OS Figure 1 J2ME architecture with configurations and profiles For this reason, we do not take Swing into account in our tests. Java 1.1 on the other hand is taken into account, because most of the today s JVMs on handheld devices are based on Java 1.1 functionality [1, 5, 6]. Furthermore, the reference implementation currently supports only Linux and VxWorks 1. Of the target devices for CDC, Compaq ipaq H3600 series handheld devices are currently one of the few that run Linux and could be considered as a real target device for CDC 2. This paper is organized as follows. In Section 2 we give a more detailed introduction to CDC. Section 3 points out some aspects of running Java on small devices. Section 4 discusses the differencies between CDC, Java 1.1 and Java 2. In Section 5 we analyse the CDC as an option for a Java environment on small devices. Finally, Section 6 concludes this paper. 1 VxWorks is a realtime operating system from WindRiver, who is specialized in embedded platforms, for instance PDA devices. 2 For more information on running Linux on Compaq ipaq, see

4 22 2 CONNECTED DEVICE CONFIGURATION CDC is a Java Community Process effort (JSR-36) that has standardized a portable, Java technology building block for consumer electronic and embedded devices. The CDC standardization effort was the result of a collaboration of companies representing the consumer electronic industry. CDC contains the full Java 2 Platform virtual machine (CVM) and the minimal class libraries and APIs to get the system up and running. For an application to do useful work, the Foundation Profile is required. It includes all the class libraries and APIs that are designed for consumer devices. However, the Foundation Profile does not include GUI classes. Thus, other profiles would be required if an application a GUI. Personal Java applications can be easily ported to CDC. Also, CLCD-compliant profile is upwardly compatible with CDC. Target devices for CDC typically have around two megabytes or more of total memory available for the Java platform, including both RAM and ROM. Target devices for CDC typically contain connectivity to a network, often a wireless one with a limited bandwidth. 2.1 C Virtual Machine CVM is a small-footprint virtual machine incorporating the latest in JVM technology, while remaining suitable for the embedded world. According to Sun, it is very portable, RTOS-aware, deterministic, and space-efficient. It allows devices to map Java threads directly to native threads, and can run Java classes out of ROM. It combines these embedded-friendly features with advanced VM features such as a precise memory system, generational garbage collector, and fast Java synchronization. Finally, CVM supports all Java 2 Platform, version 1.3, JVM features and libraries for security, weak references, JNI, RMI, and JVMDI. The technical white paper introduces a set of features, which are claimed to make CDC suitable for small devices. These are collected in Table 1. In Section 4 we will take a deeper look at these features by running various tests in order to find out, how these features are fulfilled. 2.2 CDC Classes In general, CDC contains the minimal Java packages from Java 2 SE to build and run the JVM. These packages are: java.lang java.util java.net System classes. Underlying Java utilities. UDP Datagram and File I/O. java.io Java File I/O. java.text Minimal support for I18n.

5 23 Table 1 CDC features [3] Feature Improved memory system RTOS-aware Fast synchronization Preloaded classes Native threads Small memory footprint Efficient stack usage Clean shutdown and restart Pluggable architecture Description Incorporated exactness, small average GC pause times (generational GC algorithm), separation of JVM from the memory system and pluggable GCs. CDC is implemented in C, with very little Assembler. It includes a well-documented porting layer and multiple porting options leaving the porter only the bare minimum of porting work. Most of the synchronization operations are performed with just a few machine instructions, without consuming additional OS-level lock resources. Java classes can be ROMified resulting in better startup time and less fragmentation. Performs internal synchronization and GC correctly in presence of preemptive native threading. Memory footprint for classes is about 40 percent compared to Java 2 SE and around 17 percent compared to Personal Java. CVM features deterministic and reduced-footprint native stack usage, achieved by careful static analysis of the JVM code. All allocated memory is guaranteed to be freed and all threads are guaranteed to be stopped. CVM provides extensible and well-defined interfaces making it easy to add new features to CVM. java.security Minimal fine-grain security and encryption for object serialization It should be noted that CDC as well as the Foundation Profile make corrections to the Java 2 SE API library by removing all noncritical, deprecated APIs. 2.3 The Foundation Profile The Foundation Profile is a set of Java APIs that, together with the CDC, provides a complete application runtime environment for small devices. CVM is the engine for the Foundation Profile libraries. Typical implementations use a subset of the Java 2 SE platform, depending on the application area.

6 24 In general, the Foundation Profile contains the complete Java packages from Java 2 SE, except that the GUI dependencies on java.awt are removed. The basic packages from CDC are modified in the Foundation Profile as follows: java.lang java.util java.net Full java.lang.* Java 2 SE package support. Adds full Zip support and some utilities (e.g. Timer). Adds TCP/IP Socket and HTTP connections. java.io Full java.io.* Java 2 SE package support for Java I/O. java.text Full java.text.* Java 2 SE package support for I18n. java.security Adds code signing and certificates.

7 25 Table 2 Small device categories Operating System Java Environments Example devices Windows CE/Pocket PC Personal Java (CDC), proprietary JVMs Casio Cassiopeia E-125, HP Jornada 500 Series PalmOS J2ME CLCD Palm m505, Motorola Accompli 008 Linux Java 1.1, Java 2, CDC, Kaffe Compaq ipaq H3630, VTech Helio Others, e.g. and Nokia Symbian Personal Java, own clean-room implementations Nokia Communicator 9210, Psion Series 5mx 3 JAVA ON HANDHELD DEVICES Installing and running Java environment on handheld devices introduces problems in terms of the limitations of the devices. The main limitations that mainly relate to Java are the limited processing power, limited amount of Read Only Memory (ROM) and Random Access Memory (RAM) 3. Optionally, if graphical user interaction is considered, the small screen size and resolution, and alternative input methods, such as touchscreen, may pose some additional constraints to the Java environment and the applications running in it. The small devices can be divided, based on the operating system, roughly into four categories, which are shown in Table 2. Windows CE/Pocket PC devices usually use commercial JVM implementations or free Personal Java reference implementation from Sun. Personal Java will merge as Personal Profile on top of CDC under the J2ME family in the future. The problem so far is that Personal Java is based on Java 1.1, whereas CDC is based on Java 2 and has removed all deprecations. Palm devices running PalmOS are usually only able to run J2ME CLCD due to their limiting processing power and amount of memory. Linux offers the widest range for choosing Java environment. Compaq ipaq H3600 family is an example of a handheld Linux machine. In this machine it is possible to run both Java 1.1, Java 2 and Kaffe, which is a clean-room implementation of Java 1.1-compliant virtual machine. Sun Microsystems, Inc. has also demonstrated CDC-port for ipaq Linux. Unfortunately we do not have this port available for testing yet. The fourth category consists of devices that run either some own clean-room implementation or some implementation of Personal Java specification. 3 High-end small devices usually have 64MB of RAM and 16-32MB of ROM, on which the operating system and pre-installed application software are installed.

8 26 4 COMPARING CDC TO JAVA STANDARD EDITION CDC is meant to be a scaled-down version of Java 2 environment. Java 1.1 on the other hand is mostly supported Java environment on the handheld devices, because almost all the implementations follow either Java 1.1 directly or implement the PersonalJavaspecification. In this section we introduce a set of test cases which are used to test the CDC and compare it to Java 2 and 1.1 standard editions. We inspect the static and dynamic footprint of the JVMs, performance and compliance. In the tests we don t take the Swing-classes into account, because they are not supported implicitly in Java 1.1 and at all in CDC. Also, we run Java 2 in interpreter-mode, because JIT (Just-in-time) compilation is not available in Java 1.1 and CDC. We tried to select the tests so that they reflect the key features of Java language as much as possible in terms of performance. To compare the performance aspects between Java 2, Java 1.1 and CDC, we implemented a test set, which consists of the following test cases: 1. Object creation 2. Threads and synchronization 3. Garbage collector performance and pause times 4. I/O (Input/Output streams) 5. Java Collection classes 6. Real application In object creation test case we simply measure the time needed to create a large number of objects. Threads and synchronization test case creates a set of objects, each making a method call to a synchronized method. Java reflection test case measures the overhead introduced when creating objects using Java reflection API instead of creating an object traditionally. In garbage collector s case we only study the GC algorithm used in CDC, because the tracing support in CDC could not provide us with the timestamp information so that we could have inspected the pause times in detail. I/O test case measures the time to read and write data, with different kinds of streams, to the disk. In Java Collection classes test case we compare the performance of Java Collections classes. Finally, the real application test case tests the collective effect of the functions from all of the previous test cases, excluding the Java reflection. In this test case we run a Java-based agent platform called MicroFIPA-OS [10]. The test environment we used in our tests is specified in Table Static footprint Static footprints are measured on both JVM executables and class libraries. Java 1.1 and 2 include AWT GUI libraries, but not Swing-libraries, which in CDC are not included. This should be taken into account when comparing class libraries

9 27 Table 3 Environment used in tests Hardware Model Processor Memory Toshiba Portégé 7140CT Laptop Intel Pentium III (500MHz) 192 Mb Software OS Linux Java2SE Java 2 SE Version Java 1.1 SE Java 1.1 SE Version CDC J2ME Version J2ME CDC 1.0 footprints. In CDC s case the size of the CVM build depends on the compilation options. In our measurements the CVM has the Foundation Profile support built in. Without Foundation the size of the executable is about 400 Kb smaller. The results are shown in Figure 2. CDC provides an interesting feature of allowing Java classes to be compiled in compact form using CodeCompact tool that comes with the distribution. The result object file from this tool can then be statically linked with the JVM as preloaded class. We did not test this feature though. JVM Executable Footprint Class Library Footprints Bytes Bytes Java 1.1 Java 2 CDC Java environment 0 Java 1.1 Java 2 CDC Figure 2 Static footprint sizes 4.2 Dynamic footprint Dynamic footprint sizes are measured by running the real application, MicroFIPA- OS, and acquiring the allocated memory from Linux process table. Therefore, the

10 28 measurement includes allocated memory for both JVM and the application s classes. The results are shown in Figure 3. Java 1.1 clearly seems to have the smallest footprint, whereas Java 2 with green threads is quite equal to CDC, about 6Mb. But being so high, having more than one JVM running on a handheld device seems unrealistic. Dynamic Footprints Bytes Java 1.1 Java 2 green Java 2 native CDC Java environment Figure 3 Dynamic footprint sizes of MicroFIPA-OS 4.3 Performance Caffeine Benchmarks. CaffeineMark [7] is a benchmark program, which measures the performance of the execution of Java programs. The CaffeineMark uses 9 subtests to measure various aspects of Java virtual machine performance. In Figure 4 the CaffeineMark 3.0 benchmark results for the target devices are presented. It should be noted that because CDC does not support GUIs, we used embedded-mode of the CaffeineMark, which does not measure the performance of Java graphical libraries. The results show that Java 1.1 and Java 2 are superior over CDC. This is quite surprising, because we believed that CDC would be as performative as Java 2. Furthermore, we found out that there was no single subtest in CaffeineMark that performed much poorer than the others thus being able to drag the overall score down; instead, every test performed equally poorly as compared to the subtest results of Java 1.1 and 2. The reason might be in some caching scheme that could be applied in Java 1.1 and 2, but not in CDC. However, we could not verify this and the real reason for performance difference remains unsolved Object creation. In object creation test case we create objects in a loop and measure the time spent on creating the objects. To get a better understanding on the scalability, we use run the loop for 1000, , and times. The

11 29 CaffeineMark 3.0 Benchmarks ,7 901,5 Benchmark ,3 Java 1.1 Java 2 CDC Java environment Figure 4 CaffeineMark 3.0 Benchmark results. Larger bar implies better results results are shown in Figure 5. All the measurements represent an average of ten test rounds. It should also be noted that the x-axis is not linear. It is quite surprising to see that CDC performs worse than Java 1.1 and 2. With smaller amounts of objects the performances are quite equal, but with larger amounts the CDC starts to become slower than the others. It must be kept in mind though that in handheld devices we cannot even create large amounts of objects because of the limitations in available memory, but in general, CDC does not seem scale well with large loads of objects. One reason could be that CDC is optimized for small amounts of objects. It might also be that the reference implementation from Sun simply is not optimized at all Threads and synchronization. Threads and synchronization test case inspects the effectiveness of handling large amounts of threads and synchronization between them. In this case we create 10, 100 and 1000 threads and let them all call a shared synchronized method. CDC supports only native threads, i.e. the Java threads are mapped directly to threads provided by the operating system. However, in Java 2 there is a possibility to choose from native and green threads. Green threads are scheduled by the JVM itself, and thus are more lightweight in terms of overhead in creation and context switching. Therefore, in this test case we inspected both native and green threads in Java 2. Java 1.1 only supports green threads. The results are shown in Figure 6. As in the previous test case, these results are averages of ten test rounds and in the figure the x-axis is not linear. The results show that native threads in Java 2 cannot match the performance of the native threads in CDC and green threads in Java 1.1. This is understandable, but also encouraging for the CDC, because its implementation of threading seems to work a lot faster than in Java 2. This is inline with the claims that Sun makes in their specifications.

12 30 Object creation Time (ms) Java 1.1 Java 2 CDC Nbr. of objects Figure 5 Object creation times Threads and synchronization Time (ms) Java 1.1 Java 2 green Java 2 native CDC Nbr. of threads Figure 6 Thread execution and synchronization measurements Garbage collector performance and pause times. Garbage collection has been critizised for two reasons: low throughput and high latency. In other words, collection will either slow down the end-to-end performance of their systems, or induce long collection pauses, or both. Generational garbage collection technique can address both performance problems. They split the heap into generations according to object age. Concentrating collection activity on the young generation increases throughput, because (in most programs) young objects are more likely to be garbage, so more free space is recovered per unit of collection work. Since the young generation is

13 typically small relative to the total heap size, young-generation collections are usually brief, addressing the latency concern. However, objects that survive a sufficiently large number of young-generation collections are considered long-lived, and are promoted into an older generation. Even though the older generation is typically larger, it will eventually be filled and require collection. Old-generation collection has latency and throughput similar to full-heap collection; thus, generational techniques actually only postpone, but do not solve, the problem [8]. CDC supports generational GC algorithm by default. We believe that the generational GC is chosen because it fits into the real-time environments because it is interruptible and can therefore guarantee a upper bound for GC pause time. However, the use of generational GC techniques in embedded devices has been critizised to some extent [9]. First of all, it has a bigger footprint than simple mark-and-sweep collectors. Also, because it is a copying collector in its nature, meaning that the Java heap is compacted once in awhile to defragment the heap, there has to be two logical heaps. It should be noted though that simple reference counting has its disadvantages too in this context, because it requires that every instance of a class includes a reference field. Thus, it could be summarized that generational garbage collectors work best in real-time environments and when the amount of runtime objects is large, whereas simple reference counting suits better to environments, where there are only a few runtime objects and real-time requirements do not have to be met. We believe that this is the reason why CDC supports pluggable garbage collectors, so that if the default one does not fit in target application environment, a more suitable GC algorithm can be used instead I/O (Input/Output streams). In this test case we measure the performance of three different streams: FileReader, DataInputStream and ObjectStream. With FileReader we read an two-kilobyte ASCII file from the disk. The same file is read also using DataInputStream. The difference between these two is that with FileReader we read Java Strings whereas with DataInputStream we are dealing with bytes. ObjectStream is used for testing the Java serialization by first writing object to and then reading them from a ObjectStream. The results are shown in Figure 7. All the test results are averages of ten test rounds. There are a few points to raise about the results. First of all, DataInputStream performed poorly because reading was not buffered. This explains the general performance gap between FileReader and DataInputStream. Secondly, in FileReader and ObjectStreams CDC performed well as compared to Java 1.1 and 2. We believe that the reason for this is that in CDC both FileReader and ObjectStreams use rewritten native code. This seemed to especially boost the performance in ObjectStreams, while the differencies in FileReader and DataInputStream are not significant Java Collections. Java Collections are tested using three-step approach. The results are shown in Figure 8. First we create a large LinkedList and fill it with Integer-objects. This is labelled in the figure as Creation. Secondly, we iterate the 31

14 32 Input/Ouput Streams ,2 Time (ms) ,3 19,9 15,5 12,4 5,5 3,7 4,1 2,6 Java 1.1 Java 2 CDC Java environment FileReader DataStream ObjectStream Figure 7 Java I/O measurements list through using Iterator interface and remove every second element from the list. This is labelled as Iteration in the figure. Finally, we sort the list into ascending order by converting it first to a array of objects and then using Arrays.sort()-method. This is labelled as Sorting in the figure. It should be noted that because Java 1.1 does not have the Collections classes built in, we used an external Collections-package for Java 1.1. The results are shown in Figure 8. These test results are averages of ten test rounds. The results show that Java 1.1 beats both Java 2 and CDC in every case, although the most significant difference is in the object creation phase, which we already inspected in Section CDC performs most poorly in every case, but the difference in the cases of iteration and sorting is not significant as compared to Java 1.1 and Real application. In the final test we run a MicroFIPA-OS agent platform, which is a middleware for running software agents on handheld devices [10]. Because it does not require a GUI, it suits well for our testing purposes. The test case consists of starting up the agent platform, which involves creating a large number of objects, firing up multiple threads and using sockets. The results of this test case are shown in Figure 9. Again in this test case the results are averages of ten test rounds. It can be seen that when a real application utilizing all features that are tested separately, the performance gap shown in some test cases seem to even out. Although Java 1.1 is still the most performative, the differencies are not significant. 4.4 Compliance We found out that in our tests CDC API was compliant with Java 2 API. The only exception is the lack of GUI classes. If a GUI is needed in CDC, another profile

15 33 Java Collections ,2 Time (ms) , ,9 51,9 39,6 20,2 46,1 23,7 Creation Iteration Sorting 10 0 Java 1.1 Java 2 CDC Java environment Figure 8 Performance of Java Collection classes MicroFIPA-OS Startup ,5 5537,8 5043, Time (ms) Java 1.1 Java 1.2 green Java 2 native CDC Java environment Figure 9 Performance of MicroFIPA-OS agent platform together with Foundation must be used, or the GUIs can be implemented in some other language allowing interaction between it and CDC code. Java 1.1 on the other hand is not upwards compliant with CDC meaning that in CDC it is possible to run Java 1.1 code, but not vice versa. For porting CDC code on to Java 1.1 the missing classes must be replaced with external class libraries. For instance, the Java Collections are available as a separate package for Java 1.1 providing the same API as in Java 2. The developer only needs to restructure the imports clauses in Java code and recompile.

16 34 5 ANALYSIS CDC turned out to be superior in footprint sizes as compared to Java 1.1 and 2. According to Sun the CDC is targeted to machines having around 2Mb of memory. We found out that with Foundation Profile compiled in, the footprint size of the CVM is about 2.4Mb. But the fact is that without Foundation Profile the CDC is quite useless. When we take CVM footprint together with the footprint of Foundation classes, we are not talking about 2Mb anymore. Furthermore, the GUI classes are not included. Although the target devices for CDC usually have 16Mb of ROM, we think that, with Foundation and some GUI library, consuming almost half of that amount to just have a Java environment on the device is not acceptable. After all, the Java environment being as a middleware is there only to allow applications to be run. Having said this we must of course remember that the implementation we used is the first implementation available, and cannot be considered as a final product. Therefore, we can expect optimizations on various aspects in further releases. Furthermore, all our experiments are based on running CDC on laptop Linux, which might not reflect the situation with for instance CDC on Compaq ipaq running Linux. Generally the claims that Sun makes about CDC hold pretty well. Threading and synchronization works really fast, remembering that the threads in CDC are native threads. Native threads in CDC are almost as fast as green threads in Java 1.1 and 2. However, one interesting point about native thread support is the justification for supporting them. It is well known that green threads are inherently faster to create and to change context, so why not support them in CDC? We believe that the use of native threads is well justified in multiprocessor environment, where each thread can be physically assigned to run on a separate processor thus having a real gain in performance. But in single processor environments, which the handheld devices currently are and we think will be in future also, having green threads would sound a more reasonable choice. I/O streams, especially object streams are really fast in CDC. Reading a file and reading/writing objects to an object stream is even faster than in Java 1.1. Object creation, especially when creating a large number of them, turned out to be slow in CDC. Speaking for CDC it must be noted that the amounts of objects we created in our test case is practically impossible in real handheld device due to the limited amount of memory. Pluggable garbage collector scheme is an advantage of CDC over the other Java environments. If the default GC algorithm does not suite the target application s requirements, the algorithm can be changed. What could be argued is the choice of generational GC algorithm as the default one. In the realtime environments it is justified, but in non-realtime environments a simpler algorithm might be better. Furthermore, simple reference counting is said to be more effective over the generational algorithm, when the amount of garbage is small. Software design for resource-constrained systems promotes the reuse of objects thus trying to avoid object creations, which turned out to be a heavy operation in Java, and especially CDC. Thus, with a good-designed application the amount of garbage should be low, and therefore a simple GC algorithm could be used.

17 6 CONCLUSION AND FUTURE WORK In this paper the CDC of J2ME was studied and its applicability to handheld devices was analysed by running several tests and comparing it with Java 1.1 and Java 2. The tests included measurements for static and dynamic footprints and performance in terms of object creation, threading and synchronization, I/O streams, Java Collections and a real application called MicroFIPA-OS. In addition we studied the garbage collection implementation in CDC. We found out that although there were some significant differencies in performance in some test cases, it seems that when running a real application, the performance differencies in separate test cases even out. Although CDC is designed to be run in handheld devices having limited amount of memory and CPU power, its performance is not any better than Java 2 or Java 1.1. What is good in CDC is the small total static footprint size as compared to Java 1.1 and Java 2. The big disadvantage is that the with CDC supplemented with Foundation Profile it is not possible to develop GUIs. We think that GUIs are essential method for user interaction especially in handheld devices, where the limited ways for user interaction basically rule out for instance the use of written text input. Without a point-and-click user interaction the use of a handheld device is not feasible. Thus, when a GUI is needed and Swing is not required, JDK 1.1 seems the best choice for handheld devices in terms of runtime performance. However, in the future there will be optimized releases of CDC, especially for real handheld devices, and additional profiles on top of CDC providing GUI classes. These will most probably make CDC the most appropriate Java environment for handheld devices. In the future we will port the CDC on to Compaq ipaq device and perform the tests in order to see, how the CDC performs in real device. 35

18 36 References [1] Sun Microsystems, Inc. PersonalJava Specification version 1.2a Available at: [2] Sun Microsystems, Inc. JSR J2ME[tm] Connected Device Configuration Specification - Final Release Available at: [3] Sun Microsystems, Inc. Connected Device Configuration (CDC) and the Foundation Profile. Technical Whitepaper Available at: [4] Sun Microsystems, Inc. Connected Device Configuration Reference Implementation Available at: [5] Insignia Solutions. Insignia - homepage Available at: enabled.htm. [6] NSICom. CrEme[tm] - The Java[tm] Enabler for Windows CE Available at: [7] Pendragon Software Corporation. CaffeineMark 3.0 homepage Available at [8] Detlefs David and Printezis Tony Generational Mostly-concurrent Garbage Collector. Sun Microsystems Research. Technical Report, TR Jun [9] Petit-Bianco Alexandre No Silver Bullet - Garbage Collection for Java in Embedded Sytems. Red Hat Embedded Documents (Cygnus). Technical Whitepaper. Jan Available at: nosb/. [10] University of Helsinki. MicroFIPA-OS - Small footprint extension to FIPA-OS Available at: