J2ME ARCHITECTURE AND RELATED EMBEDDED TECHNOLOGIES

Transcription

1 J2ME ARCHITECTURE AND RELATED EMBEDDED TECHNOLOGIES Pradip Lamsal Abstract: Java 2 Platform Micro Edition (J2ME ), a flavour of Java architecture, is aimed at low memory consumer devices, typically less that 2 Mbytes. The architecture consists of three layers: Java virtual machine, configuration and profiles. The virtual machine sits on top of the host operating system. Configuration sits on top of the virtual machine and defines the java language and virtual machine features. Profile, which is the topmost layer, addresses the specific demands of a certain vertical market segment or device family. This paper is an investigation on J2ME specifications and it summarises J2ME architecture and different technologies that are aimed to work with it. 1 INTRODUCTION On the 15 th of June 1999, Sun Microsystems announced a redefined architecture for the Java platform at the JavaOne conference in San Francisco [12]. The architecture was targeted to a wide variety of markets and at the same time expected to provide developers, service providers and device manufacturers extra benefits by making it simpler and specific to the market. The new architecture consists of three editions of Java platforms, each specific for a group of consumers. These are Java 2 Platform, Standard Edition (J2SE); Java 2 Platform, Enterprise Edition (J2EE) and Java 2 Platform, Micro Edition (J2ME). J2SE is targeted for standard desktop and workstation applications and contains all the Java functionality. J2EE is targeted for server side of the network and contains all the functionality required for heavy-duty server systems. J2ME is for small and 1

2 2 memory constrained devices such as Personal Digital Assistants (PDAs) and mobile phones. It has limited Java functionality. Each of the editions comes with a Java Virtual Machine (JVM), Java programming language, core packages and optional packages [12], [6]. The type of the virtual machine and the constraints on the language and the packages depend on the type of the edition. The rest of the paper is organised as follows: Section 2 presents an overview of J2SE and J2EE before J2ME is described in detail. Section 3 describes the J2ME building blocks followed by detail description of configurations and profiles in section 4 and 5 respectively. Section 6 contains other Java embedded technologies and finally section 7 contains some concluding remarks. 2 OVERVIEW OF J2SE & J2EE J2SE is a feature complete development and deployment foundation for building client side enterprise applications [14]. These applications include both web applications such as applets and standalone desktop applications. In addition to standard components of Java platform (JVM, Java programming language, Java packages) J2SE includes java applet viewer, java debugger and other tools. One of such tools found in version 1.3 of J2SE is Java plug-ins. J2SE platform consists of two binary deliverables: Java 2 Standard Development Kit (JDK) and Java 2 Runtime Environment (JRE). JDK consists of Java compiler and is used for application development whereas JRE consists of only those components, which are mandatory in running a Java application or a Java applet. J2EE is a foundation for server side of enterprise application development. Traditionally, enterprise applications are based on two-tier model, generally the client and the server. As the complexity of the applications grow tremendously and the customers demand flexibility, the two-tier applications model started to migrate to a multi-tier application model. In a multi-tier model, the business logic is kept separate from both the client side user interface and the server side system services and it occupies the middle tier(s). The server side system services can be either new services or some existing Enterprise Information Systems (EIS). These middle tiers take the role of middleware and provide services to both the client-tier and EIS-tier without them knowing the details of how these services are implemented.

