Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 5
Текст из файла (страница 5)
Devices include set-topboxes and in-vehicle systems.The Personal Basis Profile and Personal Profile have replaced PersonalJava technology and provide a clear migration path for PersonalJavaapplications to J2ME. Although Personal Information Management andTelephony APIs are not mandatory in this profile, replacements are beingspecified for J2ME use.
Both the Personal Basis Profile and Personal Profileare layered on top of the CDC and Foundation Profile.1.2 CLDC and MIDP1.2.1CLDCA developer wishing to create applications for mobile devices may betempted to ignore the full specification of CLDC. A developer may initiallybe interested in getting acquainted with MIDP as a standalone technology.It is, however, important to understand the underlying technology thatforms MIDP.The CLDC, as specified by Java Specification Request (JSR) 30(http://jcp.org/en/jsr/detail?id=30), is the smaller of the two configurations and sets out to define a standard for devices with the followingcapabilities:• 160 KB to 512 KB of total memory budget available for the Javaplatform• 16-bit or 32-bit processor• low power consumption, often operating on battery power• intermittent network connection, possibly wireless and limited to abandwidth of 9600 bps or less.The 160 KB memory budget is derived from the minimum hardwarerequirements, as follows:8INTRODUCTION TO J2ME• at least 128 KB of non-volatile memory available for the Java VirtualMachine and CLDC libraries• 32 KB of volatile memory for the Java runtime object memory.CLDC itself defines the minimum required Java technology in terms oflibraries and components for small-connected devices.
Specifically, thisaddresses the Java language itself, the virtual machine definition, corelibraries, I/O capabilities, networking and security.Interestingly, from an early stage, one of the focuses for the CLDCdefinition was to recognize that much of the content for these deviceswould come from third-party developers.
Another was that the idea ofbeing able to create applications portable across a range of devices shouldbe adhered to. This would provide an easier path to revenue generationand therefore proliferate content for more devices. The nature of Javameans that a programmer can create applications that use the device’sfeatures without having to actually understand the working of the device.The developer only needs to comprehend the interface to the device.CLDC does not guarantee portability and it does not implement anyoptional features. Variants of devices within CLDC should be specifiedthrough profiles, rather than the configuration.
It must be said that trueapplication portability can only be obtained if a few principles are appliedduring the application design stage. We shall be looking at these issueslater in this book.1.2.1.1 K-Virtual MachineSun’s original VM for CLDC was known as the KVM (which stoodfor Kauai Virtual Machine, sometimes also known as the Kilo VirtualMachine).
The CLDC VM is, apart from a few differences which we shalloutline shortly, compliant with the Java Virtual Machine Specificationand the Java Language Specification.The libraries available are typically split into two categories: thosedefined by CLDC and those defined by a profile and its optional packagessuch as MMAPI and WMA. Figure 1.2 demonstrates at a high level howthese components fit together.So that the CLDC virtual machine can run within a small footprintand also to take into account additional security requirements for CLDCdevices, CLDC differs from CDC in the following respects:• no floating point support (although it has been added for CLDC1.1) – this means that float and double numbers cannot be usedand alternative means of storing these values have to be found, forexample, ”string math”• no finalization – the Object.finalize() method does not exist(Object.finalize() is used to carry out any tidying up that mayCLDC AND MIDP9ProfilesCLDC LibrariesJava Virtual MachineHost Operating SystemFigure 1.2High-level architecture.be needed when an object is collected by the garbage-collector.However, there is little, if any, practical need for this method.)• limited error handling – only three error classes exist: java.lang.Error, java.lang.OutOfMemory and java.lang.VirtualMachineError• no Java Native Interface (JNI) – this is due to security concerns andthe overhead exerted by JNI on the device memory• no user-defined class loaders – the built-in class loader cannot beoverridden, for security reasons• no reflection• no thread groups and daemon threads – although threading is available, thread groups cannot be created (however, Thread arrays canbe created if a similar effect is required)• no weak references, although these will be added to CLDC 1.1.1.2.1.2 Core LibrariesA number of classes have been inherited from J2SE.
To maintain therelationship between J2ME configurations and J2SE, it was decided thateach class has to have the same name and that each package name mustbe identical or a subset of the corresponding J2SE class. The semantics ofthe class must remain the same; methods included in the subset shall notbe changed. This means that classes may not be added to a package ifthey do not exist in J2SE.The following outlines the classes that are available in CLDC 1.0 (afull listing of these packages can be found in Appendix 1):10INTRODUCTION TO J2ME• system classes – J2SE includes several classes that are closely tied intothe Java virtual machine; for example, the javac compiler requirescertain functions from the String and StringBuffer classes• data type classes – Boolean, Byte, Short, Integer, Long andCharacter are supported under CLDC; Double and Float arenot supported• collection classes – Vector, Stack and Hashtable are available,together with interfaces such as Enumeration• input/output classes – Reader, Writer, InputStreamReader andInputStreamWriter are required in order to support internationalization• calendar and time classes – a small subset of the java.util classesCalendar, Date and TimeZone are included; only one time zone issupported by default, although device manufacturers may implementadditional ones• additional utility classes – the java.util classes Random and Mathhave been included to provide a pseudo-random number generatorand methods such as min, max and abs, respectively• exception classes – as the CLDC classes are compatible with J2SElibraries, CLDC classes throw the same exceptions as J2SE classes;there is, therefore, a fairly comprehensive list of exception classes (seeAppendix 1)• error classes – in contrast to the exception classes, the error handling capabilities of CLDC are limited to the three error classesseen previously• internationalization – CLDC provides support for the translation ofUnicode characters to and from byte streams; just as J2SE uses readersand writers, J2ME uses the following constructors:newnewnewnewInputStreamReader(InputStream is);InputStreamReader(InputStream is, String name);OutputStreamReader(OutputStream os);OutputStreamReader(OutputStream os, String name);The constructors that define a string parameter can name the encodingscheme.
If it is not named, the default encoding (stored in the system property microedition.encoding) is used. Additional converters may beused by certain implementations. An UnsupportedEncodingException will be thrown if the specified converter is not present. CLDCdoes not support localization such as time and currency formatting. Ifnecessary, these can be added to an application’s logic.CLDC AND MIDP11• property support – java.util.Properties provides support forthe limited set of properties available in CLDC.The properties are obtained by making a call to System.getProperty(String, key). This method returns some limited propertyinformation about the device itself, such as the configuration version,platform name, character encoding and supported profiles.
It also returnsthe values of the properties defined by each optional package supportedby the device.1.2.1.3 Networking and I/ONetworking on CLDC devices has been streamlined so that the programmer does not have to fully understand the underlying device capabilities.The Generic Connection Framework (GCF) has been created, streamlining the implementation of networking within applications. This also helpsprovide a smaller footprint.Networking and I/O are implemented using the same interface.
Allconnections are created using a single static method in a system classcalled Connector. There are six basic interface types addressed by thisframework, although the actual implementation of any of these protocolsis governed by the profile rather than by CLDC:• basic serial input• basic serial output• datagram communication• connection-orientated, i.e. TCP/IP• notification mechanism for client–server communications• basic web server connections.Creating the connections is rather simple and, regardless of the typeof connection, the format is the same. Here is a list of some commonexamples:• HTTP:Connector.open("www.foo.com");• Sockets:Connector.open("socket://192.168.0.1:9000");• Datagrams:Connector.open("datagram://192.168.0.1");This minimizes the differences between one protocol and another anduses a text string (the parameter to the open() method) to categorize thetype of connection required.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
