high level display screens in j2me manufacturer

CIOs and IT managers are always struggling to improve the availability of corporate data to those who need it to run the business. In the case of salespeople and mobile executives, that"s a tall order. Ideally, you would use the very gear that these people already carry — such as PDAs or cell phones — to act as messaging systems and data terminals that can fetch customer information or place an order.

Unfortunately, the vast differences among these devices — Pocket PCs running Windows CE, PDAs running Palm OS or Linux, cell phones running the Symbian OS — pose significant problems for developers. Even the cell phones from a single vendor such as Motorola (the company I work for) can vary widely in processor type, memory amount, and LCD screen dimensions. Worse, new handsets sporting new features, such as built-in cameras and Bluetooth networking, are released every six months to nine months.

For IT managers whose chief concern is that applications running on device A today also run on device B tomorrow, the best choice among development platforms is J2ME, a slimmed-down version of Java tailored for use on embedded and mobile devices. Most handset vendors implement their own Java VM, and third-party VMs provide Java support in Palm and Pocket PC devices. For a broad range of devices, past, present, and future, J2ME provides a high degree of security and application portability — but not without drawbacks.

As were all editions of Java technology, J2ME was built to provide controlled access to program resources. The run-time architecture uses a “sandbox” mechanism that contains the executing program in a separate, protected memory space. This prevents code malfunctions from damaging other critical components of the run-time environment. Also, the program doesn’t have unfettered access to any low-level hardware or resources outside of the sandbox. Instead, all device operations are conducted via J2ME API calls.

There are good reasons to isolate a program from many of the phone’s functions. Unlike a desktop PC in which a program crash might clobber a word processing session, a cell phone is essentially a two-way radio. The Federal Communications Commission frowns on the improper use of radio transmitters regardless of the culprit — a cell phone’s owner or a malfunctioning program. And you wouldn’t want a Trojan program “phoning home” and transmitting personal information to a cracker. Because over-the-air provisioning allows users to download new applications, this makes the Java security sandbox more important than ever.

However, this protection scheme has its downside. Stated simply, if an API isn’t defined for a specific hardware feature, a developer can’t use that feature. For example, the Sony Ericsson T610 handset comes with an army of features: Bluetooth networking, infrared and serial connectivity, and a built-in digital camera. However, the current APIs in the T610’s J2ME implementation don’t utilize these features. Instead, you must use C++ and the Symbian OS (which lies under the J2ME abstraction layers) to access them.

Most vendors sidestep this issue by providing special Java APIs designed to access proprietary features. Unfortunately, each vendor devises its own unique set of APIs to use similar services. These incompatible APIs defeat J2ME’s prime directive to provide an abstract platform with a consistent interface that accesses all available features across all devices. Using such vendor-specific APIs also ties the application to a particular mobile device, which reduces an IT manager’s options to deploy the application as far as possible across the enterprise.

J2ME limits support for vendor-specific hardware features to accommodate variations among devices. J2ME tackles hardware variations in two ways. First, J2ME defines an abstraction layer known as a configuration, which describes the minimum hardware required to implement Java on an embedded device. The J2ME configuration that addresses resource-constrained devices such as mobile phones and low-end PDAs is the CLDC (Connected Limited Device Configuration).

Second, J2ME defines a second abstraction layer, termed a profile, that describes the device’s hardware features and defines the APIs that access them. Put another way, profiles extend a configuration to address a device’s specific hardware characteristics.

J2ME currently defines one profile for CLDC devices: the MIDP (Mobile Information Device Profile). In addition to stipulating the basic hardware requirements, the MIDP implements the APIs used to access the hardware.

It’s important to understand that a J2ME device can have only one configuration that describes the core hardware. However, multiple profiles are allowed, including the MIDP and vendor profiles that support device-specific features. A vendor can therefore quickly adapt J2ME for a new device by writing profiles for it.

Besides interfaces, the MIDP describes the characteristics of a J2ME application, known as a midlet. Midlets are taxonomically similar to Java applets, the major difference being that a midlet can download data but not additional code through the connection. The end result is that a midlet has the potential to run unaltered on any J2ME-enabled device. Furthermore, because J2ME profiles define the interface, the appearance and behavior of the midlet on different devices is nearly identical. J2ME thus holds out the promise of becoming a universal front-end for client applications that can run on any mobile device.