3 3 Figure 1: Two-tier (a) and multi-tier (b) models [14] J2EE architecture is based on multi-tier model. The client user interface is implemented as the first tier, the EIS tier stores business critical data and the middle tier implements enterprise services such as database access, Common Gateway Interface (CGI) behaviour and implementation of easily configurable and reusable components as multi-tier applications. These multi-tier applications are expected to provide scalability, accessibility and manageability. In order to achieve this model, the J2EE platform provides a lot of standard system services whereas the developers are responsible for implementing business and presentation logic. 3 J2ME ARCHITECTURE 3.1 J2ME devices Increasing demand and use of the consumer electronics are the primary driving forces behind J2ME. This edition of Java platform provides common services from small personal devices such as mobile phones, pagers, PDAs to more traditional consumer electronics such as televisions, VCRs, CD players and game machines. These devices are characterised by the following: They have limited memory, typically 128Kbytes to 2Mbytes. They have limited computational power. They are 16 bit or 32 bit devices. They can be either mobile devices or plug in devices. Mobile devices are most likely to be powered by batteries. Taking these characteristics into consideration, it can be easily imagined that the functionality provided by this flavour of Java platform should be limited and should form the common base across the range of devices. At the same time, it should maintain the core Java technology qualities such as:

4 4 Built-in consistency across products in terms of running anywhere, any time and on any device. Power of high-level object-oriented programming language. Portability of code. Safe network delivery Upward scalability with J2SE and J2EE technology. 3.2 Building blocks J2ME is modular and scalable. It consists of two main building blocks: configuration and profile as shown in Figure 2. Figure 2: Building blocks of J2ME [7], [2] Configuration: A J2ME configuration defines minimum platform required for a group of devices having similar memory and processing capability. A configuration is comprised of a virtual machine, Java language feature and minimum class libraries to support that group of devices. Profile: A profile extends a configuration and addresses the specific needs of a certain device family. It guarantees interoperability within the given vertical device family. A profile comes with domain specific Java class libraries. Both configuration and profile are explained in detail in the following sections.

5 4 CONFIGURATIONS As mentioned in the previous section, a configuration defines a Java platform for a horizontal category or group of devices with similar memory requirement and processing capability. A configuration specifies the following: Supported Java programming language features. Supported JVM features. Supported basic Java libraries and Application Programming Interfaces (APIs). Currently, there are two J2ME configurations. These configurations have different flavours of virtual machines as shown in Figure 3. 5 Figure 3: CLDC and CDC building blocks 4.1 Connected, Limited Device Configuration (CLDC) CLDC is a J2ME configuration. It defines a standard minimum-footprint Java platform for small and resource constrained devices. The devices targeted by CLDC have the following characteristics: 160 Kbytes to 512 Kbytes of total memory available. 16-bit or 32-bit processor. Low power consumption and often operating with battery power. Connectivity to some kind of networked, often with a wireless, intermittent connection and with limited bandwidth.

6 6 CLDC also intends to allow dynamic delivery of Java applications and contents to those devices and enable 3 rd party application developers to easily create applications and contents that can be deployed to those devices. As shown in Figure 3, the CLDC configuration consists of CLDC library, Kilobyte Virtual Machine (KVM) and Java programming language Java language The Java language for CLDC has limited or no support for a set of Java language features that is available in J2SE platform. Nonetheless, it is still complaint with the full Java language specification. The primary features Java language for CLDC does not support are listed below: No floating point support: Java language supporting CLDC does not have floating point support. This is mainly because the cost of support floating point is high and the hardware implementing CLDC does not have floating point support. No finalization: finalize() method is not supported in this version of Java language so that an object cannot be cleaned up before being garbage collected. The CLDC libraries do not have Object.finalize() method and therefore any application built on top of CLDC configuration must not expect finalize(). Error handling limitations: There is full support for exceptions but limited support for error handling in Java language for CLDC. Exceptions represent mild errors, which can be caught and possibly fixed. Errors, on the other hand, represent serious errors and they should not be caught in the program. The main reasons for not supporting full error handling are: recovery from error conditions is very device specific and ordinary programs are not expected to recover from exceptions very easily. For these reasons implementing error handling capabilities according to full Java specification can be expensive and demanding in terms of overhead requirements JVM As with Java language support, the JVM for CLDC devices is also compliant to JVM as specified in J2SE specification but has limited features. The main differences are listed below: Eliminated features: Due to various reasons such as cost of implementing features, library changes or security concerns, the following features have been removed from the virtual machine supporting CLDC. o o No support for Java Native Interface (JNI). JNI allows Java language to use a class library written in other native languages such as C++, visual basic etc. No support for user defined, Java-level class loaders.

