Java in Ubicomp. Mikko Honkala HUT, Telecommunications Software and Multimedia Laboratory. Abstract

Transcription

1 Java in Ubicomp Mikko Honkala HUT, Telecommunications Software and Multimedia Laboratory Abstract This paper describes the use of Java language in embedded devices, such as handhelds, digital TV set-top boxes, and even smart cards. The variety of devices offering the Java platform has transformed the original Java mantra write once, run anywhere into one size doesn t fit all. 1 INTRODUCTION Developing applications targeted to multiple systems is traditionally very hard. C and its successor C++ are well defined languages, but developers still have to maintain a lot of compatibility code, if they want to run their applications in different systems. Traditionally, different systems has meant Windows and Linux, but today the variety of those environments is great; There are new handhelds with proprietary operating systems and most web services must run on different operating systems. Code versions for different systems need to be maintained at development time, but also distribution is difficult: the C program has to be compiled for all target systems. (Hansmann, 2001) Why would every software project have to write their own compatibility code? With Java, they don t have to. Java lets the developer develop for an abstract virtual machine that is platform neutral. In addition, Java includes a huge class library, that helps the development work and reduces the need for outside libraries. As a language, Java is simpler than C++, and in addition it includes a garbage collector, which removes the programmer from the burden of memory management (Hamilton, 1996). This is why Java is a good choice for Ubicomp (or Pervasive Computing), where the profiles of devices vary a great deal. 2 BACKGROUND This chapter gives a brief background on the Java environment. Java is not solely a programming language, it consists of different modules, of which most notable are the Java language, the Virtual Machine, and the class libraries. 2.1 Java Language Characteristics Java language is an object oriented programming language with a syntax similar to C 1

2 and C++, only simpler (Hamilton, 1996). The most notable difference is the lack of pointers and the memory handling tools. The reason is the garbage collector that takes care of the objects in the memory that are no longer needed. Java also has some advanced features, not found in C++, such as Interfaces and build-in thread and sychronization support. 2.2 Java Virtual Machine At development time, the Java source code is compiled into abstract byte code, capable of running in all Java environments. Each environment supporting Java has a Java runtime environment (JRE) consisting of the Java virtual machine (JVM) and the class libraries. The JVM interprets and executes the byte code on the fly (Hansmann, 2001). Most JRE s also have a Just-In-Time (JIT) compiler, which compiles the byte code into fast native code before executing it. (Cramer, 1997). 2.3 Java Class Libraries The Java language and the JVM assure that the Java programs are portable and their execution environment is secure (Cramer, 1997). But this is not by far the only thing that Java has to offer. Java has a quite large build-in class library that frees programmers for writing support code for, for instance, Hashtables and socket access, every time they need them in a program. This also reduces the size of Java programs, since the class libraries are not needed in a distribution, since the Java environment is guaranteed to have them. 3 JAVA EDITIONS The networking features and the platform independence have made Java a popular technology in the internet applications. Applets and servlets are part of many advanced web sites. Most browsers can execute Java byte code as do the web servers. Since the diversity of devices is increasing, Java s platform independence becomes a key feature. Many handhelds, set-top boxes, smart cards, and other embedded devices provide a JVM. On the other hand, the number of Java-capable platforms is increasing, while the number of features in the Java programming language and class library are also increasing. Because of this, Sun has defined many different flavors of the Java environment. 3.1 Java 2 based editions Table 1 lists the different editions, while Figure 1 depicts the editions in respect to each other. The standard environment is the Standard Edition. This is, what is found in desktop and in Web browsers. In Web servers, a larger Enterprise edition is used. The Java 2 Micro Edition is meant for small machines, such as mobile phones, and the Java Card is for smart cards. Table 1. Java Editions 2