The astute reader will have no doubt noticed the words “potential” and “nearly” in that last paragraph. Let’s face it: A few limitations in J2ME can hamper application portability. To begin with, subtle variations in each vendor’s J2ME implementation can cause incompatibilities.

Another issue is that if an API doesn’t exist for a specific device feature, you can’t use that feature at all. J2ME does specify optional standards, such as the MMAPI Mobile Media API, which provides support for audio playback and streamed video. Unfortunately, a developer can’t rely on an optional standard being available on every device.

However, J2ME is constantly evolving to address these concerns. In November 2002, the Java Community Process (JCP) released a significant revision to the MIDP specification. Called MIDP 2.0, it adds mission-critical APIs that support secure network connections (via HTTPS) and implements permissions with digital signatures to support trusted code. The specification also provides improved UI elements that offer enhanced form layout for business applications.

Unlike optional standards, a device that uses MIDP 2.0 must implement all the APIs that it describes, thus ensuring their availability to a program. Handsets that support the MIDP 2.0 specification should appear on the market later this year.

Down the road, the JCP proposes a new JTWI (Java Technology for the Wireless Industry) specification. In JTWI, a number of optional J2ME APIs — such as MMAPI and WMA (Wireless Messaging APIs) — become required services.

Even in its current state, J2ME offers developers the ability to write once and deploy a business application across the wide range of wireless gear currently available. J2ME’s abstraction layers also provide a hedge against vendor lock-in, and they help cope with the rapid changes in today’s wireless devices. Developers may have to craft the midlet’s interface to address the lowest-common-denominator display, but that’s a small price to pay compared with writing a custom client application for each device the corporation owns.

This chapter explains the Java 2 platform architecture and its security features as they apply to building Java applications. In particular, it describes the various Java platforms and the core security features that contribute to the end-to-end security of Java-based applications running on various systems—from servers to stand-alone computers, computers to devices, and devices to smart cards.

Sun"s Java philosophy of "Write Once, Run Anywhere" has been an evolving success story since its inception, and it has revolutionized the computing industry by delivering to us the most capable platform for building and running a wide range of applications and services. In general, the Java platform provides a general-purpose object-oriented programming language and a standard runtime environment for developing and delivering secure, cross-platform application solutions that can be accessed and dynamically loaded over the network or run locally.

With the release of the Java 2 Platform, Sun categorized the Java technologies under three key major editions in order to simplify software development and deployment. The Java 2 Standard Edition (J2SE) provides the runtime environment and API technologies for developing and executing basic Java applications, and it also serves as the secure foundation for running Java enterprise applications. The Java 2 Enterprise Edition (J2EE), or the J2EE Platform, is a set of standards and API technologies for developing and deploying multi-tier business applications. To support Java on microdevices and embedded systems, Java 2 Micro Edition (J2ME) provides the runtime environment and API technologies for addressing the needs of consumer electronics and devices. With its widespread adoption, today Java technology is enabled and executed from smart cards to microdevices, handhelds to desktops, workstations to enterprise servers, mainframes to supercomputers, and so on.

To facilitate end-to-end security of the Java platform-based application solutions, the Java runtime environment (JRE) and the Java language provide a solid security foundation from the ground up by imposing strong format and structural constraints on the code and its execution environment. This distinguishes the Java platform from other application programming languages—it has a well-defined security architectural model for programming Java-based solutions and their secure execution.

In this chapter, we will explore the various Java platforms and the intricate details of their security architecture that contribute to the end-to-end security of Java-based application solutions. In particular, we will study Java security and the inherent features of the following technologies:

Security has been an integral part of Java technology from day one. Security is also an evolving design goal of the Java community—building and running secure and robust Java-based network applications. The primary reason for Java"s success today as a secure execution environment is the intrinsic security of its architectural foundation—the Java Virtual Machine (JVM) and the Java language. This foundation achieves the basic Java security goal and its definitive ways for extending security capabilities to ensure features such as confidentiality, integrity, trust, and so forth. A second reason for its success is its ability to deliver an interoperable and platform-neutral security infrastructure that can be integrated with the security of the underlying operating system and services.