7 7 o o o o No support for reflection features. Reflection features allow a Java program to inspect the number and the contents of classes, objects, methods, fields, threads, execution stack and other runtime structures inside the virtual machine. No support for thread groups and daemon threads. Thread operation such as starting and stopping of thread can only be applied to individual thread objects. No support for weak references. An application build on top of the virtual machine supporting CLDC must not expect weak references. Features not supported by Java language (floating point support, finalize method, error handling etc) as mentioned in the previous section. Changes in classfile verification: Like the conventional virtual machine, JVM supporting CLDC is expected to identify and reject invalid classfiles. This operation is very expensive for CLDC devices in terms of memory and computation power. CLDC defines a different mechanism to implement classfile verification. This includes a pre-verifier tool that inserts a special attribute called the stackmap attribute into normal class files. Preverification takes place off-device, e.g., on a server or workstation. Once pre-verification is complete, the classfile is downloaded onto the target device, where in-device verification occurs. This is illustrated in Figure 4. Figure 4: Classfile verification in CLDC/KVM [6] Changes in classfile format and class loading: In order to allow dynamic downloading of Java applications and 3 rd party content CLDC requires the

8 8 distribution of Java applications via compressed Java Archive (JAR) files [6]. These classfiles within these JAR files are expected to have stackmap attributes. This is applicable only to Java applications classified as distributed publicly or represented publicly. If the application is closed or private then the vendor is free to specify any classfile format. The virtual machine that is specified in CLDC configuration is KVM. KVM is a very compact and portable JVM intended for CLDC devices (with 128Kbytes of memory and 16 to 32 bit processors). KVM is a key feature of the J2ME architecture and is the smallest possible complete JVM Java libraries Both J2SE and J2EE contain an extensive collection of libraries that are of great use to developers. These libraries require a lot of memory, which is not available in resource constrained small devices that use CLDC configuration. CLDC contains only a minimum useful set of libraries to support practical application development and profile definition. Selection of libraries is influenced by the fact that CLDC puts a lot of emphasis on connectivity. Therefore, CLDC has some extra libraries on top of the standard libraries to support networking. The libraries for CLDC also provide upward compatibility and portability of applications to other Java platform editions. However, this is not easy because a lot of libraries in J2SE and J2EE have interdependencies on one another and it is therefore not possible to take one part of the libraries and ignore others. To overcome this issue, CLDC libraries are divided into two categories: classes that are a subset of standard J2SE libraries and classes that are specific to CLDC but can be mapped onto J2SE. For instance, packages such as java.lang.*, java.util.* and java.io.* are from J2SE libraries whereas package such as javax.microedition.* is specific to CLDC. 4.2 Connected Device Configuration (CDC) CDC is the other J2ME configuration aimed at devices that have bigger memory footprint and more computational power than CLDC devices. The devices that use CDC typically have the following characteristics: 2Mbytes or more memory for Java platform 32-bit processor High bandwidth network connection, most often using TCP/IP Like CLDC, CDC also consists of Java language, Java virtual machine and Java libraries. As shown in Figure 5, CLDC is a subset of CDC, which is again a subset of J2SE. Both CDC and CLDC have some features that are not inherited from J2SE such as connection framework. This connection framework, defined in javax.microedition.io is customised for handheld devices with lower memory footprint because networking features defined in java.io.* or java.net.* are too expensive for the CDC or CLDC devices.