3 Java 2 Standard Edition (J2SE) Java 2 Enterprise Edition (J2EE) Java 2 Micro Edition (J2ME) Java Card The standard client edition Meant to be used in a server For pervasive devices For smart cards Server W orkstation Pervasive devices J2ME J2EE J2SE Car profile TV profile PDA profile J2ME Core Libraries Phone profile VISA Smart Card JavaCard Java Programming Language Figure 1: The different Java editions 3.2 Java 2 Standard Edition (J2SE) The Java 2 Standard Edition (J2SE) is the default language profile for workstations and small servers. It includes all the core packages (applet, awt, beans, io, lang, math, net, rmi, security, text, and util) plus javax.swing and org.omg.corba packages) 3.3 Java 2 Enterprise Edition (J2EE) The Java 2 Enterprise Edition offers addition features on top of the standard edition. It is meant for large scale servers, such as web servers. Some extra features of J2EE are servlets, JavaServer Pages, JDBC, Java Message Service, Java Naming and Directory Interface, Java Transaction, JavaMail, XML, CORBA, and Enterprise Java Beans. The Software Development Kit is available. The next version 1.4 of the JDK will have a new JIT compiler, called Java Hot Spot Server VM, optimized for server use. 3

4 3.4 Java 2 Micro Edition (J2ME) The J2ME is meant for restricted devices, such as handhelds and digital television. In order to meet the peculiarities of different device classes, J2ME introduces profiles and configurations, which specify language and environment subsets for different groups of devices. Chapter 4 describes the different flavors of the Java 2 Micro Edition. 3.5 Java Card The Java Card is the smallest java edition available. It is meant to be used with smart cards, with very limited memory and processing power. For example, there is no string support in the Java Card edition. The card Virtual Machines are provided by the smart card manufacturers, and they are shipped directly on the card ROM (Hansmann, 2001). 3.6 Java 1.1 based editions Personal and Embedded Java are predecessors of the Java 2 Micro Edition. They have the same motivation and design goals as J2ME, but are based on an older version of the JDK (1.1). Personal Java will be migrated into J2ME as a Personal Java profile, while Embedded Java will probably not be included in J2ME. 4 DIFFERENT FLAVOURS OF MICRO EDITION Because of the varying nature of small scale devices, the same Java environment does not fit well to every type of device. Because of this, Sun has defined the Java 2 Micro Edition to be flexibly redefined for each class of devices. J2ME introduces profiles and configurations, which specify language and environment subsets for different groups of devices. The environment, which consists of the virtual machine and a set of APIs, is called the Configuration, while the layer on top of the configuration, is called a profile. There are different kinds of small scale virtual machines, such as KVM and CVM. Table 2 defines the terms used in this chapter. Table 2. Definitions of J2ME terms KVM CVM Configuration A compact Java virtual machine whose size is measured in the hundreds of kilobytes. A Java virtual machine larger than the KVM that is intended for use on emerging, next-generation consumer devices Either the KVM or CVM combined with a minimal set of APIs that define the expected features for a broad category of consumer devices. A layer on top of a configuration that adds additional APIs to make a complete toolkit for a specific type of consumer device. 4

5 Figure 2 depicts the relations between the profiles and configurations in J2ME. Personal MID Handheld Configuration CDC Libraries CLDC Libraries JVM KVM CVM Figure 2: Configurations and s in J2ME 4.1 Configurations The J2ME architecture is designed with flexibility and future growth in mind. The basic building block of a J2ME runtime environment is a configuration. A configuration consists of a virtual machine that implements some portion of the Java language and virtual machine specifications, and a minimal supporting set of class libraries and APIs. It may seem redundant to say libraries and APIs, but APIs include things like the Java Native Interface (JNI), which are not implemented by a class library or defined by the Java Language Specification (JLS). Additional features for specific types of devices can be built on top of a configuration, but each configuration defines a base level of functionality for a class of devices. (Savarese, 2001) Currently, there are two standard configurations (Moreira, 2001, Savarese, 2001) but more may be defined in the future provided a new class of devices warrants it: Connected Limited Device Configuration (CLDC) - addresses devices with a significant resources limitation, such as cell phones or Pagers. Connected Device Configuration (CDC) - addresses devices with a higher set of physical resources, like PDAs or Set-Top Boxes. CDC requires full support for both the JLS and JVM Specification. If you layer enough APIs on top of it, you'd wind up with J2SE plus some extra CDC-specific classes. Therefore, the main concern when porting J2SE code is one of which core classes you can assume are available. The major configurable API s are in the java.io, java.net, and java.security packages. 5