The JVM is an abstract computing engine that resides on a host computer. It is the execution environment for the Java programming language and has the primary responsibility for executing the compiled code by interpreting it in a machine-independent and cross-platform fashion. The JVM is often referred to as the Java runtime environment. While executing a Java program running on top of the JVM, the JVM insulates the application from the underlying differences of the operating systems, networks, and system hardware, thus ensuring cross-platform compatibility among all of the implementations of the Java platform.

The Java language allows creation of general-purpose programs called Java classes that represent a Java program or an application. The Java classes compile into a format called Java"s executable bytecodes, which are quite similar to the machine language that can run on top of a JVM. The JVM also allows users to download and execute untrusted programs and applications from remote resources or over a network. To support delivery of Java components over the network, the JVM controls the primary security layer by protecting users and the environment from malicious programs. To enable security, the JVM enforces stringent measures ensuring systems security on the host client machine and its target server environments.

Distributing the executable Java bytecode over a network or running automatically inside a Web browser or a client"s machine leads to different security risks and attacks, such as disclosure of the target environment to the untrusted applications and damage or modification of the client"s private information and data. For example, Java applets downloaded from a network are not allowed to have access to, read from, or write to a local file system. They are also not allowed to create network connections to any host system except the one where they are deployed. On the other hand, stand-alone Java applications that reside and run locally as trusted applications are not subjected to these security features. The key issue is that allowing untrusted applications such as Java applets to be downloaded from a network via a Web browser and letting them access certain resources on the host computer paves the way for security breaches and becomes a potential avenue for the spread of viruses. To prevent known security breaches and threats, the JVM provides a built-in Java security architecture model, configurable security policies, access control mechanisms, and security extensions. Because of the built-in JVM safety features, Java programs can run safely and are more securely protected from known vulnerabilities.

Java is a general-purpose object-oriented programming language similar to C++. It delivers platform-neutral compiled code that can be executed using a JVM and is intended for use in distributed application environments, heterogeneous systems, and diverse network environments. The Java language is also designed to provide for the security and integrity of the application and its underlying systems at all levels—from the Java language constructs to the JVM runtime and from the class library to the complete application.

The language defines all primitives with a specific size and all operations are defined to be in a specific order of execution. Thus, the code executed in different JVMs will not differ from the specified order of execution.

The language provides access-control functionality on variables and methods in the object by defining name space management for type and procedure names. This secures the program by restricting access to its critical objects from untrusted code. For example, access is restricted by qualifying the type members as public, protected, private, package, etc.

The Java language does not allow defining or dereferencing pointers, which means that programmers cannot forge a pointer to the memory or create code defining offset points to memory. All references to methods and instance variables in the class file are done via symbolic names. The elimination of pointers helps to prevent malicious programs like computer viruses and misuse of pointers such as accessing private methods directly by using a pointer starting from the object"s pointer, or running off the end of an array.

The Java language is a strongly typed language. During compile time, the Java compiler does extensive type checking for type mismatches. This mechanism guarantees that the runtime data type variables are compatible and consistent with the compile time information.

The language allows declaring classes or methods as final. Any classes or methods that are declared as final cannot be overridden. This helps to protect the code from malicious attacks such as creating a subclass and substituting it for the original class and override methods.

The Java Garbage Collection mechanism contributes to secure Java programs by providing a transparent storage allocation and recovering unused memory instead of deallocating the memory using manual intervention. This ensures program integrity during execution and prevents programmatic access to accidental and incorrect freeing of memory resulting in a JVM crash.

With these features, Java fulfills the promise of providing a secure programming language that gives the programmer the freedom to write and execute code locally or distribute it over a network.

In the previous two sections, we briefly looked at the basic security features provided by the JVM and the Java language. As part of its security architecture, Java has a built-in policy-driven, domain-based security model. This allows implementing security policies, protecting/controlling access to resources, rule-based class loading, signing code and assigning levels of capability, and maintaining content privacy.