9 9 Figure 5: Relationship between J2ME configurations and J2SE [6] Java language Although CDC devices have limited memory, it is expected that the memory footprint is big enough to support full Java language features as defined in J2SE Java virtual machine The virtual machine specified in CDC is called Compact Virtual Machine (CVM). 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 [3], [1]. The reduction in memory footprint for classes is approximately 40% compared to JDK classic [1]. This smaller footprint makes it suitable for embedded devices. In addition to this, CVM supports some other features, which are listed below: Memory system: CVM supports advanced memory system featuring exactness, small average garbage collection pause times, full separation of virtual machine from the memory system, pluggable garbage collectors and generational garbage collection. Portability: Most of CVM is implemented in C language, which makes it easier to port to other devices assuming that most of the target devices support C implementation. CVM also contains a real time aware porting layer, supports multiple porting options for areas that are difficult to implement by a porter.

10 10 Fast synchronization: CVM performs most synchronization operations with just a few machine instructions and most without consuming additional lock resources from the underlying operations system. ROMable classes: CVM can run with preloaded, mostly read-only classes along with dynamically loaded classes. This gives better startup time, less fragmentation, more data sharing and ability to execute bytecodes out of Read Only Memory (ROM). Native thread support: CVM has support for JNI. Latest JVM support: CVM supports full Java 2 platform, version 1.3 virtual machine specification and libraries. This new version include support for weak references, reflection, serialization, JNI, Remote Method Invocation (RMI) and Java Virtual Machine Debugging Interface (JVMDI). Stack usage: CVM is cable of static analysis of the virtual machine code. It also features deterministic and reduced footprint native stack usage. Startup and shutdown: CVM is capable of cleanly shutdown and restart in a single address space operating system. It does not require any help from the process and can free up all allocated memory and stop the threads. In order to provide smaller footprint CVM supports only a subset of JVM, although it is capable of supporting full JVM features. Features like desktop user interface, native interface support, debugging support etc. are not mandatory in CVM. If CVM supports them then it becomes equivalent to JVM Java libraries The CDC class library is the minimal set of APIs needed to support a virtual machine. It contains the minimum Java packages from J2SE platform to build and run the virtual machine. CDC forms a superset of CLDC and therefore contains all the libraries such as javax.microedition.*, supported by CLDC. The basic packages supported by CDC are: java.lang, lava.util, java.net, java.io, java.text, java.security etc. 5 PROFILES As mentioned earlier, a profile addresses a market segment or a consumer device group or an application domain. This is primarily because of the fact that consumer devices range from mobile phones to washing machines or electronic toys. These devices have different requirements, different functionalities and different expected behaviours. For instance, a washing machine does not need to have feature like a mobile phone; a mobile phone does not require any pre-programmed start and stop functions like a washing machine; an electronic toy does not require an address book or a capacity to provide real time stock updates. To come up with a feature-rich platform to cover the requirements of all these devices is not only impractical and but is also business-wise or financially infeasible. J2ME framework provides a concept of profile to make it possible to define a platform for a specific group of devices. What this means is that there can be one profile for mobile phones like devices, one profile for washing machine like devices,

11 one profile for electronic toy like devices and so on. These profiles can be either device specific or application specific. It is also possible for one device to support more than one profile. Profiles sit on top of the appropriate configuration (see Figure 2 & Figure 3) and use the services provided by that configuration. Different configurations support different profiles. 5.1 CLDC profile CLDC has only one profile at this stage Mobile information device profile (MIDP) This profile covers a vertical market for mobile information devices. The MIDP specification [10] defines the architecture and APIs needed for third party application development. All of the mobile information devices share some common requirements such as limited memory, small screen size and bandwidth limited networking features. In an ideal environment, MIDP features can be implemented in a brand new set of devices and they will have only MIDP features. However, in reality, existing devices will be the first ones to use these features. These existing devices cannot simply get rid of all the existing features and take on MIDP features. Therefore, the MIDP architecture addresses these issues and tries to incorporate them so that the transition from the native system to MIDP is seamless. Since MIDP extends CLDC for mobile information devices, it introduces some extra properties and sometimes overwrites some CLDC properties. The properties introduced by MIDP can be summarised as follows: MIDP defines some additional system properties that must be made available to the applications through java.lang.system.getproperty. These properties are microedition.locale and microedition.profiles. lava.lang.system.exit and java.lang.runtime.exit must throw java.lang.securityexception when invoked by a MIDlet. A MIDlet is an MIDP application that uses only the APIs defined by MIDP and CLDC. MIDP adds functions that allow the applications to set and be notified of timers. MIDP extends GenericConnection framework available in CLDC to support a subset of HTTP protocol that can be implemented by using both IP based protocols such as TCP/IP and non-ip based protocols such as Wireless Application Protocol (WAP). This framework provides the base stream and content interfaces. The interface HttpConnection provides the additional functionalities to set request headers and other http specific functions. MIDP provides a mechanism to allow MIDlets to persistently store data and retrieve it later. This storage mechanism is called Record Management 11