6 4.2 s In addition to the core Micro configurations, the J2ME includes the possibility to define different profiles for a certain set of devices. Examples of profiles include the Mobile Information Device (MIDP) and PDA. The Mobile Information Device (MIDP) is a set of JavaTM APIs which, together with the Connected Limited Device Configuration (CLDC), provides a complete J2METM application runtime environment targeted at mobile information devices, such as mobile phones and entry level PDAs. The MIDP specification addresses issues such as user interface, persistence storage, networking, and application life cycle. PDA provides user interface and data storage APIs for small, resource-limited handheld devices. It is based on the Connected, Limited Device Configuration (CLDC). PDA s have the following characteristics: No less than 512KB total memory (ROM + RAM) available for Java runtime and libraries, and no more than 16 MB. Limited power, typically battery operated. User interfaces of varying degrees of sophistication, but having at least: displays with a total resolution of at least 20,000 pixels, a pointing device, and character input. This profile, in conjunction with the "J2ME Connected, Limited Device Configuration," enables application development for handheld devices used as personal digital assistants. Other profiles that are currently being defined include: J2ME Foundation a base profile for use in implementing non-gui networked devices; built on CDC J2ME RMI provides RMI support for J2ME CDC-class devices; requires CDC and Foundation J2ME Personal Basis provides application environment for networked devices with basic level of graphical presentation; requires CDC and Foundation J2ME Personal is the next generation PersonalJava environment; based upon Personal Basis (and thereby, CDC and Foundation ) Java Game 6

7 4.3 The K Virtual Machine (KVM) A JVM is the foundation for Java technology. The virtual machine handles related tasks such as managing the system's memory, providing security against malicious code, and managing multiple threads of program execution. In order to meet the market need for a very small footprint Java implementation, the KVM was designed to overcome three key technical challenges: reducing the size of the virtual machine and class libraries themselves, reducing the memory utilized by the virtual machine during execution, and allowing for components of the virtual machine to be configured to suit particular devices (e.g., by allowing pluggable garbage collection). The features of the K virtual machine are (Sun Microsystems, 2001): Reduced VM Size - the K virtual machine is currently only K of object code in its standard configuration, depending on target platform and compilation options. Reduced Memory Utilization - In addition to the K virtual machine's small object size, it requires only a few tens of kilobytes of dynamic memory to run effectively. Because of the reduced VM size and memory utilization, even with total memory available of only 128K the K virtual machine enables useful Java technology-based applications to run on a device. Performance - the K virtual machine is able to run effectively on 16 bit processors clocked as low as 25 MHz, and can scale smoothly up to much more powerful 32 bit processors. Portability - although implemented in native code for extra performance, the K virtual machine has a highly portable architecture that reduces system dependencies to a minimum. Even multi-threading and garbage collection have been implemented in a completely system-independent manner, enabling speedy porting to any host platform. 4.4 The C Virtual Machine (CVM) CVM is A Java virtual machine larger than the KVM that is intended for use on emerging, next-generation consumer devices. The CVM virtual machine is a Java 2 virtual machine designed for devices needing the functionality of the Java 2 virtual machine feature set, but with a smaller footprint. CVM is designed to meet the market need for emerging, next generation consumer electronic and embedded devices. Devices using CVM are typically compact and connected consumer-oriented devices. 4.5 Development Tools for Small Java Editions Even that the Micro Java specification is quite new, there is already many development environments and tools for the Small Java Editions. Table 3 lists some Java development tools for pervasive computing (Day, 2001). Some of these tools include an 7

8 target device emulator, where the application can be previewed in the correct target environment. Table 3. Micro java development tools (Day, 2001)! "!"# $ %&' & ( )& &&!& # ) - # 0 1 #!!$%&' ))!* +,-., /!*, $ 0*12/- *13 $ $456 / 7/ 9 "1 2 :1 #" $ # *) +,. - / + 2$0 1$/ 0 1 %& 3 " 4" )*) +, $ %5)0 )/ $% 5)6/ '8& $ $7%+ //7 *7"1)1 )+/2 1, '8& )$ + & ).) 2/$/8; /8 & & < /8 91 2/ $ 62( * 8, 21 '1! &%+//=5) & )#>) 1+/# $/ & 022 ( >! )/ & 62 %5 ) )/. / / ) & 022 ( %.. 2/# & +/% # &/; &?# 8