In the first release of the Sun Java Platform, the Java Development Kit 1.0.x (JDK) introduced the notion of a sandbox-based security model. This primarily supports downloading and running Java applets securely and avoids any potential risks to the user"s resources. With the JDK 1.0 sandbox security model, all Java applications (excluding Java applets) executed locally can have full access to the resources available to the JVM. Application code downloaded from remote resources, such as Java applets, will have access only to the restricted resources provided within its sandbox. This sandbox security protects the Java applet user from potential risks because the downloaded applet cannot access or alter the user"s resources beyond the sandbox.

The release of JDK 1.1.x introduced the notion of signed applets, which allowed downloading and executing applets as trusted code after verifying the applet signer"s information. To facilitate signed applets, JDK 1.1.x added support for cryptographic algorithms that provide digital signature capabilities. With this support, a Java applet class could be signed with digital signatures in the Java archive format (JAR file). The JDK runtime will use the trusted public keys to verify the signers of the downloaded applet and then treat it as a trusted local application, granting access to its resources. Figure 3-1 shows the representation of a sandbox in the JDK 1.1 security model.

The release of J2SE [J2SE] introduced a number of significant enhancements to JDK 1.1 and added such features as security extensions providing cryptographic services, digital certificate management, PKI management, and related tools. Some of the major changes in the Java 2 security architecture are as follows:

In the Java 2 security architecture, all code—regardless of whether it is run locally or downloaded remotely—can be subjected to a security policy configured by a JVM user or administrator. All code is configured to use a particular domain (equivalent to a sandbox) and a security policy that dictates whether the code can be run on a particular domain or not. Figure 3-2 illustrates the J2SE security architecture and its basic elements.

): In J2SE, all local Java applications run unrestricted as trusted applications by default, but they can also be configured with access-control policies similar to what is defined in applets and remote applications. This is done by configuring a ProtectionDomain, which allows grouping of classes and instances and then associating them with a set of permissions between the resources. Protection domains are generally categorized as two domains: "system domain" and "application domain." All protected external resources, such as the file systems, networks, and so forth, are accessible only via system domains. The resources that are part of the single execution thread are considered an application domain. So in reality, an application that requires access to an external resource may have an application domain as well as a system domain. While executing code, the Java runtime maintains a mapping from code to protection domain and then to its permissions.

Protection domains are determined by the current security policy defined for a Java runtime environment. The domains are characterized using a set of permissions associated with a code source and location. The java.security.ProtectionDomain class encapsulates the characteristics of a protected domain, which encloses a set of classes and its granted set of permissions when being executed on behalf of a user.

): In essence, permissions determine whether access to a resource of the JVM is granted or denied. To be more precise, they give specified resources or classes running in that instance of the JVM the ability to permit or deny certain runtime operations. An applet or an application using a security manager can obtain access to a system resource only if it has permission. The Java Security API defines a hierarchy for Permission classes that can be used to configure a security policy. At the root, java.security.Permission is the abstract class, which represents access to a target resource; it can also include a set of operations to construct access on a particular resource. The Permission class contains several subclasses that represent access to different types of resources. The subclasses belong to their own packages that represent the APIs for the particular resource. Some of the commonly used Permission classes are as follows:

Example 3-1 shows how to protect access to an object using permissions. The code shows the caller application with the required permission to access an object.

Permissions can also be defined using security policy configuration files (java.policy). For example, to grant access to read a file in "c:\temp\" (on Windows), the FilePermission can be defined in a security policy file (see Example 3-2).

Policy: The Java 2 security policy defines the protection domains for all running Java code with access privileges and a set of permissions such as read and write access or making a connection to a host. The policy for a Java application is represented by a Policy object, which provides a way to declare permissions for granting access to its required resources. In general, all JVMs have security mechanisms built in that allow you to define permissions through a Java security policy file. A JVM makes use of a policy-driven access-control mechanism by dynamically mapping a static set of permissions defined in one or more policy configuration files. These entries are often referred to as grant entries. A user or an administrator externally configures the policy file for a J2SE runtime environment using an ASCII text file or a serialized binary file representing a Policy class. In a J2SE environment, the default system-wide security policy file java.policy is located at /lib/security/ directory. The policy file location is defined in the security properties file with a java.security setting, which is located at /lib/security/java.security.