12 12 System (RMS). Records are arrays of bytes that are uniquely identified by recordid. MIDP defines an application model, which specifies how the applications or MIDlets are packaged together and how they share resources within the same virtual machine. For applications, MIDP has a MIDlet suit that consists of a runtime execution environment, MIDlet suite packaging, application descriptor and application lifecycle. MIDP defines two levels of user interface APIs: high level and low level. The high level API is designed for business application, where portability of the application across devices is important. To achieve portability, it employs a high level of abstraction and little control. Low-level API, on the other hand, is for applications, which require precise placement and control of graphic elements and do not have much abstraction. 5.2 CDC profile Currently, CDC has only one profile the foundation profile. However, in the future more profiles can be added to this configuration Foundation profile The foundation profile sits on top of CDC configuration and provides a complete implementation of JVM as in standard J2SE platform. This profile can therefore be used by any embedded devices with limited resource but still require full Java platform features. The foundation profile contains the complete basic Java packages from J2SE technology except some Graphical User Interface (GUI) related features. Due to the nature of the screen size of CDC devices, the GUI dependencies on java.awt are removed. This profile also modifies some of the packages from CDC libraries and obviously this modification is not seen by any other profiles, which may sit on top of CDC configuration in the future. This modification of the CDC libraries is primarily to make the combination of this profile and CDC equivalent to J2SE. Some of the additions made by foundation profile are full java.lang.*, support, full zip support, addition of TCP/IP socket and HTTP connections, full java.io.*, extra security support such as code signing and certificates etc. 6 RELATED EMBEDDED TECHNOLOGIES This section consists of a set of Java based embedded technologies. This set of technologies is not related to J2ME but both of them are aimed towards to consumer devices they both have similar restrictions on memory and computational power. 6.1 Java card Java card technology allows programs written in Java programming language to run on smart cards. Smart cards typically have 1Kbytes of Read Access Memory (RAM), 16Kbytes of Electrically Erasable Programmable ROM (EEPROM) and 24Kbytes of

13 ROM. These figures are a lot less than the smallest of the J2ME technology. Java card technology consists of three components: Java Card Virtual Machine (JCVM), Java Card Runtime Environment (JCRE) and Java Card API. The Java language itself is a very customized subset of the standard Java language. The JCVM consists of two different virtual machines: a converter, an off-card virtual machine and an interpreter, an on-card virtual machine. The converter stays in desktops or workstations and it converts class files into Converted APplet (CAP) files that are executed by the interpreter residing on the smart cards. JCRE acts as the operating system for the smart card. It houses the JCVM (or the interpreter), native methods, installer (which installs the CAP files onto the card), system classes, industry specific extensions etc. The Java Card API consists of a set of customised classes for programming smart card applications, also called Java Card applets. The API consists of three core packages: java.lang, javacard.framework and javacard.security and one extension package: javacardx.crypto. 13 Figure 6: Java Card installation process [15] 6.2 Java TV Java TV is a J2SE based technology aimed at digital TV receivers [8], [9]. It consists of standard JVM and several reusable libraries belonging to Java programming language. The virtual machine resides on the TV receiver and executes byte code from there. The libraries consist of core class libraries from the Java platform and a set of application specific libraries. The technology provides a key benefit in the sense that applications and applets can be brought to the receiver only when they are needed and they can be removed from the receiver when they are not needed. Figure 7 shows a typical software stack on a digital TV receiver.