9 7,! 8 " $/4" 0 1 & $$0 1 2/$/(;& ; 1 " /& ; 1 5 PROBLEMS WITH THE CURRENT ENVIRONMENTS The different flavors of the Java environment has made writing portable Java somewhat more difficult. Even though the early days saw many platform-specific features, it was largely possible for most projects to maintain a single source base that would work for all platforms that is, if you ignored the difficulties in creating debug and test versions of Java code caused by the lack of conditional compilation support. There have been portability problems before, because of different revisions of the JDK, but many projects transitioned smoothly to the latest JDK without having to support multiple JDKs in great part because of Java featuring only on the server. Had Java been a success on the desktop, the story would have been far different, as evidenced by the major portability and code maintenance dilemmas that were introduced developers who bought into applets. (Savarese, 2001). 5.1 Performance JIT compilers can provide dramatic performance improvements for programs, where the vast majority of execution time would otherwise be spent interpreting bytecodes. Because JIT compilers do not address the performance of other aspects of a virtual machine, programs that include extensive use of synchronization, memory allocation, and native methods may not run much faster. While a JIT compiler is essential for highperformance JVM implementations, it is not a complete solution. (Cramer, 1997). Garbage collection feature of Java eases the task of memory handling from the programmer point of view, but it also makes Java programs a little less efficient. New garbage collectors for different kind of profiles are being developed currently. 6 EXAMPLE ENVIRONMENTS This section describes few example environments for embedded Java, namely SavaJe and JBed. 6.1 SavaJe SavaJe is an interesting Java environment for relatively powerful PDA s, such as the Compaq IPAQ with at least 32 MB of memory. Unlike most embedded Java 9

10 environments, it supports full Java 2 Standard Edition, version 1.3. Because of this, it can run the same applications that are run on the desktop with minimal changes. 6.2 Jbed Jbed Micro Edition CLDC is a full-featured Java virtual machine and development environment designed for PDAs, mobile phones, Internet appliances, and similar devices. It uses an interesting method of Way Ahead of Time (WAT) compilation. This means that all bytecode used for the application is precompiled into native code, for best performance. By precompiling the code can be optimized to suit the needs of the target environment. The code is linked into an image which is loaded onto the target hardware. Jbed Micro Edition CLDC and Jbed for MID support dynamic class loading as a standard Java feature. The user can download classes from the network, via HTTP, PPP or any other preferred protocol. These classes can then be dynamically loaded into the running application, via the classloader and the FastBCC. For mobile phone targets, as well as PDA's, the dynamically loaded classes are compiled on the target and linked into the running application. This enables the downloading of e.g. jar files containing MIDlet suites onto a mobile phone, which will be compiled to native code in order to run with optimum performance. 7 CONCLUSIONS This paper described the use of Java language in embedded devices, such as handhelds, digital TV set-top boxes, and even smart cards. The variety of devices offering the Java platform has made Sun Microsystems, together with the open Java Community Process, to define multiple different flavors of the Java environment, each suited for a particular class of devices. The future of Java in embedded devices looks bright: there are multitude of different embedded hardware platforms and more are coming up. Developing a cross-platform software to run directly on these devices would be a pain, or possibly impossible. That s where Java s strengths materialize. On the other hand, the multitude of different Java environments, configurations and profiles has made Java code less portable than before. The future will show, how well the Java environment adapts to the challenges of the embedded pervasive devices. REFERENCES Cramer, T., et al Compiling Java just in time. IEEE Micro, Vol.17, issue 3, May- June 1997, pp Day, B J2ME Archive. Available at: Hamilton, M.A Java and the shift to net-centric computing. Computer, Vol. 29, Issue 8, Aug. 1996, pp

11 Hansmann, U., et al Pervasive Computing Handbook. Springer. Moreira, P From PersonalJava to J2ME: Some Introductory Ideas. Micro Java Network, May Available at: Savarese, D. F The Great Migration. Java Pro. September Sun Microsystems, The K Virtual Machine. Available at: 11