Example 3-3 is a policy configuration file that specifies the permission for a signed JAR file loaded from "http://coresecuritypatterns.com/*" and signed by "javaguy," and then grants read/write access to all files in /export/home/test.

The J2SE environment also provides a GUI-based tool called "policytool" for editing a security policy file, which is located at "/bin/policytool."

The effective policy of the JVM runtime environment will be the union of all permissions in all policy files. To specify an additional policy file, you can set the java.security.policy system property at the command line:

): Each Java application can have its own security manager that acts as its primary security guard against malicious attacks. The security manager enforces the required security policy of an application by performing runtime checks and authorizing access, thereby protecting resources from malicious operations. Under the hood, it uses the Java security policy file to decide which set of permissions are granted to the classes. However, when untrusted classes and third-party applications use the JVM, the Java security manager applies the security policy associated with the JVM to identify malicious operations. In many cases, where the threat model does not include malicious code being run in the JVM, the Java security manager is unnecessary. In cases where the SecurityManager detects a security policy violation, the JVM will throw an AccessControlException or a SecurityException.

In a Java application, the security manager is set by the setSecurityManager method in class System. And the current security manager is obtained via the getSecurityManager method (see Example 3-4).

The class java.lang.SecurityManager consists of a number of checkXXXX methods like checkRead (String file) to determine access privileges to a file. The check methods call the SecurityManager.checkPermission method to find whether the calling application has permissions to perform the requested operation, based on the security policy file. If not, it throws a SecurityException.

If you wish to have your applications use a SecurityManager and security policy, start up the JVM with the -Djava.security.manager option and you can also specify a security policy file using the policies in the -Djava.security.policy option as JVM arguments. If you enable the Java Security Manager in your application but do not specify a security policy file, then the Java Security Manager uses the default security policies defined in the java.policy file in the $JAVA_HOME/jre/lib/security directory. Example 3-5 programmatically enables the security manager.

): The access controller mechanism performs a dynamic inspection and decides whether the access to a particular resource can be allowed or denied. From a programmer"s standpoint, the Java access controller encapsulates the location, code source, and permissions to perform the particular operation. In a typical process, when a program executes an operation, it calls through the security manager, which delegates the request to the access controller, and then finally it gets access or denial to the resources. In the java.security.AccessController class, the checkPermission method is used to determine whether the access to the required resource is granted or denied. If a requested access is granted, the checkPermission method returns true; otherwise, the method throws an AccessControlException.

Codebase: A URL location of class or JAR files are specified using codebase. The URL may refer to a location of a directory in the local file system or on the Internet. Example 3-7 retrieves all the permissions granted to a particular class that"s been loaded from a code base. The permissions are effective only if the security manager is installed. The loaded class uses those permissions by executing Class.getProtectionDomain() and Policy.getPermissions().

To ignore the default policies in the java.security file, and only use the specified policy, use "==" instead of "=". With the policy just presented, you may run the following:

Bytecode verifier: The Java bytecode verifier is an integral part of the JVM that plays the important role of verifying the code prior to execution. It ensures that the code was produced consistent with specifications by a trustworthy compiler, confirms the format of the class file, and proves that the series of Java byte codes are legal. With bytecode verification, the code is proved to be internally consistent following many of the rules and constraints defined by the Java language compiler. The bytecode verifier may also detect inconsistencies related to certain cases of array bound-checking and object-casting through runtime enforcement.

ClassLoader: The ClassLoader plays a distinct role in Java security, because it is primarily responsible for loading the Java classes into the JVM and then converting the raw data of a class into an internal data structure representing the class. From a security standpoint, class loaders can be used to establish security policies before executing untrusted code, to verify digital signatures, and so on. To enforce security, the class loader coordinates with the security manager and access controller of the JVM to determine the security policies of a Java application. The class loader further enforces security by defining the namespace separation between classes that are loaded from different locations, including networks. This ensures that classes loaded from multiple hosts will not communicate within the same JVM space, thus making it impossible for untrusted code to get information from trusted code. The class loader finds out the Java application"s access privileges using the security manager, which applies the required security policy based on the requesting context of the caller application.