14 14 Figure 7: Typical software stack on digital TV receiver [9] 6.3 Java embedded server software The Java embedded server software is targeted to service driven network applications. This technology enables dynamic delivery of services on demand. To achieve this a Java embedded server product has to be embedded in any network device such as home gateway, vending machine, automobile or gas station and the services can be deployed on those devices over the network. This embedded server has a very small memory footprint, around 500Kbytes and therefore does not need a bit chunk of the available memory. Figure 8: Java embedded server architecture [16]

15 As shown in Figure 8 Java embedded server technology consists of two components: framework or service space and the services themselves. The framework consists of APIs for lifecycle management of services and applications. It manages things like installation, versioning, content management, monitoring etc. The services are modular services that can be deployed on the devices through the network, primarily the Internet. Some examples of services are http, login, thread management, remote administration etc. 6.4 Personal java application environment Personal Java Application Environment (PJAE) is a Java application environment that executes software written in Java programming language [11]. It is an old version of Java platform for embedded devices and therefore is aimed at software for consumer devices rather than desktop computers. However, the virtual machine this environment relies on is the standard JVM specified for J2SE. Therefore, this environment uses most of the standard JDK APIs and also some PJAE specific APIs. The latest PJAE, version 1.2 uses JDK Currently a new CDC profile called the personal profile is being developed in the Java Community Process (JCP) [14]. This profile is expected to be backward compatible with personal java. In the long run, it is very likely that personal java will be replaced by personal profile for CDC. 7 CONCLUDING REMARKS Although Java came out as an object-oriented programming language it has now established itself as a platform. The concept of configurations and profiles makes J2ME platform very modular, scalable and customisable. The developers have the flexibility of using the platform for their needs without inheriting unnecessary features and consequently making their applications very slim. Also, the APIs provided by the platform help developers concentrate only on the application specific issues. Development of configurations and profiles is attracting industry cooperation and involvement. This cooperation will help standardize the technology, make the participants commit to the technology and eventually make the development time shorter. 15

16 16 References [1] Connected Device Configuration (CDC) and the Foundation Profile, Sun Microsystems, [2] Connected, Limited Device Configuration, Sun Microsystems, [3] The CVM Virtual Machine, Sun Microsystems, May [4] Java 2 Platform, Micro Edition, Frequently Asked Questions, January [5] Simplified guide to the Java 2 Platform, Enterprise Edition, Sun Microsystems, [6] Java Platform Micro Edition (J2ME ) Technology for Creating Mobile Devices, Sun Microsystems, [7] Java 2 Platform, Micro Edition Data Sheet, Sun Microsystems, [8] Java Technologies for Interactive TV Technical White Paper, Sun Microsystems, [9] The Java TV TM API Overview: Setting the Standard for a Digital Future, Sun Microsystems, [10] Mobile Information Device Profile (JSR 37), Java Community Process, Java 2 Platform Micro Edition, Sun Microsystems, [11] PersonalJava Application Environment Specification, Sun Microsystems, [12] Sun Outlines Three Editions of Java 2 Platform, Press Release, June 15, 1999

17 17 [13] Java 2 Platform Micro Edition, Wireless Toolkit, Sun Microsystems, [14] Personal Profile Specification, JSR 62, Java Community Process, [14] J2SE 1.3 Datasheet, Sun Microsystems, [15] Java Card Technology Overview [16] Java Embedded Server Technology Data Sheet