With the Java 2 platform, all Java applications have the capability of loading bootstrap classes, system classes, and application classes initially using an internal class loader (also referred to as primordial class loader). The primordial class loader uses a special class loader SecureClassLoader to protect the JVM from loading malicious classes. This java.security.SecureClassLoader class has a protected constructor that associates a loaded class to a protection domain. The SecureClassLoader also makes use of permissions set for the codebase. For instance, URLClassLoader is a subclass of the SecureClassLoader. URLClassLoader allows loading a class or location specified with a URL.

Keystore and Keytool: The Java 2 platform provides a password-protected database facility for storing trusted certificate entries and key entries. The keytool allows the users to create, manage, and administer their own public/private key pairs and associated certificates that are intended for use in authentication services and in representing digital signatures.

We will take a look in greater detail at the usage of the Java keystore and keytool and how these tools help Java security in the section entitled "Java Security Management Tools," later in this chapter.

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users" wishes when a user submits their information through our Contact Us form.

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

If a user"s personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user"s personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user"s account.

Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson"s commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice

To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users" wishes when a user submits their information through our Contact Us form.

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

If a user"s personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user"s personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user"s account.

Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson"s commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice

To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users" wishes when a user submits their information through our Contact Us form.

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

If a user"s personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user"s personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user"s account.

Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson"s commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice

To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

J2ME, in its most familiar guise of MIDP, comes closer to this ideal than either the Standard or Enterprise edition because there"s only one version of the specification. Although there are different implementations, as far as the Java application is concerned it isn"t able to tell which platform it"s running on. There is a fly in the ointment, however. While MIDP offers a highly consistent runtime environment and so consistency of functionality, user interfaces vary wildly.

Real-world marketing issues mean that manufacturers produce phones in a range of shapes and sizes, with capabilities to suit every pocket. Can developers be blamed for wanting to take full advantage of the facilities of each individual device? Instead of forcing owners of high-end devices to make do with the minimal interface the J2ME standard requires, developers would, for instance, like to make full use of the large, deep-color screens that the latest devices sport.

Yet network operators (who aim to be the premier suppliers of mobile applications and services) don"t just want portability; they demand it. They will, for many consumers, also be the first point of contact when technical problems arise. If a MIDlet behaves very differently across various devices, the technical support costs for the operator could spiral out of control, and these costs subsequently will have to be passed on to the consumer, the developer, or possibly both.

The assumptions that MIDlet authors can make about the device running their applications are deliberately limited, and they have no control over application appearance. They do know, however, that their applications might be deployed on a device with only a numeric keyboard, a 96 x 54 pixel, and a 1-bit deep screen; or they might be deployed on a device with a _ VGA display, qwerty keyboard, and touch screen. Or anything in between. This has led to several different application styles.

The first style collects raw input events and uses Graphics, with its 2D primitives, directly for the UI. This style is typical of the games that currently form the bulk of available MIDlets and is aimed at smartphones. With these applications, assumptions about screen size, aspect ratio, and color depth are crucial factors when producing a portable app. These applications can be memory- and processor-hungry.

The second style of MIDP application uses displayables and commands to build simple form-based UIs, most similar to those on old green-screen mainframe apps. The commands are presented to the user in the same way that commands are usually displayed on the device. In principle, this offers the highest level of portability, since the items in the UI, and the commands that affect them, are presented to the user using implementations native to each device. As we shall see, there are problems with this approach.

A third style combines the first two approaches using a library such as kAWT to provide something closer to a traditional UI, with stronger layout control and richer UI components. This allows a great deal of portability at the expense of increased memory consumption and extra processor load. Application designers still need to make some assumptions regarding screen size.

To be allowed to bear the distinctive Java logo and use the phrase "Java powered," a device has to pass the tests in the Technology Compatibility Kit (TCK) from Sun Microsystems. There"s just one TCK for all devices. This guarantees conformity to the Java standard.

However, the standard enforced by the TCK guarantees only the lowest common denominator, and it"s possible for a MIDP implementation to pass the TCK tests and not perform well at all: in particular, the TCK has nothing to say about how UI components appear on screen, or how user actions are transmitted to applications.

The TCK also allows a great deal of latitude in how applications are deployed and managed, and an additional problem is that despite the presence of device emulators, these PC-based emulators often perform differently from their real-world counterparts - especially if the actual phone is still in development.

The J2ME specification states that a MIDlet may pass through three stages during its life, from creation in the PAUSED state, through the ACTIVE state, to the DESTROYED state. The MIDlet class constructor can allocate any resources used only by the MIDlet, and startApp() can allocate "shared resources," which should be released when the MIDlet is paused. Nonshared resources must be released by destroyApp(). The intention here is that MIDlets PAUSED by the device"s operating system must release expensive or volatile resources. This facility is meant to be used when a MIDlet is moved to the background on a task-swap.

Unfortunately, platforms differ in their interpretation of this feature. Some platforms, in fact, call destroyApp() when the MIDlet goes to the background, and create a new instance when it returns to the foreground. Clearly, a MIDlet that expects to be PAUSED but not DESTROYED could malfunction severely when restarted.

J2ME, like the Standard and Enterprise Editions, uses Unicode characters. Some platforms on which J2ME is installed do not. This results in some platforms rejecting application descriptors that, quite validly, contain characters outside of the 7-bit ASCII character set (for instance, �).

It can be worse than that. Some MIDP-enabled devices do not install from .jar and .jad files, but from proprietary binary formats created from the .jar and .jad files (one example is the RIM BlackBerry). Some MIDlets can"t be directly translated into RIM .cod files because attributes in the .jad contain ASCII characters that are not valid in a project name in the RIM tool used to build .cod files.

Commands attached to a displayable will be presented to the user in the same way as commands that are part of the device"s own UI are presented. This can cause confusion, since some platforms present commands in a menu that contains default items such as "select" and "exit". Some platforms present the commands in an immediate mode: simply selecting the command item sends an event to the application. On other platforms, a two-stage process takes place where the command is selected from a menu, then activated.

There are two problems here. Again, it"s challenging to write user instructions that will make sense on every platform. Also, words belonging to a screen navigation metaphor, such as "select" and "back", should be avoided as names of commands. To a greater or lesser extent, the MIDlet"s UI is presented within the context of the platform"s own.

The gauge item illustrates some of the issues in UI appearance and interaction that occur with J2ME applications. On some platforms, the gauge item does not have a border, nor does it have any textual representation of the current value. So a gauge showing a value of 0 is invisible, merely a blank area on the screen.

On some platforms, a gauge item has accompanying text to indicate the current value, as well as the graphical display. On other platforms, this text displays the current value of the gauge and, still on others, it"s the current value, as a percentage of the maximum value, that"s displayed.

This uncertainty causes difficulties in writing portable applications using gauges, especially interactive gauges. Imagine also the difficulty in writing the user guide for an application using gauges, not knowing how the platform will display the gauge or its current value.

Figure 1 shows a form with a gauge, as implemented on Sun"s reference platform. Figures 2, 3, and 4 show the same displayable from the MIDlet in the same state, but on three different platform-specific emulators. Notice that the reference implementation does not display any of the numerical parameters of the gauge, and neither does the platform in Figure 2, whereas the platform in Figure 3 shows all three parameters.

The platform in Figure 2 does display the title of the form being displayed ("Gauge: value 2") and displays both commands attached to the form ("back" and "continue"); the platform in Figure 3 does not display the form"s title and displays only one command ("back"). The command "continue" is on the options menu, along with platform-supplied commands "copy text", "find in page", and "exit"". Both platforms indicate that the gauge has focus, by the ears shown on either side of it (see Figure 2), and the grey box surrounding it (see Figure 1).

Contrast this with the platform shown in Figure 4. Here, the gauge shows the current and the maximum value (but not the minimum), and doesn"t look much like a gauge at all. The gauge ha