Download Support Readiness Document Java 2 Platform, Micro Edition

Support Readiness Document
Java 2 Platform, Micro Edition:
Connected Limited Device
Configuration 1.0.2, Mobile
Information Device Profile 1.0.1,
and J2ME Wireless Toolkit 1.0.1
Sun Microsystems, Inc.
Market Development and Developer Relations
Support Readiness Education
Support Readiness Document
Java 2 Platform, Micro Edition:
Connected Limited Device
Configuration 1.0.2, Mobile
Information Device Profile 1.0.1,
and J2ME Wireless Toolkit 1.0.1
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
U.S.A.
Version: 1.0.1
Release Date: February 6, 2001
 2000 by Sun Microsystems, Inc.—Printed in USA.
901 San Antonio Road, Palo Alto, CA 94303-4900
All rights reserved. No part of this work covered by copyright may be duplicated by any
means—graphic, electronic or mechanical, including photocopying, or storage in an information
retrieval system—without prior written permission of the copyright owner.
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.227-7013 (October 1988) and FAR 52.227-19 (June 1987). The
product described in this manual may be protected by one or more U.S. patents, foreign patents,
and/or pending applications.
TRADEMARKS: EmbeddedJave, Forte, J2ME, Java, Java Card, JavaPhone, Java Native Interface,
JDK, JNI, PersonalJava, Solaris, SPARC, and Sun Developer Essentials are trademarks of Sun
Microsystems, Inc. All SPARC trademarks are used under license and are trademarks or
registered trademarks of SPARC International, Inc. in the United States and other countries.
Products bearing SPARC trademarks are based upon an architecture developed by Sun
Microsystems, Inc. UNIX is a registered trademark in the United States and other countries,
exclusively licensed through X/Open Company, Ltd.
Production Note: This book was written in FrameMaker 5.5 for Solaris and Windows by Kathy
Kleinsteiber, Nicolas Lorain, Roger Riggs, Dov Zandman, and Tasneem Sayeed.
Support Readiness Education SRD Template 2.0
Table of Contents
Preface vii
1.0 Java 2 Platform, Micro Edition Overview
1
1.1 K Virtual Machine 2
1.2 Configurations 2
1.2.1 Connected Limited Device Configuration 3
1.2.2 Connected Device Configuration 4
1.3 Profiles 4
1.3.1 Mobile Information Device Profile 5
1.3.2 Personal Digital Assistant Profile 6
1.3.3 Personal Profile 6
1.3.4 Foundation Profile 6
1.3.5 Remote Method Invocation Profile 6
1.3.6 Other Profiles 7
1.4 Implementations of CLDC and MIDP 7
1.4.1 Reference Implementations from Sun 7
1.4.2 J2ME Wireless Toolkit 7
1.4.3 MIDP for Devices Using the Palm OS 7
1.4.4 Other CLDC and MIDP Implementations 8
1.5 Related Technologies 8
1.5.1 Wireless Application Protocol 8
1.5.2 PersonalJava 9
1.5.3 JavaPhone 9
1.5.4 EmbeddedJava 9
1.5.5 Java Card 9
1.6 Pointers to Tutorials and Other Product Materials 10
1.6.1 Product Homepages 10
1.6.2 Tutorials 10
1.6.3 Training Course Information 10
2.0 Product Changes in Current Versions of CLDC, MIDP, and the
J2ME Wireless Toolkit 10
SUN MICROSYSTEMS, INC.
i
Table of Contents
2.1 CLDC Releases 10
2.1.1 New Features in CLDC 1.0.2 11
2.1.2 Bugs Fixed in CLDC 1.0.2 11
2.1.3 Backward and Forward Compatibility with Other Versions of
CLDC 11
2.2 MIDP Releases 11
2.2.1 New Features in MIDP 1.0.1 11
2.2.2 Bugs Fixed in MIDP 1.0.1 12
2.2.3 Backward and Forward Compatibility with Other Versions of
MIDP 12
2.3 J2ME Wireless Toolkit Releases 12
2.3.1 New Features in the J2ME Wireless Toolkit 1.0.1 12
2.3.2 Bugs Fixed in the J2ME Wireless Toolkit 1.0.1 12
2.3.3 Backward and Forward Compatibility with Other Versions of
the J2ME Wireless Toolkit 12
3.0 Product Distribution and Licensing 13
3.1
3.2
3.3
3.4
Free Product and Specification Downloads 13
Physical Media 13
International Distribution 13
Product Licensing 13
3.4.1 Binary Product 13
3.4.2 Redistribution of Binary Product 14
3.4.3 Source Code License 14
4.0 Requirements and Dependencies
14
4.1 System Requirements and Dependencies 14
4.1.1 System Requirements for Connected Limited Device
Configuration 14
4.1.2 System Requirements for Mobile Information Device
Profile 15
4.1.3 System Requirements for J2ME Wireless Toolkit 15
4.2 Software Requirements and Dependencies 16
4.2.1 Software Requirements and Dependencies for CLDC 16
4.2.1.1 Software Requirements and Dependencies for Running CLDC Applications 16
4.2.1.2 Software Requirements and Dependencies for Developing CLDC Applications 16
4.2.1.3 Software Requirements and Dependencies for
Rebuilding CLDC 16
4.2.2 Software Requirements and Dependencies for MIDP 16
4.2.2.1 Software Requirements and Dependencies for Running MIDlet Suites 17
SUN MICROSYSTEMS, INC.
ii
Table of Contents
4.2.2.2 Software Requirements and Dependencies for Developing MIDlet Suites 17
4.2.2.3 Software Requirements and Dependencies for
Rebuilding MIDP 17
4.2.3 Software Requirements and Dependencies for the J2ME
Wireless Toolkit 17
4.2.4 Software Requirements and Dependencies for Wireless
Devices 17
5.0 Downloading, Installing, and Uninstalling CLDC 18
5.1 Downloading CLDC 18
5.2 Pre-installation Considerations 18
5.3 Installation Details 19
5.3.1 Default Installation Path for CLDC Binary Files 19
5.3.2 Changes to System Files 19
5.3.3 Directories Created When Installing CLDC 19
5.4 How to Install CLDC 20
5.4.1 Installing CLDC Package 1 20
5.4.2 Installing CLDC Package 2 21
5.4.3 Verifying the CLDC Installation 21
5.5 Uninstalling CLDC 21
6.0 Downloading, Installing, and Uninstalling MIDP 21
6.1 Downloading MIDP 21
6.2 Pre-installation Considerations 21
6.3 Installation Details 22
6.3.1 Default Installation Path for MIDP 22
6.3.2 Changes to System Files 22
6.3.3 Directories Created When Installing MIDP 22
6.4 How to Install MIDP 22
6.4.1 Installing the MIDP Package 22
6.4.2 Verifying the MIDP Installation 23
6.5 Uninstalling MIDP 23
7.0 Downloading, Installing, and Uninstalling the J2ME Wireless
Toolkit 23
7.1 Downloading the J2ME Wireless Toolkit 23
7.2 Pre-installation Considerations 23
7.3 Installation Details 24
7.3.1 Default Installation Path for the J2ME Wireless Toolkit 24
7.3.2 Changes to System Files 24
7.3.3 Directories Created When Installing the J2ME Wireless
Toolkit 24
7.4 How to Install the J2ME Wireless Toolkit 24
SUN MICROSYSTEMS, INC.
iii
Table of Contents
7.4.1 Installing the J2ME Wireless Toolkit as a Stand-alone Development Tool 25
7.4.2 Installing the J2ME Wireless Toolkit as a Plug-in to Forte for
Java 25
7.5 Verifying the J2ME Wireless Toolkit Installation 25
7.6 Common Problems with Installation 26
7.6.1 J2ME Wireless Toolkit Does Not Find J2SE Installation 26
7.6.2 The J2ME Wireless Toolkit Does Not Run from Forte for
Java 26
7.7 Uninstalling the J2ME Wireless Toolkit 26
8.0 Developing Applications with CLDC
26
8.1 The CLDC Specification 27
8.1.1 Application Management 27
8.1.2 CLDC Security 28
8.1.2.1 Low-Level Virtual Machine Security 28
8.1.2.2 Application Level Security 28
8.1.3 No Floating Point Support 29
8.1.4 No Finalization 29
8.1.5 Limited Error Handling 29
8.1.6 Limited Java Libraries 29
8.1.6.1 No Java Native Interface Support 29
8.1.6.2 No User-Defined Class Loaders 29
8.1.6.3 No Reflection 29
8.1.6.4 No Thread Groups or Daemon Threads 29
8.1.6.5 No Weak References 30
8.1.6.6 Internationalization and Localization Support 30
8.1.6.7 Generic Connection Framework – Input, Output, and
Networking Support 30
8.1.6.8 Garbage Collection 31
8.2 CLDC Application Development Cycle 31
8.2.1 Writing the CLDC Application 32
8.2.2 Compiling the CLDC Application 32
8.2.3 Preverifying the CLDC Application 33
8.2.4 Testing the CLDC Application on a Desktop System 34
8.2.5 Loading and Running the CLDC Application on a CLDC
Device 34
8.2.5.1 Loading and Running a CLDC Application on a Palm
Device 34
8.2.5.2 The Java Application Manager 35
8.3 Optimizing CLDC Applications 35
9.0 Developing Applications with MIDP
SUN MICROSYSTEMS, INC.
36
iv
Table of Contents
9.1 Language Features of MIDP 36
9.1.1 MIDP API Packages 36
9.1.2 MIDP Applications and Application Suites 37
9.1.3 MIDP User Interface Capabilities 37
9.1.4 MIDP Persistent Storage Capabilities 38
9.1.5 MIDP Input, Output, and Networking Capabilities 38
9.1.6 MIDP Timers 38
9.2 MIDlet States 38
9.3 MIDP Application Development Cycle 39
9.3.1 Writing the MIDlet 39
9.3.2 Compiling the MIDlet 40
9.3.3 Preverifying the MIDlet 41
9.3.4 Packaging the MIDlet in a JAR File 42
9.3.5 Writing the MIDlet Descriptor File 42
9.3.6 Testing the MIDlet on a Desktop System 43
9.4 Loading and Running a MIDlet on a Mobile Information
Device 44
9.5 Making HTTP Connections with MIDP 44
9.6 Optimizing MIDP Applications 44
10.0 Developing Applications with the J2ME Wireless Toolkit
44
10.1 Developing Applications with the J2ME Wireless Toolkit 45
10.2 Using the Emulator Available With the J2ME Wireless Toolkit 46
10.3 Customizing the J2ME Wireless Toolkit 47
11.0 Troubleshooting CLDC
48
11.1 Product Limitations 48
11.1.1Java Native Interface Not Supported by CLDC 48
11.1.2No End-to-End Security Available 48
11.2 Common Developer Questions 48
11.2.1Published Lists of Frequently Asked Questions 48
11.2.2Building the CLDC Executable Files 48
11.2.3Palm Development Questions 49
11.2.4Abstract Windowing Toolkit for CLDC 49
11.3 Troubleshooting Utilities 49
11.4 Known Bugs and Their Workarounds 50
12.0 Troubleshooting MIDP
50
12.1 Product Limitations 50
12.1.1Palm OS Implementation Not Available With MIDP
12.2 Common Developer Questions 50
12.2.1Published Lists of Frequently Asked Questions 50
12.2.2Building the MIDP Executable Files 50
12.2.3Running a MIDP Application in Color 51
SUN MICROSYSTEMS, INC.
50
v
Table of Contents
12.2.4Creating a Socket Connection 51
12.2.5Running MIDP Applications from Behind a Firewall
12.2.6Other Environment Variables 51
12.3 Troubleshooting Utilities 51
12.4 Common Developer Problems 51
12.5 Known Bugs and Their Workarounds 51
13.0 Troubleshooting the J2ME Wireless Toolkit
51
51
13.1 Product Limitations 51
13.1.1J2ME Wireless Toolkit Only Supported on Windows 98 52
13.1.2J2ME Wireless Toolkit Emulator Limitations 52
13.1.3No Source Level Debugging Available 52
13.1.4Pointer Devices Not Supported by Emulator 52
13.2 Common Developer Questions 52
13.2.1Published Lists of Frequently Asked Questions 52
13.2.2Problems Installing the J2ME Wireless Toolkit 53
13.2.3Displaying Japanese Characters 53
13.2.4Using the J2ME Wireless Toolkit to Develop Applications for
Palm OS 53
13.2.5Creating New Devices for the Emulator 53
13.2.6Creating an HTTP Connection 53
13.3 Troubleshooting Utilities 53
13.4 Known Bugs and Their Workarounds 54
14.0 Reference Information
54
14.1 Product Information 54
14.1.1CLDC Product Information and Downloads 54
14.1.2MIDP Product Information and Downloads 54
14.1.3J2ME Wireless Toolkit Product Information and
Downloads 54
14.1.4Other J2ME Information 55
14.1.5Information on Related Products 55
14.2 Frequently Asked Questions 55
14.3 Training Courses 55
14.4 Books, Articles, and Tutorials 55
14.4.1Books 55
14.4.2J2ME White Papers 55
14.4.3Java Developer Connection Articles and Tutorials
14.4.4Webcasts and Transcripts of Online Chats 56
14.4.5Palm Development Articles and Tutorials 57
SUN MICROSYSTEMS, INC.
56
vi
Preface
This document provides Support Readiness information for the Java 2 Platform, Micro
Edition: Connected Limited Device Configuration 1.0.2, Mobile Information Device
Profile 1.0.1, and J2ME Wireless Toolkit 1.0.1. The goal of Support Readiness
Documents (SRDs) is to help support engineers prepare to support Software Products
and Platforms Division products. SRDs are not designed to provide comprehensive
product training (see the product documentation or Sun Education for this). Instead,
they focus on issues immediately relevant to support, such as installation, configuration,
and common user problems.
The SRD for the Java 2 Platform, Micro Edition: Connected Limited Device
Configuration 1.0.2, Mobile Information Device Profile 1.0.1, and J2ME Wireless
Toolkit 1.0.1 can be viewed in PostScript or PDF format. The PDF version of the
document allows navigation via a table of contents frame, and the benefit of live cross
references and web links. Text that is underlined and in blue, such as the URL in this
paragraph, are clickable links in the PDF version of the document. (Note: page numbers
in the PDF document refer to printed pages, and will not coincide with the page
numbers in the PDF reader status bar.) Although the blue color and underlining appear
in the PostScript version, there are no live links when viewing that version.
Typographic Conventions
This document uses the following type conventions:
• The names of commands, files, Java™ objects, Java classes, and directories are
shown in regular monospace font.
• Text that is a placeholder to be replaced with a real name or value appears in italic
type; for example: % unzip jsdt-1.4.zip -d destination directory.
• Text that you type, when shown alongside computer output such as a command
prompt, is shown in bold monospace font. The marker "prompt>," in regular
monospace font, represents the actual command prompt you would see on your
screen, which may vary depending on your specific environment, shell, or platform.
For example: Solaris prompt> ls -l.
• The names of menu items, buttons, windows, and keyboard keys appear in regular
font with initial capitals, such as the Enter key.
• URLs that are clickable web links in the PDF version of the document are shown in
blue, underlined monospace font, as in http://java.sun.com. Although the blue
SUN MICROSYSTEMS, INC.
vii
Preface
color and underlining appears in the PostScript version, there are no live links when
viewing that version.
• URLs that are not clickable web links are shown in regular monospace font, such as
jsdt://stard:5555/socket/Session/chatSession.
• Cross-references to other sections of the document are shown in regular font but are
blue and underlined, as in, See Section 1.0, “JSDT Overview.” In the PDF version of
the document, these are clickable links to the indicated section. Although the blue
color and underlining appears in the PostScript version, there are no live links when
viewing that version.
• New terms and book titles appear in italic type.
SUN MICROSYSTEMS, INC.
viii
Support Readiness Document
Java 2 Platform, Micro Edition:
Connected Limited Device Configuration 1.0.2,
Mobile Information Device Profile 1.0.1, and
J2ME Wireless Toolkit 1.0.1
This document provides support readiness information for three products within the
Java™ 2 Platform, Micro Edition (J2ME™): Connected Limited Device Configuration
(CLDC), Mobile Information Device Profile (MIDP), and the J2ME Wireless Toolkit.
Of these three products, only the Wireless Toolkit is intended to be used primarily by
application developers. While CLDC and MIDP include binary reference
implementations, they are primarily source products intended to be ported to small,
wireless devices with limited memory and storage capacity. Implementations of CLDC
and MIDP are included with the J2ME Wireless Toolkit, and understanding of the
concepts involved with CLDC and MIDP is important when developing applications
with the J2ME Wireless Toolkit, hence, all three products are described in this
document.
1.0 Java 2 Platform, Micro Edition Overview
This section provides an overview of J2ME technology with an emphasis on those
aspects of the technology most related to application development with the J2ME
Wireless Toolkit for small, resource constrained wireless devices, such as cellular
telephones and personal digital assistants (PDAs).
J2ME is the edition of the Java 2 platform for consumer electronics and embedded
devices. The types of devices for which J2ME is designed are small, resource
constrained consumer and embedded devices such as mobile phones, PDAs, Internet
screenphones, digital television settop boxes, automotive entertainment and navigation
systems, network switches, and home automation components.
The J2ME technology consists of a Java virtual machine (JVM) and a set of Application
Programming Interfaces (APIs) suitable for providing tailored runtime environments for
consumer and embedded electronics. To support the vast array of products and their
associated capabilities, J2ME allows for several variations. These variations are
SUN MICROSYSTEMS, INC.
1 of 57
Java 2 Platform, Micro Edition Overview
provided through two layers of software built on top of the host operating system of the
device:
• Configuration Layer – The configuration layer defines the minimum set of Java
virtual machine features and Java class libraries available on a specific category of
devices. The configuration used for a particular device is based primarily on the
physical resources of the device.
The configuration layer includes an implementation of a Java virtual machine that is
customized for a particular device’s host operating system. The JVM that provides
the foundation for the J2ME that is used with the smallest devices is called the
KVM. The K indicates that the size of this JVM is small enough to be measured in
kilobytes.
• Profile Layer – The profile layer defines the minimum set of Application
Programming Interfaces (APIs) available on a specific type of device. The profile
used by a particular device is based on the functionality of the device.
J2ME profiles and configurations are defined for specified target devices by open
industry working groups using Sun’s Java Community ProcessSM(JCP). This allows
industry representatives to decide what elements are necessary to provide a complete
solution targeted at their industry. For more information on the Sun Community Process
Program see http://java.sun.com/aboutjava/communityprocess/.
1.1 K Virtual Machine
The K Virtual Machine (KVM) is a highly portable Java virtual machine designed for
small-memory, limited-resource, network-connected devices such as cellular phones,
pagers, and personal organizers. These devices typically contain 16- or 32-bit
processors and a minimum total memory footprint of approximately 128 KB.
The KVM was originally based on an API system called Spotless developed at Sun
Labs. Since it was developed, the KVM has been standardized through the JCP and
integrated in a configuration called Connected Limited Device Configuration (CLDC).
Since no J2ME profile was available when CLDC was first introduced, a set of Spotless
APIs was made available as the Palm Overlay. The combination of CLDC and Palm
Overlay provides application developers with an experimental Java runtime
environment that is not officially supported by Sun. Application developers requiring
support for J2ME on Palm OS should use MIDP for Palm OS, or the PDA profile when
they become available.
1.2 Configurations
A configuration defines the core runtime environment for J2ME implementations. It
specifies the capabilities of the Java virtual machine, a supported subset of J2SE classes,
and additional J2ME-specific classes.
Devices using J2ME technology can be roughly divided into two categories: devices
that are mobile, and devices that typically are fixed. The hardware and network
resources available to mobile devices tends to be more limited than for devices with an
ample supply of wall-power. Conversely, devices with easy access to power and wired
SUN MICROSYSTEMS, INC.
2 of 57
Java 2 Platform, Micro Edition Overview
network connections can take advantage of the wires to provide more power and
sophistication to the user.
Sun and the Java Community have defined two J2ME configurations:
• Connected Limited Device Configuration (CLDC) – intended to be used for mobile
devices. This configuration is described in detail in this document.
• Connected Device Configuration (CDC) – intended to be used for fixed devices. This
configuration is only described briefly in this document.
There is no plan to define more than these two configurations.
Configurations can be nested, so that any software able to execute on a less capable
configuration is able to execute on a more capable one. To ensure upward compatibility
between configurations, the CDC is a superset of the CLDC.
1.2.1 Connected Limited Device Configuration
The CLDC is a Java Community Process effort known as the Java Specification Request
000030 (JSR-30). It has standardized a portable, minimum-footprint Java building block
for small, resource-constrained devices. The CLDC configuration of J2ME provides for
a virtual machine and set of core libraries appropriate for use on small, wireless devices
such as cellular phones and PDAs. This configuration includes some new classes, not
drawn from the J2SE APIs, designed specifically to fit the needs of small-footprint
devices.
Target devices for CLDC are generally characterized as follows:
• 160 to 512 kilobytes of total memory, including both RAM and flash memory or
ROM, available for the Java platform and applications
• Limited power, often battery powered operation
• Connectivity to some kind of network, often with a wireless, intermittent connection
and with limited (often 9600 bps or less) bandwidth
• User interfaces with varying degrees of sophistication, including no interface at all
CLDC is base technology that defines the core virtual machine features and libraries
that all small, resource-constrained devices will share. CLDC runs on top of the KVM, a
Java virtual machine implementation designed specifically for small, resourceconstrained devices, and is a core component of the J2ME platform.
Sun provides a reference implementation of the CLDC for Solaris and Windows
operating environments. With CLDC 1.0.2 there is also a reference implementation for
Linux. A reference implementation is a non-commercial implementation of an API that
demonstrates a working example of the API. A reference implementation is intended to
familiarize developers with the API and the technology before developers make their
choice on commercial implementations. A reference implementation is used to
demonstrate that the specification can be implemented and that various compatibility
tests can be written against it.
SUN MICROSYSTEMS, INC.
3 of 57
Java 2 Platform, Micro Edition Overview
Sun has also created a CLDC compliant implementation for Palm OS handhelds. Sun
will allow application developers to redistribute this CLDC implementation with their
applications, together with a MIDP compliant implementation for Palm OS. The MIDP
implementation for Palm OS is scheduled to be released in the summer of 2001.
Third-party organizations have ported CLDC to several other devices. To facilitate the
porting process, Sun makes the source code of its reference implementation available
through the Sun Community Source License (SCSL). For licensing information, see
http://www.sun.com/communitysource/.
For more information about CLDC, see the CLDC product page available from
http://java.sun.com/products/cldc/.
The CLDC 1.0 specification is available for download from
http://java.sun.com/aboutJava/communityprocess/final/jsr030/
Sun’s reference implementation of CLDC is available from
http://www.sun.com/software/communitysource/j2me/download.html
1.2.2 Connected Device Configuration
The Connected Device Configuration (CDC) is designed for the market consisting of
shared, fixed, connected information devices. The devices targeted by the CDC typically
have the following characteristics:
• Permanent power source
• A minimum of 512 KB ROM and 256 KB RAM available for the Java platform and
applications
• Less limited processing power than is available on devices for which CLDC is the
appropriate configuration
• Permanent network connection
• Relatively constrained user interface
Screen phones, set-top boxes, and high-end PDAs are some of the devices that might be
supported by CDC. CDC technology uses a new virtual machine called CVM, where the
C stands for consumer or compact.
1.3 Profiles
A profile builds on a configuration by adding classes and specifying behaviors in
support of families of specific devices or types of applications. A profile can also build
on another profile.
A profile is a specification that details the Java technology APIs necessary to provide a
complete runtime environment for a specific kind of device. Both a profile and a
configuration are necessary to provide a complete runtime environment for a specific
kind of device.
A profile must be complete in the sense that an application written to the specification
can execute in the specified Java technology environment without the addition of other
SUN MICROSYSTEMS, INC.
4 of 57
Java 2 Platform, Micro Edition Overview
Java classes. Profiles provide flexibility to the Java community while still maintaining
portability across device types.
1.3.1 Mobile Information Device Profile
The Mobile Information Device Profile (MIDP or MID Profile) is a set of Java APIs
which, together with the CLDC, provides a complete J2ME application runtime
environment targeted at mobile information devices, such as low-to-mid range digital
cellular phones and two-way pagers. The MIDP specification addresses issues such as
user interface, persistence storage, networking, and application model.
Figure 1, “CLDC/MIDP Architecture,” shows the high level architecture of a device
running a MIDP application. It includes the following elements:
• Operating System – This is the operating system of the device; it provides the base
level of the architecture.
• CLDC/KVM – A device-specific implementation of CLDC runs on the device’s
operating system and includes an implementation of the KVM
• MID Profile – A device-specific implementation of MIDP runs on top of CLDC
• MID Profile Application – Most MIDP applications make use of the MIDP APIs,
although some MIDP applications may need only CLDC APIs.
• OEM Specific APIs – Device manufacturers often create APIs specific to their
devices, some of which may run on CLDC or MIDP.
• OEM Applications – Device manufacturers are free to create applications that run
directly on the device’s operating system or that use their own device-specific APIs.
Note: The OEM applications shown in the diagram are designed to run only on the
specific device. MIDP applications should run on any device with fully compliant
CLDC and MIDP implementations.
Figure 1.
CLDC/MIDP Architecture
SUN MICROSYSTEMS, INC.
5 of 57
Java 2 Platform, Micro Edition Overview
A MIDP application is known as a MIDlet. A MIDlet can be developed using the J2ME
Wireless Toolkit, Sun’s reference implementations of CLDC and MIDP, or compliant
implementations available primarily from device manufacturers. Some CLDC and
MIDP implementations are listed in Section 1.4.4, “Other CLDC and MIDP
Implementations.”
The reference implementations of CLDC and MIDP available from Sun run on desktop
systems. For a MIDlet to run on a mobile information device, there must be
implementations of CLDC and MIDP available for the target device. Sun provides
source code licensing to allow development of CLDC and MIDP implementations for
mobile information devices. Additionally, Sun plans to release an implementation of
MIDP for the Palm OS in the second quarter of 2001.
1.3.2 Personal Digital Assistant Profile
A Java Specification Request (JSR) submitted by Palm Computing for a PDA Profile
has been approved by the J2ME JCP Executive Committee and is in the process of being
defined though Sun’s Java Community ProcessSM Program. The PDA Profile will
support PDA devices and will build on top of the CLDC. While an implementation of
MIDP is being developed for the Palm OS, the PDA profile expert group believes PDA
type devices would benefit from the development of additional APIs that would take full
advantage of these devices’ capabilities, such as enhanced database access and user
interface navigation system.
The PDA Profile is expected to be completed by the end of 2001. Since Palm
Computing is the lead organization in this effort, they will be expected to provide a
reference implementation and Technology Core Platform Compatibility Kit (TCK) for
the PDA Profile. For more information, see http://java.sun.com/aboutJava/
communityprocess/jsr/jsr_075_pda.html.
1.3.3 Personal Profile
The Personal Profile is being defined through the JCP. It will be built on top of the CDC.
The Personal Profile, in combination with the CDC, and the Foundation Profile, will
provide 100% backwards compatibility with the PersonalJava™ application
environment. The Personal Profile is slated for release in early 2001. For more
information, see http://java.sun.com/aboutJava/communityprocess/
jsr/jsr_062_pprof.html.
1.3.4 Foundation Profile
The Foundation Profile is a set of APIs targeted at emerging, next generation consumer
electronic, wireless, and embedded devices. The Foundation Profile is designed to work
in conjunction with the CDC. For more information, see
http://java.sun.com/aboutJava/communityprocess/first/jsr046/.
1.3.5 Remote Method Invocation Profile
The Remote Method Invocation (RMI) Profile is being built on top of the CDC Profile.
The API for the RMI Profile for J2ME is the minimal subset of the J2SE 1.3 RMI API
that may be used with J2ME. For more information, see
http://java.sun.com/aboutJava/communityprocess/review/jsr066/.
SUN MICROSYSTEMS, INC.
6 of 57
Java 2 Platform, Micro Edition Overview
1.3.6 Other Profiles
Other profiles are being discussed and may be developed in the future. These include the
Automotive Profile and the TV Profile.
1.4 Implementations of CLDC and MIDP
1.4.1 Reference Implementations from Sun
Sun provides separate reference implementations for CLDC and MIDP that run on
desktop systems. Details of these reference implementations are described in this
document.
For specific support information on CLDC, see:
• Section 5.0, “Downloading, Installing, and Uninstalling CLDC”
• Section 8.0, “Developing Applications with CLDC”
• Section 11.0, “Troubleshooting CLDC”
For specific support information on MIDP, see:
• Section 6.0, “Downloading, Installing, and Uninstalling MIDP”
• Section 9.0, “Developing Applications with MIDP”
• Section 12.0, “Troubleshooting MIDP”
1.4.2 J2ME Wireless Toolkit
Sun provides an integrated development tool for creating MIDP applications from a
desktop system: the J2ME Wireless Toolkit. This tool includes implementations of
CLDC and MIDP that are essentially the same as the reference implementations. The
J2ME Wireless Toolkit provides tools for developing and testing MIDP applications and
assists the developer in creating the files required to test and deploy the application. It
includes a bytecode preverifier and an emulation environment. Bytecode preverification
is an essential step in providing security when using CLDC and MIDP and is discussed
in Section 8.1.2, “CLDC Security.”
The Wireless Toolkit can be used as a stand-alone development tool or as a plug-in to
Forte™ for Java. Forte for Java is a comprehensive integrated development environment
(IDE) for Java application development. For more information about Forte for Java, see
http://www.sun.com/forte/ffj/.
For specific support information on the Wireless Toolkit, see:
• Section 7.0, “Downloading, Installing, and Uninstalling the J2ME Wireless Toolkit”
• Section 10.0, “Developing Applications with the J2ME Wireless Toolkit”
• Section 13.0, “Troubleshooting the J2ME Wireless Toolkit”
1.4.3 MIDP for Devices Using the Palm OS
Sun will release an implementation of MIDP for the Palm OS in the summer quarter of
2001. The Early Access release will be available in the second quarter of 2001. This
implementation will work on any PDA with flashable memory and Palm OS version 3.5
SUN MICROSYSTEMS, INC.
7 of 57
Java 2 Platform, Micro Edition Overview
or greater. A future release of the J2ME Wireless Toolkit may include emulation
capabilities for Palm OS devices, allowing application developers to build and test
MIDP applications for the Palm OS from a desktop system.
1.4.4 Other CLDC and MIDP Implementations
Several device manufacturers have created J2ME implementations for their mobile
information devices. These include:
• Motorola’s implementation, available from
http://www.motorola.com/java/
• Research in Motion (RIM)’s implementation, available from
http://developers.rim.net/handhelds/
Sun technology evangelist Bill Day maintains a list of J2ME implementations in his
J2ME Archive available from http://www.billday.com/j2me/
1.5 Related Technologies
1.5.1 Wireless Application Protocol
The Wireless Application Protocol (WAP) is a standard for presenting and delivering
wireless information and telephony services on mobile phones and other wireless
devices. WAP is based on the premise that wireless devices and wireless device
networks are not robust enough to handle HyperText Markup Language (HTML)
documents available on the Internet. To help bring the Internet to wireless devices,
software company Phone.com developed the Handheld Device Markup Language
(HDML). Phone.com and three cellular phone manufacturers, Motorola, Nokia, and
Ericsson, devised a standardized language based on HDML called Wireless Markup
Language (WML). The WAP specifications require the use of WML for information
transfer.
When a person with a WAP-enabled cell phone accesses a website, the request is
transferred to a server maintained by the wireless network. On the server, a software
filter called a WAP gateway is used to translate the web page from HTML to WML. The
WML document is transmitted to the cell phone, where the information is presented on
the cell phone’s screen.
J2ME leverages existing browser-based technologies such as WAP or i-mode’s Compact
HTML, but brings additional benefits that are not currently available in mobile devices.
Sun is an active member of the WAP Forum and has proposed the development of Java
APIs that would leverage the WAP specification to this industry association. Sun is also
involved in several deployment projects requiring the integration of J2ME with WML
and HDML microbrowsers.
A browser interface is convenient to access static information, such as news and sports
scores, or to display a list of applications and services. Java technology can provide
interactive or transaction-oriented applications and services such as mobile commerce
(m-commerce) and games that the user can continue to interact with even while
disconnected from the network.
SUN MICROSYSTEMS, INC.
8 of 57
Java 2 Platform, Micro Edition Overview
More information on WAP is available from the WAP Forum homepage:
http://www.wapforum.org/.
For an article in the Scientific American by Karen J. Bannan entitled “The Promise and
Perils of WAP” see
http://www.sciam.com/2000/1000issue/1000bannan.html.
For an article in JavaWorld by Quasay H. Mahmoud entitled “WAP for Java developers:
Develop WAP applications with Java servlets and JSP” see
http://www.javaworld.com/javaworld/jw-06-2000/jw-0602-wap.html.
1.5.2 PersonalJava
The PersonalJava application environment was the first J2ME technology and is used
with devices requiring full web fidelity. The current generation of the PersonalJava
application environment, version 3.1, is based on a JDK™ 1.1 code base. The next
release of PersonalJava will be based on the CDC, the Foundation Profile, and the
Personal Profile, and will provide full compatibility for applications written to the
PersonalJava runtime specification. For more information, see
http://java.sun.com/products/personaljava/.
1.5.3 JavaPhone
The JavaPhone™ API is an extension of the PersonalJava platform. It defines a set of
APIs targeted at wireless devices with more physical resources than the devices targeted
by MIDP. The JavaPhone API was developed prior to the formalized JCP process, but
included widespread industry participation.
Note: The MID Profile is different from the JavaPhone API. The JavaPhone API defines
a set of APIs targeted at higher end wireless devices and covers functionality such as
direct telephony control, datagram messaging, and power monitoring. For more
information on JavaPhone, see http://java.sun.com/products/javaphone/.
1.5.4 EmbeddedJava
EmbeddedJava™ technology provides licensing terms and tools to vendors who want to
incorporate Java technology in their devices, but do not require a platform-based
solution. EmbeddedJava technology allows such vendors to use Java libraries outside of
a J2ME profile, but only for closed, “black box” solutions where an API is not exposed.
For more information, see http://java.sun.com/products/embeddedjava/.
1.5.5 Java Card
Java Card™ technology provides a Java environment for the smallest platform: smart
cards and other such severely resource constrained devices. The Java Card API allows
applications written for one smart card platform enabled with Java Card technology to
run on any other such platform. For more information on Java Card, see
http://java.sun.com/products/javacard/.
SUN MICROSYSTEMS, INC.
9 of 57
Product Changes in Current Versions of CLDC, MIDP, and the J2ME Wireless
1.6 Pointers to Tutorials and Other Product Materials
1.6.1 Product Homepages
The J2ME homepage contains introductory material on J2ME and links to more
information. The J2ME homepage can be found at http://java.sun.com/j2me/
The CLDC homepage contains introductory material on CLDC and includes links to
more information. The CLDC homepage can be found at
http://java.sun.com/products/cldc/
The MIDP homepage contains introductory material on MIDP and includes links to
more information. The MIDP homepage can be found at
http://java.sun.com/products/midp/
The J2ME Wireless Toolkit homepage contains introductory material on the Wireless
Toolkit and includes links to more information. The Wireless Toolkit homepage can be
found at http://java.sun.com/products/j2mewtoolkit/
1.6.2 Tutorials
The staff of the Java Developer ConnectionSM (JDC) is creating a series of articles
providing tutorials on various aspects of wireless programming using J2ME. These
articles are available from
http://developer.java.sun.com/developer/technicalArticles/
wireless/
1.6.3 Training Course Information
Sun’s Market Development and Developer Relations department provides hands-on
classes called code camps on several products. A code camp is available for J2ME
Wireless Programming. Information on the code camp is available from
http://www.sun.com/developers/edu/camps/. The code camp materials can
be downloaded from this site.
2.0 Product Changes in Current Versions of CLDC,
MIDP, and the J2ME Wireless Toolkit
2.1 CLDC Releases
There have been several releases of CLDC:
• CLDC 1.0 is the release available to the public and will be available as the default
public release through January 2001.
• CLDC 1.0.1 was made available to a limited set of partners in November 2000. It
was never made available to the public, but can be accessed from the licensee
website.
• CLDC 1.1 Beta was made available to a limited set of partners in January 2001. It
will be renamed as CLDC 1.0.2 when it is released to the public in February 2001.
SUN MICROSYSTEMS, INC.
10 of 57
Product Changes in Current Versions of CLDC, MIDP, and the J2ME Wireless
2.1.1 New Features in CLDC 1.0.2
The primary new features in CLDC 1.0.2 are:
• New exact and compacting garbage collector
The compacting garbage collector is configurable. Compaction can be disabled on
platforms that have a segmented, non-contiguous memory architecture such as the
Palm OS.
• Java-level debugging support using the KVM Debug Wire Protocol (KDWP)
interface, a subset of the Java Debug Wire Protocol (JDWP)
The Java-level debugging APIs allow the KVM to be plugged into a third-party,
source-level Java debugger such as Forte for Java or CodeWarrior.
• Various configurable performance optimizations
• Redesigned interpreter
• Preverifier enhancements with JAR support and improved checks for the correct use
of CLDC libraries
• Linux port
• Bug fixes from CLDC 1.0.1
The impact of these features on the developer are summarized in the KVM Porting
Guide, which is included as part of the documentation for this release. There are no
changes to the CLDC 1.0 Specification.
For the most current information, please refer to the release notes available in the docs
directory of the CLDC download.
2.1.2 Bugs Fixed in CLDC 1.0.2
Bugs fixed in this release are listed in the release notes available with the product
download. For a list of current bugs and bugs fixed in CLDC 1.0.2, check the Bug
Parade, available from
http://developer.java.sun.com/developer/bugParade/. Choose the
category K Virtual Machine.
2.1.3 Backward and Forward Compatibility with Other Versions of CLDC
There are no known compatibility issues between versions of CLDC.
2.2 MIDP Releases
The release of MIDP available to the public through January 2001 is version 1.0. MIDP
1.0.1 is to be released late January 2001.
2.2.1 New Features in MIDP 1.0.1
The primary changes in MIDP 1.0.1 relate to internationalization and localization.
Internationalization support is available in MIDP 1.0 through the use of Readers and
Writers for input and output. The changes to internationalization, especially with
input, enable the use of the underlying Windows system input methods. This makes it
possible for the MIDP application to input and output characters in many locales. This
feature was only available in English in version 1.0.
SUN MICROSYSTEMS, INC.
11 of 57
Product Changes in Current Versions of CLDC, MIDP, and the J2ME Wireless
There are no specification or API changes for MIDP 1.0.1.
2.2.2 Bugs Fixed in MIDP 1.0.1
Bugs fixed in this release are listed in the release notes available with the product
download. For a list of current bugs and bugs fixed in MIDP 1.0.1, check the Bug
Parade, available from
http://developer.java.sun.com/developer/bugParade/. Choose the
category JSR-31 Specification and RI.
2.2.3 Backward and Forward Compatibility with Other Versions of MIDP
There are no known compatibility issues between versions of MIDP.
2.3 J2ME Wireless Toolkit Releases
J2ME Wireless Toolkit 1.0 is based on CLDC 1.0 and MIDP 1.0. The changes made in
CLDC 1.0.1 and MIDP 1.0.1 will be reflected in the J2ME Wireless Toolkit 1.0.1. J2ME
Wireless Toolkit 1.0.1 will be released in February 2001.
2.3.1 New Features in the J2ME Wireless Toolkit 1.0.1
The main features of J2ME Wireless Toolkit 1.0.1 are:
• Features are aligned with MIDP 1.0.1
• Internationalization output adjusts fonts to support the correct locale.
• Internationalization input can now be used in a Swing text box. In version 1.0, the
input methods of the underlying Windows system were used for text input. With
version 1.0.1, a MIDP application can input any text that a Swing text box can input.
• Integrates with new MIDP 1.0.1 emulator skin
• Supports pointer events for the Canvas class
A complete list of changes and new features is available in the release notes. The release
notes are in the file BinaryReleaseNotes.html available at the root of the
installation directory after installing the download file.
2.3.2 Bugs Fixed in the J2ME Wireless Toolkit 1.0.1
Bugs fixed in this release are listed in the release notes available with the product
download.
2.3.3 Backward and Forward Compatibility with Other Versions of the J2ME
Wireless Toolkit
There are no known compatibility issues between versions of the J2ME Wireless
Toolkit.
SUN MICROSYSTEMS, INC.
12 of 57
Product Distribution and Licensing
3.0 Product Distribution and Licensing
3.1 Free Product and Specification Downloads
This document covers three products: CLDC, MIDP, and the J2ME Wireless Toolkit.
The products are free can be downloaded from the following locations:
• CLDC
Specification can be downloaded from:
http://java.sun.com/aboutJava/communityprocess/final/jsr030/
Source and binary files can be downloaded from:
http://www.sun.com/software/communitysource/j2me/
download.html
• MIDP
Specification can be downloaded from:
http://java.sun.com/aboutJava/communityprocess/final/jsr037/
Source and binary files can be downloaded from:
http://www.sun.com/software/communitysource/midp/
download.html
• J2ME Wireless Toolkit
Binary product can be downloaded from:
http://java.sun.com/products/j2mewtoolkit/download.html
3.2 Physical Media
A CD-ROM containing many resources for developing with J2ME, including source
and binary files and documentation, is available from the Sun Developer Essentials™
program of the Sun Developer Connection. This CD-ROM is updated on a regular basis,
but does not include the final material for CLDC, MIDP, or the J2ME Wireless Toolkit
at this time. For more information, see
http://www.sun.com/developers/tools/j2me.html.
3.3 International Distribution
Due to limited intellectual property protection and enforcement in certain countries, the
source code may only be distributed to an authorized list of countries. Countries
authorized to receive source code are listed at
http://www.sun.com/software/communitysource/countries.html. You
will not be able to access the source code if you are downloading from a country that is
not on this list. Sun is continuously reviewing this list for addition of other countries.
3.4 Product Licensing
3.4.1 Binary Product
The binary versions of CLDC, MIDP, and the J2ME Wireless Toolkit may be used
freely after agreeing to the license agreement that appears when downloading the
product.
SUN MICROSYSTEMS, INC.
13 of 57
Requirements and Dependencies
3.4.2 Redistribution of Binary Product
Redistribution of the binary product is not currently authorized except to partners, such
as development tool vendors, who have signed a specific license agreement.
Sun is preparing a special redistribution license agreement for the MIDP compliant
implementation for the Palm OS. Commercial terms are not yet finalized, but this
license agreement will allow application developers to redistribute the MIDP
implementation with their applications targeted at Palm OS handhelds.
3.4.3 Source Code License
CLDC and MIDP are source code products that are provided for porting to various
platforms. The source code of the CLDC and MIDP reference implementations is
available under the Sun Community Licensing Agreement (SCSL). The source code is
available free of charge for research and education purposes, but you will need to sign a
commercial license agreement with Sun if you intend to redistribute code for
commercial purposes. As part of any commercial use agreement, it is necessary to pass
compatibility tests that ensure a standardized Java application environment. The
technology compatibility toolkit (TCK) for CLDC and for MIDP can be licensed from
Sun separately. For more information about commercial licensing terms please contact a
sales representative found on http://www.sun.com/software/sales/.
The J2ME Wireless Toolkit source code is available for commercial licensees of the
CLDC and MIDP reference implementations.
4.0 Requirements and Dependencies
4.1 System Requirements and Dependencies
4.1.1 System Requirements for Connected Limited Device Configuration
The CLDC is intended to be ported to devices with limited hardware resources. The
reference implementation is designed to run on a desktop system. The CLDC reference
implementation is available for the following platforms:
• Solaris™/SPARC™ – Solaris 2.6, Solaris 7, and Solaris 8 on SPARC hardware
• Win32 – Windows 95, 98, NT 4.0, and 2000 on Intel hardware
• Palm OS – Palm devices
The Palm OS package can be used as an overlay on Solaris/SPARC and on Win32 to
create applications for the Palm OS.
Note: The Palm OS implementation of CLDC is an unsupported, proof-of-concept
implementation.
When running CLDC on a desktop system, Java 2 Standard Edition (J2SE) must also be
installed. Any system with the minimum configuration required for J2SE will be able to
run CLDC.
The uncompressed CLDC download package requires an additional 12 MB of disk
space.
SUN MICROSYSTEMS, INC.
14 of 57
Requirements and Dependencies
A CLDC implementation for a resource constrained device requires a minimum total
memory budget of about 128 KB, including the virtual machine, the minimum Java
class libraries specified by the configuration, and some heap space for running Java
applications. A more typical implementation requires 160 to 512 KB of total memory
available for the Java platform, of which approximately 128 KB are used for the CLDC
platform (KVM plus libraries). The static size of the KVM core is 50 to 80 KB
depending on the platform and compilation options. This size estimate does not take
into consideration romizing, which is described briefly in Section 8.3, “Optimizing
CLDC Applications.”
The ratio between volatile memory (for example, DRAM) and non-volatile memory (for
example, ROM or Flash) in the total memory budget configuration varies depending on
the implementation. A simple KVM implementation without system class prelinking
support needs more volatile memory than a KVM implementation with system classes
or applications preloaded into the device.
4.1.2 System Requirements for Mobile Information Device Profile
The MIDP is intended to be ported to mobile information devices with limited hardware
resources. The reference implementation is designed to run on a desktop system. The
MIDP reference implementation is available for the Win32 platform only. The same
system configurations defined for the CLDC in Section 4.1.1, “System Requirements
for Connected Limited Device Configuration,” are required for MIDP.
The uncompressed MIDP download package requires an additional 10 MB of disk
space.
Note: An unsupported Solaris port is available for MIDP. It is included with the MIDP
reference implementation product download.
4.1.3 System Requirements for J2ME Wireless Toolkit
The J2ME Wireless Toolkit is a development tool designed to be used on a desktop
system and is supported on Windows 98 only. It can be installed and used on Windows
NT and 2000, but it has only been tested thoroughly on Windows 98.
Note: The J2ME Wireless Toolkit cannot be used on Windows 95.
The J2ME Wireless Toolkit can be used alone or in combination with Forte for Java to
provide a complete development environment.
When the Wireless Toolkit is used alone, it requires the following minimum system
configuration:
• Minimum processor – 166 MHz
• Recommended RAM – 64 MB
• Disk space – 15 MB
When the J2ME Wireless Toolkit is used in combination with Forte for Java, the
following minimum system configuration is required for the combined products:
• Minimum processor – Pentium II, 300 MHz
SUN MICROSYSTEMS, INC.
15 of 57
Requirements and Dependencies
• Minimum RAM – 128 MB
• Recommended RAM – 192 MB
• Disk space – 30 MB
4.2 Software Requirements and Dependencies
J2ME products that run on desktop systems are intended for software development and
require tools from the Java 2 Platform Standard Edition (J2SE) Software Development
Kit (SDK). The J2SE SDK can be downloaded from http://java.sun.com/j2se/.
4.2.1 Software Requirements and Dependencies for CLDC
The software requirements for CLDC depend on how you intend to use CLDC.
4.2.1.1 Software Requirements and Dependencies for Running CLDC
Applications
To run a CLDC application on a desktop system, the following is required:
• The CLDC reference implementation
The binary code provided with the download is all that is needed to run a CLDC
application.
Note: Applications should be created using CLDC in combination with a profile such as
MIDP. Such applications will also require the binary code for the profile.
4.2.1.2 Software Requirements and Dependencies for Developing CLDC
Applications
To develop CLDC applications, the following is required:
• The CLDC reference implementation
The binary code provided with the download is used to develop a CLDC application.
• J2SE SDK version 1.2 or greater
The compiler and JAR tools of the J2SE SDK are needed to compile the CLDC
application.
Note: A profile such as MIDP should be used with CLDC when developing
applications.
4.2.1.3 Software Requirements and Dependencies for Rebuilding CLDC
To rebuild the CLDC release, the following is required:
• The CLDC reference implementation
• J2SE SDK Version 1.2 or greater
• C compiler and shell tools as described in the release notes
4.2.2 Software Requirements and Dependencies for MIDP
The software requirements for MIDP depend on how you intend to use MIDP.
SUN MICROSYSTEMS, INC.
16 of 57
Requirements and Dependencies
4.2.2.1 Software Requirements and Dependencies for Running MIDlet Suites
To run a MIDlet suite on a desktop system, the following is required:
• The MIDP reference implementation
The binary code provided with the download is all that is needed to run a MIDlet
suite.
4.2.2.2 Software Requirements and Dependencies for Developing MIDlet Suites
To develop MIDlet suites, the following is required:
• The MIDP reference implementation
The binary code provided with the download is used to develop a MIDlet suite.
• J2SE SDK Version 1.2 or greater
The compiler and JAR tools of the J2SE SDK are needed to compile the MIDlet.
4.2.2.3 Software Requirements and Dependencies for Rebuilding MIDP
To rebuild the MIDP release, the following is required:
•
•
•
•
The MIDP reference implementation
J2SE SDK version 1.2 or greater
CLDC
C compiler and shell tools as described in the release notes
4.2.3 Software Requirements and Dependencies for the J2ME Wireless Toolkit
To install and run the J2ME Wireless Toolkit as a standalone application (without Forte
for Java), the following software must be installed before the J2ME Wireless Toolkit can
be installed:
• J2SE SDK, version 1.3 or greater
To install and run the J2ME Wireless Toolkit with Forte for Java, the following software
must be installed before the J2ME Wireless Toolkit can be installed:
• J2SE SDK – version 1.3 or greater
• Forte for Java – When using the Forte for Java, Community Edition, use version 1.0
Update Release 2 or greater, downloadable from
http://www.sun.com/forte/ffj/ce/.
4.2.4 Software Requirements and Dependencies for Wireless Devices
Consumer devices contain an operating system. Operating system vendors are generally
responsible for creating implementations of the CLDC and MIDP Specifications to
allow CLDC and MIDP applications to run on their platforms. Applications created
with the CLDC and MIDP reference implementations should run on any device with a
fully compliant CLDC and MIDP implementation.
SUN MICROSYSTEMS, INC.
17 of 57
Downloading, Installing, and Uninstalling CLDC
5.0 Downloading, Installing, and Uninstalling CLDC
The instructions in this section include the names of the download files for CLDC 1.0.
These names will change appropriately when CLDC 1.0.2 is available for public
download.
Note: All instructions in this section were written for CLDC 1.0.
5.1 Downloading CLDC
The CLDC source code and reference implementation can be downloaded free from
http://www.sun.com/software/communitysource/j2me/download.html.
Before you can download the product, you must first register or log into the Sun
Download Center and agree to the license agreement.
When you reach the Download Area, click the link J2ME CLDC FCS 1.0, and you will
see two packages available for download. The CLDC release contains a reference
implementation for Win32 and Solaris, and a compatible Palm OS implementation that
is provided to demonstrate optimization techniques suitable for small devices.
Package 1, j2me_cldc-1_0-src-winsol.zip, contains the CLDC reference
implementation for both the Win32 and Solaris platforms. This package includes the
source code and binary code for CLDC, as well as tools and documentation intended to
assist you in porting the CLDC implementation to new devices. When developing Java
applications, the CLDC reference implementation should be used with a profile such as
MIDP. The file, j2me_cldc-1_0-src-winsol.zip, is 4.80 MB.
Package 2, j2me_cldc-1_0-src-palm_overlay.zip, includes a set of
unsupported, proof of concept APIs made available to let developers evaluate what a full
runtime environment based on CLDC would look like on Palm OS handhelds.
Application developers requiring support for J2ME on Palm OS should be directed to
MIDP for Palm OS, or to the PDA Profile when they are available.
Package 2 can be installed on top of Package 1. The file,
j2me_cldc-1_0-src-palm_overlay.zip, is 0.52 MB.
Note: Package 2 is not intended to be used separately. If you plan to install Package 2,
you should download Package 1 as well. Package 1 must be installed before installing
Package 2.
5.2 Pre-installation Considerations
Be sure that a supported version of the Java 2 SDK is installed prior to using CLDC for
application development. CLDC requires version 1.2 or later. The order of installation is
not important.
SUN MICROSYSTEMS, INC.
18 of 57
Downloading, Installing, and Uninstalling CLDC
5.3 Installation Details
5.3.1 Default Installation Path for CLDC Binary Files
For CLDC and MIDP, installing the binary files involves extracting compressed files
only. There is no default installation path, but it is recommended that you create a
directory called J2ME which will include a directory for CLDC and a directory for
MIDP. For example, on a Win32 system:
C:\J2ME
|
CLDC
|
MIDP
Note: When building both CLDC and MIDP, the MIDP makefiles assume that the
CLDC is found in a directory named kvm that is at the same level as the MIDP
hierarchy. The makefiles can be configured to use a different name, but using the name
kvm will make the directions in the release notes easier to follow. To make version
dependencies clear, you may want to include version numbers in top level directory
names.
5.3.2 Changes to System Files
Installing the CLDC binary files involves extracting compressed files only. The
installation does not make any changes to system files.
5.3.3 Directories Created When Installing CLDC
When the CLDC download file for Package 1 (j2me_cldc-1_0-src-winsol.zip)
is uncompressed, the directory j2me_cldc is created. It may be convenient to create an
environment variable called CLDC_HOME that points to the root of the installation
directory, C:\J2ME\j2me_cldc.
Within the j2me_cldc directory, the following subdirectories are created:
• api – Contains Java source files for CLDC in the following packages:
• java.io – Provides for system input and output through data streams
• java.lang – Provides classes that are fundamental to the design of the Java
programming language
• java.util – Contains the collections framework, legacy collection classes,
date and time facilities, and miscellaneous utility classes
• javax.microedition.io – Provides classes for generic connections
• com.sun.kjava – GUI and database classes; not officially part of the CLDC
reference implementation. Provided to facilitate porting and testing; may change
or may be removed in future releases.
• com.sun.cldc.io – storage and network protocol implementations; not
officially part of the CLDC reference implementation. Provided to facilitate
porting and testing; may change or may be removed in future releases.
• bin – Contains all the binary executables and compiled Java library classes:
• CLDC binary file – kvm for Solaris and kvm.exe for Win32
• Preverify tool – preverify for Solaris and preverify.exe for Win32
SUN MICROSYSTEMS, INC.
19 of 57
Downloading, Installing, and Uninstalling CLDC
• Compiled Java .class files for CLDC in the subdirectory api
• Sample code in the subdirectory samples
• build – Contains the makefiles for building CLDC
• docs – Contains documentation including:
• Release Notes – Includes instructions for building the source release
• CLDC Specification – Defines the CLDC for device manufacturers who want to
build small Java-enabled devices and content developers who want to write Java
applications for small, resource constrained devices.
• CLDC API Documentation – Provides information on all packages included in
the CLDC reference implementation
• KVM API Documentation – Includes information on the package
com.sun.kjava, not officially part of the CLDC reference implementation
• KVM Porting Guide – Provides information for porting the KVM reference
implementation to a new platform
• jam – Contains the source code for the optional Java Application Manager (JAM)
component that is provided with the KVM
• kvm – Contains the source code of the KVM
• samples – Contains the source code and icons of a number of sample applications
• tools – Contains the source code and icons of the tools JavaCodeCompact and
preverifier.
When the CLDC download file for Package 2 (j2me_cldc-1_0-srcpalm_overlay.zip) is uncompressed, files are added to the directories listed above.
5.4 How to Install CLDC
There are two packages you can download from the CLDC download page.
• Package 1 includes the source and the binary files for the reference implementation
for use on Solaris or Win32.
• Package 2 contains a CLDC-compatible port for the Palm Connected Organizer. It
includes the binary files and tools for using CLDC on the Palm OS. If you plan to
install Package 2, install Package 1 first.
5.4.1 Installing CLDC Package 1
Extract the download file, j2me_cldc-1_0-src-winsol.zip, using a utility
program such as WinZip on Win32 systems. In this document, the download file is
assumed to have been extracted to the directory J2ME. The directories listed in
Section 5.3.3, “Directories Created When Installing CLDC,” are created.
Note: Chapter 2 of the release notes distributed with CLDC is entitled “Installation
Notes.” This chapter explains how to build the source release. Building the source
release is not necessary if you plan to use the binary CLDC files only. These binary files
are already built and are available with the download package. The binary files are
located in the bin directory.
SUN MICROSYSTEMS, INC.
20 of 57
Downloading, Installing, and Uninstalling MIDP
5.4.2 Installing CLDC Package 2
Package 2 is not intended to be used separately. If you plan to install Package 2, you
should install Package 1 first.
Extract the download file, j2me_cldc-1_0-src-palm_overlay.zip, using a utility
program such as WinZip on Win32 systems, noting the following:
• Extract to the directory j2me_cldc created when Package 1 was installed.
• Be sure to use the overwrite option.
No new directories are created when extracting Package 2 with the overwrite option;
files are added to the directories created when extracting Package 1.
5.4.3 Verifying the CLDC Installation
To verify the CLDC installation, create and run an application as described in
Section 8.2, “CLDC Application Development Cycle.”
5.5 Uninstalling CLDC
To uninstall CLDC, simply remove the CLDC installation directory and its contents.
6.0 Downloading, Installing, and Uninstalling MIDP
The instructions in this section include the names of the download files for MIDP 1.0.
These names will change appropriately when MIDP 1.0.1 is available for public
download.
Note: All instructions in this section were written for MIDP 1.0.
6.1 Downloading MIDP
The MIDP source code and reference implementation can be downloaded free from
http://www.sun.com/software/communitysource/midp/download.html.
Before you can download the product, you must first register or log into the Sun
Download Center and agree to the license agreement.
When you reach the Download Area, click the link Mobile Information Device Profile,
and you will see the package available for download. The MIDP release currently
contains a reference implementation for Win32 only. The download package is called
j2me_midp-1_0-fcs-bin-b10-win-15_sep_2000.zip and is 2.48 MB.
6.2 Pre-installation Considerations
Be sure that a supported version of the Java 2 SDK is installed prior to using MIDP.
MIDP requires version 1.2 or later.
Be sure that CLDC is installed prior to using MIDP. The order of installation is not
important.
SUN MICROSYSTEMS, INC.
21 of 57
Downloading, Installing, and Uninstalling MIDP
6.3 Installation Details
6.3.1 Default Installation Path for MIDP
For MIDP, installing the binary files involves extracting compressed files only. There is
no default installation path, but it is recommended that you create a directory called
J2ME which will include a directory for CLDC and a directory for MIDP. For example,
on a Win32 system:
C:\J2ME
|
CLDC
|
MIDP
Note: When building both CLDC and MIDP, the MIDP makefiles assume that the
CLDC is found in a directory named kvm that is at the same level as the MIDP
hierarchy. The makefiles can be configured to use a different name, but using the name
kvm will make the directions in the release notes easier to follow. To make version
dependencies clear, you may want to include version numbers in top level directory
names.
6.3.2 Changes to System Files
Installing the MIDP binary files involves extracting compressed files only. The
installation does not make any changes to system files.
6.3.3 Directories Created When Installing MIDP
When the MIDP download file is uncompressed, the directory midp-fcs is created. It
may be convenient to create an environment variable called MIDP_HOME that points to
the root of the installation directory, C:\J2ME\midp-fcs.
Within the midp-fcs directory, the following subdirectories are created:
• bin – Contains the MIDP binary in the file midp.exe
• build – Contains makefiles and tools for building the MIDP source code on Solaris
and on Win32 platforms
• classes – Contains the Java .class files for MIDP
• docs – Includes the MIDP specification, instructions for building the MIDP source
code, instructions for creating and running MIDlets, and instructions for using the
included demonstration applications
• src – Includes the Java source files for MIDP
6.4 How to Install MIDP
6.4.1 Installing the MIDP Package
Extract the download file:
j2me_midp-1_0-fcs-bin-b10-win-15_sep_2000.zip using a utility program
such as WinZip on Win32 systems. In this document, the download file is assumed to
have been extracted to the directory J2ME. The directories listed in Section 6.3.3,
“Directories Created When Installing MIDP,” are created.
SUN MICROSYSTEMS, INC.
22 of 57
Downloading, Installing, and Uninstalling the J2ME Wireless Toolkit
Note: The documentation included with the MIDP package includes instructions for
building the source release. It is not necessary to build the MIDP source release if you
plan to run the MIDP binary files only. These binary files are already built and are
available with the download package. The binary files are located in the bin directory.
6.4.2 Verifying the MIDP Installation
Be sure that your system environment variable PATH includes the following:
• The Java 2 SDK bin directory, for example, c:\jdk1.3\bin
• The MIDP bin directory, for example, c:\J2ME\midp-fcs\bin
Type the following at the command line:
prompt> midp
If MIDP is installed properly and the system PATH is correct, a window containing an
image of a cellular phone will appear on your screen.
Note: For a tutorial on setting up the MIDP environment, see
http://developer.java.sun.com/developer/technicalArticles/
wireless/midpsetup/
6.5 Uninstalling MIDP
To uninstall MIDP, simply remove the MIDP installation directory and its contents.
7.0 Downloading, Installing, and Uninstalling the J2ME
Wireless Toolkit
The instructions in this section include the names of the download files for the J2ME
Wireless Toolkit 1.0. These names will change appropriately when version 1.0.1 is
available for public download.
Note: All instructions in this section were written for the J2ME Wireless Toolkit 1.0.
7.1 Downloading the J2ME Wireless Toolkit
The J2ME Wireless Toolkit binary product can be downloaded for free from
http://java.sun.com/products/j2mewtoolkit/download.html. Before
you can download the product, you must first agree to the license agreement. The
download file name is j2me_wireless_toolkit-1_0.exe and it is 4.85 MB.
7.2 Pre-installation Considerations
Be sure that a supported version of the Java 2 SDK is installed prior to installing the
J2ME Wireless Toolkit. The J2ME Wireless Toolkit requires version 1.3 or later.
SUN MICROSYSTEMS, INC.
23 of 57
Downloading, Installing, and Uninstalling the J2ME Wireless Toolkit
If using the Wireless Toolkit as a plug-in to Forte for Java, Community Edition, be sure
that Forte for Java Community Edition version 1.0 Update 2 is installed prior to
installing the J2ME Wireless Toolkit.
Note: The J2ME Wireless Toolkit also works with Forte for Java, Internet Edition.
7.3 Installation Details
7.3.1 Default Installation Path for the J2ME Wireless Toolkit
For the J2ME Wireless Toolkit, the default installation path is:
C:\J2MEWTK
7.3.2 Changes to System Files
The J2ME Wireless Toolkit installation adds entries to the Windows registry:
• [HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems, Inc.\J2ME
Wireless Toolkit]
"LatestVersion"="1.0"
• [HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems, Inc.\J2ME
Wireless Toolkit\1.0]
"InstallDir"="C:\\J2MEWTK"
"MicroVersion"="0"
These entries are stored in the Windows registry so that details of the J2ME Wireless
Toolkit installation are available to later installations of the Wireless Toolkit and to
installations of third party software.
7.3.3 Directories Created When Installing the J2ME Wireless Toolkit
The installation process for the J2ME Wireless Toolkit creates an installation directory,
which by default is called j2mewtk. Within this directory, the following subdirectories
are created:
• apps – Contains demonstration applications and serves as a location for additional
applications that are created with the KToolBar interface of the J2ME Wireless
Toolkit
• bin – Contains executable files used with the J2ME Wireless Toolkit
• lib – Contains files and directories including:
• midpapi.zip – Contains the CLDC and MIDP API class files used during
compilation of the application source files and the bytecode pre-verification of
the application classes
• devices – Contains device property files for the devices emulated by the J2ME
Wireless Toolkit
• doc – Contains the user’s guide and API documents
7.4 How to Install the J2ME Wireless Toolkit
The J2ME Wireless Toolkit can be installed as a stand-alone development tool or as a
plug-in for Forte for Java.
SUN MICROSYSTEMS, INC.
24 of 57
Downloading, Installing, and Uninstalling the J2ME Wireless Toolkit
Note: The J2ME Wireless Toolkit includes implementations of CLDC and MIDP. When
using the Wireless Toolkit, do not install CLDC or MIDP separately. The MIDP
implementation provided with the Wireless Toolkit provides emulation capabilities that
are not available with other MIDP implementations. You cannot point the Wireless
Toolkit to other CLDC or MIDP implementations.
7.4.1 Installing the J2ME Wireless Toolkit as a Stand-alone Development Tool
The download file for the J2ME Wireless Toolkit is an executable installation program.
To install the Wireless toolkit, run the installation program,
j2me_wireless_toolkit-1_0.exe. Follow the instructions, noting the following:
• Be sure to uninstall any previous version of the J2ME Wireless Toolkit already
installed before installing the new version. See Section 7.7, “Uninstalling the J2ME
Wireless Toolkit.”
• Do not include spaces in the name of the install directory. The preverify tool will
not work properly if there are spaces in the directory name.
• Select “Stand Alone” as the setup type.
• After installation, configure the emulator as described in Section 3.2, “Configuring
the Emulator,” in the Java 2, Micro Edition, Wireless Toolkit User’s Guide, available
with the download.
7.4.2 Installing the J2ME Wireless Toolkit as a Plug-in to Forte for Java
Before installing the J2ME Wireless Toolkit as a Plug-in module to Forte for Java, first
install Forte for Java and be sure that it is working. To install the J2ME Wireless
module, run the installation program, j2me_wireless_toolkit-1_0.exe. Follow
the instructions, noting the following:
• Be sure to uninstall any previous version of the J2ME Wireless Toolkit already
installed before installing the new version. See Section 7.7, “Uninstalling the J2ME
Wireless Toolkit.”
• Do not include spaces in the name of the install directory. The preverify tool will
not work properly if there are spaces in the directory name.
• Select “Integrated” as the setup type.
• After installation, configure the emulator as described in Section 3.2, “Configuring
the Emulator,” in the Java 2, Micro Edition, Wireless Toolkit User’s Guide, available
with the download.
7.5 Verifying the J2ME Wireless Toolkit Installation
To verify that the J2ME Wireless Toolkit is installed properly, open and run one of the
sample applications that are provided with the Wireless Toolkit.
To run a sample program from KToolbar, from the Start menu, choose Programs →
J2ME Wireless Toolkit 1.0 → KToolbar. If you open the project UIDemo in the
directory C:\J2MEWTK\apps, you will see a demonstration user interface on an
emulated cell phone.
SUN MICROSYSTEMS, INC.
25 of 57
Developing Applications with CLDC
If you plan to use the J2ME Wireless Toolkit from Forte for Java, you should run a
sample program from Forte for Java. To run a sample program from Forte for Java,
follow the instructions in Chapter 4 of the J2ME Wireless Toolkit User’s Guide.
7.6 Common Problems with Installation
7.6.1 J2ME Wireless Toolkit Does Not Find J2SE Installation
Problem: J2SE SDK 1.3 is already installed when the Wireless Toolkit installation
begins, but the installer gives a message saying that the SDK must be installed.
Cause: This problem occurs when either:
• The J2SE SDK is not Sun’s version of the SDK.
• The SDK has been moved after being installed.
Solution: Do the following:
1. Reinstall J2SE SDK version 1.3 from
http://java.sun.com/j2se/1.3/download-windows.html.
2. Install the J2ME Wireless Toolkit.
7.6.2 The J2ME Wireless Toolkit Does Not Run from Forte for Java
Problem: Forte for Java is already installed when the J2ME Wireless Toolkit is
installed, but the Wireless Toolkit will not run with Forte for Java. The following
message appears: This module depends on module org.netbeans.modules.kjava/1 which
was not supplied.
Solution: Do the following:
1.
2.
3.
4.
5.
Uninstall the current version of Forte for Java.
Uninstall the J2ME Wireless Toolkit.
Be sure that you have JDK 1.3 installed on your system.
Reinstall Forte for Java, Community Edition 1.0 Update 2 or greater.
During the installation, the installer program will search for a JDK in your system.
Be sure that JDK 1.3 is chosen.
6. Reinstall J2ME Wireless Toolkit. During the installation, select “Integrated” as the
setup type.
7.7 Uninstalling the J2ME Wireless Toolkit
To uninstall the J2ME Wireless Toolkit, choose Start → Programs → J2ME Wireless
Toolkit 1.0 → Remove J2ME Wireless Toolkit 1.0.
8.0 Developing Applications with CLDC
The CLDC reference implementation available from Sun is not intended to be used
without a profile such as MIDP. A profile provides APIs tailored to a specific family of
devices. Applications developed for a family of devices should call the APIs available
with the appropriate profile instead of calling CLDC APIs directly.
SUN MICROSYSTEMS, INC.
26 of 57
Developing Applications with CLDC
While applications can be developed using the CLDC reference implementation, and
the application development cycle for such applications is listed in this section, most
applications developed for a mobile device will be developed using the MIDP APIs.
Since MIDP relies on the underlying CLDC implementation, it is important to
understand CLDC.
8.1 The CLDC Specification
CLDC runs on top of the KVM. The KVM is compliant with the standard JVM except
for specific differences described in the Connected, Limited Device Configuration
Specification Version 1.0, available for download from
http://java.sun.com/aboutJava/communityprocess/final/jsr030/. The
primary differences are in the following areas:
•
•
•
•
•
•
•
•
Application management
Security
Floating point support
Finalization
Error handling
Classfile verification and loading
Limited Java libraries
Garbage collection
These differences are summarized in the following sections. For more details, see the
CLDC Specification.
The following are outside the scope of CLDC; they are defined in the profiles, such as
MIDP:
•
•
•
•
•
Application installation and life-cycle management
User interface support
Event handling
High-level application model
Database support
8.1.1 Application Management
Application management includes:
• Inspecting existing Java applications stored on the device
• Selecting and launching Java applications
• Deleting existing Java applications
Due to significant variations and feature differences among potential CLDC devices, the
details of application management are highly device specific. A CLDC implementation
does not require that Java classes downloaded from an external source are stored
persistently on the device.
SUN MICROSYSTEMS, INC.
27 of 57
Developing Applications with CLDC
The CLDC reference implementation provides an optional application manager called
the Java Application Manager (JAM). The source code for the JAM is provided in the
installation directory j2me_cldc/jam. The JAM downloads and manages Java
applications that are stored in JAR files. The implementation uses a file system to
simulate persistent storage on a small device; the JAM saves all JAR files in a directory
called instapps. The JAM also provides for HTTP downloading of web pages and
JAR files.
Note: On a CLDC device, there may be no directory structure for saving application
files.
8.1.2 CLDC Security
The amount of code devoted to security in J2SE far exceeds the memory budget
available for a JVM supporting CLDC. Security in CLDC focuses on two areas: lowlevel virtual machine security and application level security.
8.1.2.1 Low-Level Virtual Machine Security
The low-level virtual machine security means that the Java application executed by the
VM must not be able to harm the device in which it is running. This constraint is
guaranteed by classfile verification; the JVM must be able to reject invalid classfiles.
The verification approach used by CLDC is significantly smaller than the approach used
by J2SE.
The CLDC verifier requires Java class files to contain special attributes which are placed
into the class files by the CLDC preverification tool. The transformed class file is still a
valid J2SE class file; the additional attributes allow verification to be carried out
efficiently at run time. Preprocessed class files containing the extra attributes are
approximately 5% to 10% larger than the original class files.
The verification process requires two steps: off-device preverification and in-device
verification. The preverification step is performed prior to loading the application on the
device. It is usually performed on the workstation where the application is developed.
The verification step is performed on the device. For a description of the algorithms
used in the preverification and verification process, see Section 5.3 of the Connected,
Limited Device Configuration Specification Version 1.0.
8.1.2.2 Application Level Security
Classfile verification can only guarantee that a given program is a valid Java program,
and nothing more. Several other potential security threats will go unnoticed by the
verifier, for example, access to external resources such as the file system. These
potential security threats are avoided in J2SE by the security manager. Unfortunately,
the J2SE security model is far too memory-consuming to be included in a CLDC device.
CLDC provides a sandbox security model, meaning that a Java application must run in a
closed environment in which the application can only access those APIs that have been
defined by the configuration, profiles, and licensee open classes supported by the device.
System classes are protected by ensuring that a programmer cannot override classes in
the packages java.*, javax.microedition.*, or other profile- or system-specific
SUN MICROSYSTEMS, INC.
28 of 57
Developing Applications with CLDC
packages. The programmer is not allowed to manipulate the classfile lookup order in
any way.
8.1.3 No Floating Point Support
The main language-level difference between the standard JVM and CLDC is that the
CLDC provides no floating point support. Floating point support is not provided
because hardware support for floating point operations is not available in most target
CLDC devices.
8.1.4 No Finalization
CLDC libraries do not include the method Object.finalize(). CLDC does not
support the finalization of class instances; any application built on top of CLDC may not
require finalization.
8.1.5 Limited Error Handling
CLDC supports exception handling, but the set of error classes included in the CLDC
libraries is limited. The set of error classes available in any CLDC implementation is
listed in Section 6.2 of the Connected, Limited Device Configuration Specification
Version 1.0. For a list of the error classes available in the CLDC reference
implementation, see the CLDC API documentation available with the CLDC download.
8.1.6 Limited Java Libraries
Several features of the standard Java libraries have been eliminated in CLDC, either
because of the size constraints of the CLDC devices or because of security concerns.
8.1.6.1 No Java Native Interface Support
CLDC does not implement the Java Native Interface (JNI) because:
• The limited security model provided by CLDC assumes that the set of native
functions must be closed.
• The full implementation of JNI requires too much memory.
8.1.6.2 No User-Defined Class Loaders
CLDC does not support user-defined, Java-level class loaders. The CLDC class loader
cannot be overridden, replaced, or reconfigured by the user. User-defined class loaders
are not allowed due to security considerations of the sandbox model.
8.1.6.3 No Reflection
CLDC does not support reflection or any language features that require reflection, such
as RMI, object serialization, JVM debugging interface (JVMDI), and JVM profiler
interface (JVMPI).
8.1.6.4 No Thread Groups or Daemon Threads
CLDC implements multithreading but does not support thread groups or daemon
threads. Thread operations such as starting and stopping threads can be applied only to
individual thread objects. To perform thread operations for groups of threads, explicit
collection objects must be used at the application level to store thread objects.
SUN MICROSYSTEMS, INC.
29 of 57
Developing Applications with CLDC
8.1.6.5 No Weak References
CLDC does not support weak references.
8.1.6.6 Internationalization and Localization Support
CLDC includes limited support for translating Unicode characters to and from a
sequence of bytes. In J2SE this is done using objects called Readers and Writers. The
same mechanism is used in CLDC using the InputStreamReader and
InputStreamWriter classes.
CLDC does not provide any localization features. All solutions related to formatting
dates, times, and currencies are outside the scope of CLDC.
8.1.6.7 Generic Connection Framework – Input, Output, and Networking Support
The J2SE libraries that support input, output, and networking are too large to be
implemented in full in CLDC. Additionally, the standard I/O and networking
functionality is not directly applicable to small devices. This has led to the creation of
the Generic Connection Framework, a precise functional subset of J2SE classes defined
for small memory footprint mobile devices.
The generic connection framework includes the following interface types:
•
•
•
•
•
•
Basic serial input
Basic serial output
Datagram-oriented communication
Circuit-oriented communication such as TCP
Notification mechanism for a server to be informed of client-server connections
Basic web server connection
The CLDC specification provides the connection framework but does not define any
network protocols; it is up to the J2ME profiles to define the protocols for specific
device categories. Sun’s CLDC reference implementation includes several protocol
implementations that can be used as a starting point for profile-specific
implementations.
Connections are created using a static method in a system class called Connector. The
general form is:
Connector.open(“<protocol>:<address>;<parameters>”);
The following is example code that opens a test HTTP connection using the CLDC
reference implementation.
Note: In the following code sample, the line:
in =
Connector.openInputStream(“testhttp://userid:8080/hello.txt”);
is used for testing only. The CLDC reference implementation does not provide an
implementation for a CLDC device.
SUN MICROSYSTEMS, INC.
30 of 57
Developing Applications with CLDC
// file GenConnection.java
import java.io.*;
import javax.microedition.io.*;
public class GenConnection {
public static void main(String[] args) {
InputStream in = null;
int total = 0;
try {
in = Connector.openInputStream(
“testhttp://userid:8080/hello.txt”);
while ((count = in.read(b, 0, 64)) > 0)
total += count;
} catch (Exception e1) {
System.out.println(Error opening InputStream ” +
“connection ” + e1);
}
// close InputStream
try {
in.close();
} catch (Exception e2) {
System.out.println(“Error closing InputStream ” +
“connection ” + e2);
}
System.out.println(“Number of characters read: ”
+ total);
}
}
For more details on the Generic Connection Framework, see the API documents
available with the CLDC download.
8.1.6.8 Garbage Collection
The KVM garbage collector implemented in CLDC 1.0 was smaller and simpler than
the garbage collector used in the standard JVM. The KVM garbage collector in CLDC
1.0 was based on a non-copying, non-moving, non-incremental, and single space
collector that used the mark-and-sweep algorithm. The garbage collector was optimized
for small heaps ranging between 32 to 512 KB.
With the CLDC 1.0 garbage collector, object allocation was slow and memory
fragmentation could cause the VM to run out of memory more easily than with a
copying collector. The CLDC 1.1 release implements a new exact and compacting
garbage collector. Compacting garbage collection is a configurable option, and can be
turned on or off.
Note: Currently, compaction cannot be used on those platforms that have a segmented,
non-contiguous memory architecture, such as the Palm OS.
8.2 CLDC Application Development Cycle
This section traces the development cycle of a CLDC application. A simple HelloWorld
application is used to describe the process.
The Java Developer Connection (JDC) has published a tutorial describing the J2ME
Development Cycle. This tutorial provides information about how to compile, preverify,
and run a CLDC application. To view the JDC tutorial, see
SUN MICROSYSTEMS, INC.
31 of 57
Developing Applications with CLDC
http://developer.java.sun.com/developer/J2METechTips/2000/
tt1218.html.
8.2.1 Writing the CLDC Application
Writing a Java application for a CLDC device is essentially the same as writing any
other Java application. The difference is in the classes and methods available to CLDC
applications. As noted in Section 8.1, “The CLDC Specification,” some classes in the
J2SE are limited or unavailable in CLDC, and the CLDC Generic Connection
Framework adds classes that provide input, output, and networking capabilities specific
to the types of devices supported by CLDC.
Consult the CLDC API documentation, available with the CLDC download, to verify
that the classes and methods you wish to use in your application are available.
The source code for a simple HelloWorld application that is run using CLDC is identical
to source code that can be used with the J2SE.
// file HelloWorld.java
public class HelloWorld {
public static void main( String[] args ){
System.out.println( "Hello, world!" );
}
}
8.2.2 Compiling the CLDC Application
To compile a CLDC application, use the standard J2SE compiler, javac, with the
following options:
• -bootclasspath <path to CLDC installation>/bin/api/classes
The -bootclasspath option replaces the J2SE classes with the CLDC classes.
If, instead of using -bootclasspath, you reference the CLDC classes with the
class path, the compiler automatically searches the J2SE core classes first, regardless
of what is in the class path. This means that the compiler will not catch any
references to classes or methods that are missing from CLDC, leading to runtime
errors when you deploy your application.
• -g:none
To keep the class files as small as possible, you normally also use the -g:none
option to remove all debugging information.
• -d <path to unverified class files>
The -d option defines the output directory for the compiled classes. CLDC classes
must be preverified before they can be run. It is best to keep the preverified classes
separate from the verified classes. One way to keep them separate is to make a
directory called unverified to store the compiled, but not yet preverified, class
files, and to create a directory called preverified to store the preverified class
files.
The following sample command lines show you how to compile HelloWorld.java.
These examples assume the following:
SUN MICROSYSTEMS, INC.
32 of 57
Developing Applications with CLDC
• An environment variable, CLDC_HOME, has been defined to point to the root of the
CLDC installation directory. For example, on a Windows system where the default
installation directory was used, CLDC_HOME will be set to C:\j2me\j2me_cldc.
• The source for HelloWorld.java is in a directory accessible from the current
path.
• A directory, unverified, has been created as a subdirectory of the directory
containing the Java source code. This is the directory where the unverified class file
will be stored.
To compile HelloWorld.java on Windows, type the following on one line:
javac -g:none -bootclasspath %CLDC_HOME%\bin\api\classes
-d unverified HelloWorld.java
To compile HelloWorld.java on Solaris, type the following on one line:
javac -g:none -bootclasspath $CLDC_HOME/bin/api/classes
-d unverified HelloWorld.java
8.2.3 Preverifying the CLDC Application
Before running a CLDC application, the class files must be preverified. The CLDC
reference implementation includes a tool, preverify, for preverifying the application
class files. The need for preverification is discussed in Section 8.1.2, “CLDC Security.”
The preverify tool is run on a command line and uses the following options:
• -classpath <path to CLDC classes>
The -classpath option lists the directories in which to find referenced classes.
• -d <path to verified class files>
You can run preverify on a list of files or directories. When running preverify on
directories, these directories are searched recursively for any class files.
The following sample command lines show how to preverify HelloWorld.class.
These examples assume the following:
• An environment variable, CLDC_HOME, has been defined to point to the root of the
CLDC installation directory
• A directory, unverified, has been created as a subdirectory of the directory
containing the Java source code, and contains the unverified class file
HelloJava.class. This directory is accessible from the current path.
• A directory, preverified, has been created as a subdirectory of the directory
containing the Java source code. This is the directory where the preverified class file
will be stored.
To preverify HelloWorld.class on Windows, type the following on one line:
%CLDC_HOME%\bin\preverify -classpath %CLDC_HOME%\bin\api\classes
-d preverified unverified
SUN MICROSYSTEMS, INC.
33 of 57
Developing Applications with CLDC
To compile HelloWorld.java on Solaris, type the following on one line:
$CLDC_HOME/bin/preverify -classpath $CLDC_HOME/bin/api/classes
-d preverified unverified
Note: The current version of the preverifier does not handle JAR files.
8.2.4 Testing the CLDC Application on a Desktop System
The CLDC reference implementation allows you to run your compiled and preverified
application on your desktop system. The binary file used to run the CLDC application is
called kvm.
The kvm tool is run on a command line and uses the following option:
• -classpath <path to preverified classes and to CLDC classes>
The -classpath option lists the directories in which to find referenced classes.
The following sample command lines show how to run HelloWorld.class. These
examples assume the following:
• An environment variable, CLDC_HOME, has been defined to point to the root of the
CLDC installation directory
• A directory, preverified, has been created as a subdirectory of the directory
containing the Java source code. This is the directory where the preverified class file
is stored. This directory is accessible from the current path.
To run the preverified HelloWorld.class on Windows, type the following:
kvm -classpath preverified;%CLDC_HOME%\bin\api\classes HelloWorld
To run the preverified HelloWorld.java on Solaris, type the following:
kvm -classpath preverified:$CLDC_HOME/bin/api/classes HelloWorld
8.2.5 Loading and Running the CLDC Application on a CLDC Device
To run a CLDC application on a small device, there must be an implementation of
CLDC for that device. The process of loading and running applications will depend on
characteristics of the device and on the implementation of the CLDC for that device.
8.2.5.1 Loading and Running a CLDC Application on a Palm Device
At this time, the only device for which Sun provides an implementation for CLDC is the
Palm PDA. This implementation is a proof-of-concept implementation and is not
supported by Sun. If you want to develop applications for devices that use the Palm OS,
it is best to wait until the MIDP implementation for the Palm OS is available in the
second quarter of 2001.
While the CLDC implementation for Palm is not supported by Sun, it is briefly
described here for completeness. The process of loading and running an application on a
Palm device is described in two documents available with the CLDC Palm Overlay
download: docs/PalmReleaseNotes.pdf and docs/tools.html. The basic
process is as follows:
SUN MICROSYSTEMS, INC.
34 of 57
Developing Applications with CLDC
1. Compile the application as described in Section 8.2.2, “Compiling the CLDC
Application.”
2. Preverify the class files as described in Section 8.2.3, “Preverifying the CLDC
Application.”
3. Use the jar tool, provided with J2SE, to create a JAR file that contains all the Java
classes belonging to the application.
4. Use the MakePalmApp tool, provided with the CLDC Palm Overlay download, to
convert the Java classfiles or a JAR file into a Palm executable (prc) file.
5. Install the files KVM.prc, KVMutil.prc, and your application executable files on
the Palm device and launch them from the Palm application launcher.
Note: A Palm OS Emulator (POSE) can be downloaded from the Palm site at
http://www.palmos.com/dev/tech/tools/emulator/.
8.2.5.2 The Java Application Manager
The CLDC reference implementation includes an optional component manager known
as the Java Application Manager (JAM). The JAM allows Java applications to be
managed on devices without a file system. Application management includes installing,
launching, and deleting the application. The JAM also allows Java technology based
applications to be downloaded from the Internet via HTTP.
For more information on the JAM, see Chapter 14 of the KVM Porting Guide, available
with the CLDC download.
8.3 Optimizing CLDC Applications
There are methods available for optimizing applications that run on small devices
running CLDC. The same optimization techniques apply equally to applications
running on MIDP.
• System classes can be preloaded on the device using the romizing technique
available in JavaCodeCompact. Romizing allows you to preload and prelink class
files. Prelinking and preloading certain classes can improve start-up performance of
applications. Preloading must have no visible effects other than speeding up
application launch. The mechanisms used for preloading are implementation
dependent.
• A Palm-specific system optimization is available in which immutable structures are
moved from dynamic RAM to storage RAM in an effort to save Java heap space.
• The Java heap space can be allocated in multiple chunks or segments in a technique
known as chunky stacks. This allows the KVM to allocate more heap space on
resource constrained platforms.
For more information on optimizing applications, see Chapter 6 of the KVM Porting
Guide, available with the CLDC download:
• Section 6.2 includes information on general system configuration options, including
romizing
• Section 6.3 covers Palm-specific system configuration options
• Section 6.4 covers memory allocation settings, including chunky stacks
SUN MICROSYSTEMS, INC.
35 of 57
Developing Applications with MIDP
• Section 6.5 covers garbage collection options, including how to turn on and off
compaction
• Section 6.6 covers interpreter options, including the newly redesigned interpreter
options introduced in CLDC 1.1
For more information about thinking and coding for small devices, see the book Java 2
Micro Edition: Professional Developer’s Guide by Eric Giguere. Information about the
book is available from http://www.ericgiguere.com/j2mebook/.
9.0 Developing Applications with MIDP
9.1 Language Features of MIDP
MIDP is designed to work on top of CLDC. MIDP modifies or extends several features
of CLDC to provide APIs that enable application programmers to create applications for
Mobile Information Devices (MIDs). The MIDP APIs emphasize:
• Applications – Defines the semantics of a MIDP application (MIDlet) and how it is
controlled
•
•
•
•
User interface (UI) – Provides both display and input event processing
Persistent storage – Provides database support
Networking – Implements the Generic Connection framework defined in CLDC
Timers – Allow an application to schedule a task for future execution in a
background thread
These topics are summarized in this section and are described fully in the MIDP
Specification, available for download from
http://java.sun.com/aboutJava/communityprocess/final/jsr037/.
9.1.1 MIDP API Packages
The MIDP APIs are provided in several packages. The MIDP packages are extensions
to J2SE and CLDC API packages. This section lists the MIDP API packages.
• J2SE packages extended by MIDP
• java.lang – Adds IllegalStateException, which is thrown when illegal
transitions are requested.
• java.util – Adds timer classes, which allow applications to schedule tasks.
• CLDC package extended by MIDP
• javax.microedition.io – Implements HTTP for the Generic Connection
framework for MIDs.
• New packages added to the CLDC package javax.microedition
• javax.microedition.rms – Provides a record management system to enable
persistent storage.
• javax.microedition.midlet – Provides MIDlet lifecycle management.
SUN MICROSYSTEMS, INC.
36 of 57
Developing Applications with MIDP
• javax.microedition.lcdui – Provides user interface management designed
specifically for MIDs.
9.1.2 MIDP Applications and Application Suites
Applications that run on the MIDP are called MIDlets. A MIDP application must use
only functionality specified by the MIDP specification as it is developed, tested,
deployed, and run. The MIDP application lifecycle package is called
javax.microedition.midlet.
More than one MIDlet can be packaged together into a MIDlet suite. All preverified
class files and resource files, including application icons, should be packaged into the
same JAR file.
The elements of a MIDlet or a MIDlet suite are:
•
•
•
•
Runtime execution environment
MIDlet suite packaging
Application descriptor
Application lifecycle
The MIDP application management APIs make up the package
javax.microedition.midlet.
9.1.3 MIDP User Interface Capabilities
The UI for MIDP is redesigned to meet the needs of MIDs. It is not simply a subset of
the J2SE Abstract Windowing Toolkit (AWT).
The MIDP UI is logically composed of two APIs: the high-level API and the low-level
API.
• High-level API – The high-level API is designed for business applications whose
client parts run on MIDs. For these applications, portability across devices is
important. To achieve this portability, the high-level API employs a high level of
abstraction and provides very little control over look and feel.
• Low-level API – The low-level API provides very little abstraction. This API is
designed for applications that need precise placement and control of graphic
elements, as well as access to low-level input events. Some applications also need to
access special, device-specific features. A typical example of such an application
would be a game.
Applications that program to the low-level API are not guaranteed to be portable, since
the low-level API provides the means to access details that are specific to a particular
device. If the application does not use these features, the applications will be portable,
and it is recommended that the applications use the platform-independent part of the
low-level API whenever possible.
The central abstraction of the MIDP’s UI is that of a screen. A screen is an object that
encapsulates device-specific graphics rendering user input. Only one screen may be
visible at the time, and the user can only traverse through the items on that screen. The
screen takes care of all events that occur as the user navigates in the screen, with only
SUN MICROSYSTEMS, INC.
37 of 57
Developing Applications with MIDP
higher-level events being passed on to the application. The application can switch the
screens by calling:
public void setCurrent (Displayable nextDisplayable)
The MIDP UI APIs make up the package javax.microedition.lcdui. The screens
implementing the high-level API are the subclasses of Screen, while the classes
Canvas and Graphics implement the low-level API.
9.1.4 MIDP Persistent Storage Capabilities
The MIDP provides a mechanism for MIDlets to persistently store data and retrieve it
later. This persistent storage mechanism, called the Record Management System
(RMS), is modeled after a simple record-oriented database.
A record store consists of a collection of records that will remain persistent across
multiple invocations of a MIDlet. The platform is responsible for making its best effort
to maintain the integrity of the MIDlet’s record stores throughout the normal use of the
platform, including reboots and battery changes.
The MIDP persistent storage APIs make up the package javax.microedition.rms.
9.1.5 MIDP Input, Output, and Networking Capabilities
The MIDP extends the connectivity support provided by the CLDC with specific
functionality for the Generic Connection framework. MIDP supports a subset of the
HTTP protocol, which can be implemented using both IP protocols such as TCP/IP and
non-IP protocols such as WAP and i-mode, using a gateway to provide access to HTTP
servers on the Internet.
The Generic Connection framework is used to support client-server networks. Using
only the protocols specified by the MIDP will allow the application to be portable to all
MIDs. All MIDP implementations must provide support for accessing HTTP 1.1 servers
and services.
The MIDP I/O and networking APIs make up the package javax.microedition.io.
In addition to the javax.microedition.io classes specified by CLDC, MIDP
includes the interface javax.microedition.io.HttpConnection for HTTP
protocol access over the network.
9.1.6 MIDP Timers
MIDP Timers are a direct subset of, and are compatible with, J2SE
java.util.Timer. Timers allow an application to schedule a task for future execution
in a background thread. Applications that need to delay or schedule activities for a later
time can use the Timer and TimerTask classes, including functions for one-time
execution and for repeated execution at regular intervals.
9.2 MIDlet States
Once a MIDlet begins executing, it can be in three states:
• Active – The MIDlet is functioning normally. This state is entered when the method
MIDlet.startApp() is called.
SUN MICROSYSTEMS, INC.
38 of 57
Developing Applications with MIDP
• Paused – This state is entered after the MIDlet has been created and before it
becomes active.
• Destroyed – When the MIDlet has released all of its resources and is terminated, it
enters the destroyed state. The application management software can cause a MIDlet
to be destroyed by calling either the MIDlet.destroyApp() or the
MIDlet.notifyDestroyed() method.
The application manager assumes that the application behaves as follows with respect to
the MIDlet events:
• startApp – The application may call setCurrent() for the first screen. The
application manager makes Displayable really visible when startApp() returns.
Note that startApp() can be called several times if pauseApp() is called in
between.
• pauseApp – The application must release shared resources so that they can be used
by other MIDlets. This includes freeing objects that can be recreated when the
MIDlet is started with startApp() again.
• destroyApp – The application must free resources that cannot be reclaimed with
the garbage collector. This includes I/O connections.
9.3 MIDP Application Development Cycle
This section traces the development cycle of a MIDP application. A simple HelloWorld
application is used to describe the process. The MIDP reference implementation is
currently only supported on Windows platforms; the examples in this section use
Windows command line format.
The Java Developer Connection (JDC) has published a series of articles describing the
J2ME Development Cycle. The article MIDP Setup Explained, available from
http://developer.java.sun.com/developer/technicalArticles/
wireless/midpsetup/, describes the process of compiling, preverifying, packaging,
and running a MIDlet.
9.3.1 Writing the MIDlet
Writing a MIDlet is essentially the same as writing any other Java application. The
difference is in the classes and methods available to MIDlets applications. As noted in
Section 9.1, “Language Features of MIDP,” some classes in the J2SE and the CLDC are
limited or modified in MIDP.
Consult the MIDP API documentation to verify that the classes and methods you wish
to use in your application are available. The MIDP API documentation is available in
the MIDP Specification, available in the docs subdirectory of the MIDP installation or
from
http://java.sun.com/aboutJava/communityprocess/final/jsr037/.
The source code for a simple HelloWorld application that includes MIDP UI
components is published in the JDC article Introduction to Wireless Programming with
the MID Profile, available from http://developer.java.sun.com/
developer/technicalArticles/wireless/midp/. The code is duplicated here.
SUN MICROSYSTEMS, INC.
39 of 57
Developing Applications with MIDP
// file HelloMIDlet.java
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HelloMIDlet extends MIDlet
implements CommandListener {
private Command exitCommand;
private Display display;
private TextBox t = null;
public HelloMIDlet() {
display = Display.getDisplay(this);
exitCommand = new Command("Exit", Command.EXIT, 2);
t = new TextBox("Hello MIDlet",
"Test string", 256, 0);
t.addCommand(exitCommand);
t.setCommandListener(this);
}
public void startApp() {
display.setCurrent(t);
}
public void pauseApp() {
}
public void destroyApp(boolean unconditional) {
}
public void commandAction(Command c, Displayable s) {
if (c == exitCommand) {
destroyApp(false);
notifyDestroyed();
}
}
}
The application is responsible for releasing any and all resources that can be recreated in
startApp() when the application is resumed. This includes freeing memory by setting
object references to null.
9.3.2 Compiling the MIDlet
To compile a MIDlet, use the standard J2SE compiler, javac, with the following
options:
• -bootclasspath <path to MIDP installation>\classes
The -bootclasspath option replaces the J2SE classes with the MIDP classes.
If, instead of using -bootclasspath, you reference the MIDP classes with the
class path, the compiler automatically searches the J2SE core classes first, regardless
of what is in the class path. This means that the compiler will not catch any
references to classes or methods that are missing from MIDP, leading to runtime
errors when you deploy your application.
• -g:none
To keep the class files as small as possible, you normally also use the -g:none
option to remove all debugging information.
• -d <path to unverified class files>
SUN MICROSYSTEMS, INC.
40 of 57
Developing Applications with MIDP
The -d option defines the output directory for the compiled classes. MIDP classes
must be preverified before they can be run. It is best to keep the preverified classes
separate from the verified classes. One way to keep them separate is to make a
directory called unverified to store the compiled, but not yet preverified, class
files, and to create a directory called preverified to store the preverified class
files.
The following sample command lines show you how to compile HelloMIDlet.java.
These examples assume the following:
• An environment variable, MIDP_HOME, has been defined to point to the root of the
MIDP installation directory. For example, on a Windows system where the default
installation directory was used, MIDP_HOME will be set to C:\J2ME\midp-fcs.
• The source for HelloMIDlet.java is in a directory accessible from the current
path.
• A directory, unverified, has been created as a subdirectory of the directory
containing the Java source code. This is the directory where the unverified class file
will be stored.
To compile HelloMIDlet.java on Windows, from the directory containing the Java
source file, type the following on one line:
javac -g:none -bootclasspath %MIDP_HOME%\classes -d unverified
HelloMIDlet.java
9.3.3 Preverifying the MIDlet
Before running a MIDlet, the class files must be preverified. The MIDP reference
implementation includes a tool, preverify, for preverifying the application class files.
The need for preverification is described in Section 8.1.2, “CLDC Security.”
The preverify tool is run on a command line and uses the following options:
• -classpath <path to MIDP classes>
The -classpath option lists the directories in which to find referenced classes.
• -d <path to verified class files>
You can run preverify on a list of files or directories. When running preverify on
directories, these directories are searched recursively for any class files.
The following sample command lines show how to preverify HelloMIDlet.class.
These examples assume the following:
• An environment variable, MIDP_HOME, has been defined to point to the root of the
MIDP installation directory. For example, on a Windows system where the default
installation directory was used, MIDP_HOME will be set to C:\J2ME\midp-fcs.
• A directory, unverified, has been created as a subdirectory of the directory
containing the Java source code, and contains the unverified class file
HelloJava.class. This directory is accessible from the current path.
SUN MICROSYSTEMS, INC.
41 of 57
Developing Applications with MIDP
• A directory, preverified, has been created as a subdirectory of the directory
containing the Java source code. This is the directory where the preverified class file
will be stored.
To preverify HelloMIDlet.class on Windows, from the directory containing the
Java source file, type the following on one line:
%MIDP_HOME%\build\win32\tools\preverify
-classpath %MIDP_HOME%\classes;preverified
-d preverified unverified
To test the MIDlet, from the preverified directory, type the following at the
command prompt:
%MIDP_HOME%\bin\midp HelloMIDlet
A window containing an emulated cellular phone should appear.
9.3.4 Packaging the MIDlet in a JAR File
The next step is to package the MIDlet into a JAR file. In this case, there is only one
executable file associated with the MIDlet. If there are multiple executable files for the
MIDlet, they should be packaged together into a single JAR file.
To package the file HelloMIDlet.class into a JAR file called HelloMIDlet.jar,
navigate to the directory preverified and type the following at the command prompt:
jar cf HelloMIDlet.jar HelloMIDlet.class
The JAR file, HelloMIDlet.jar is created in the directory preverified.
9.3.5 Writing the MIDlet Descriptor File
A MIDlet descriptor file is required by the application management software to manage
MIDlets. The descriptor file is also used by the MIDlet for configuration. The file
extension of the MIDlet descriptor file must be .jad. If the descriptor file is to be
delivered by a Web server, its MIME type must be:
text/vnd.sun.j2me.app-descriptor
The descriptor file must contain the following attributes:
•
•
•
•
•
MIDlet-Name – Name of the MIDlet suite
MIDlet-Version – Version of the MIDlet suite
MIDlet-Vendor – Organization that provides the MIDlet suite
MicroEdition-Profile – The required J2ME profile and version, such as MIDP-1.0
MicroEdition-Configuration – The required J2ME configuration and version, such as
CLDC-1.0
• MIDlet-Jar-URL – URL from which to download the JAR file
• MIDlet-Jar-Size – Number of bytes in the JAR file
• MIDlet-n for each MIDlet in the MIDlet suite; n is an identifier for the MIDlet,
generally numbered sequentially from 1 to the number of MIDlets. The syntax for
the information in this attribute is name, icon, class of the nth MIDlet in the JAR file.
Note: Icons must be in .png format.
SUN MICROSYSTEMS, INC.
42 of 57
Developing Applications with MIDP
The descriptor may contain the following optional attributes:
•
•
•
•
MIDlet-Description
MIDlet-Info-URL – URL for further information on the MIDlet suite
MIDlet-Data-Size
MIDlet specific attributes that do not begin with MIDlet-
The following is the MIDlet descriptor file for HelloMIDlet, HelloMIDlet.jad:
MIDlet-Name: HelloMIDlet
MIDlet-Version: 1.0.0
MIDlet-Vendor: Sun Microsystems, Inc.
MIDlet-Description: A Simple Example
MIDlet-Info-URL: http://java.sun.com/j2me/
MIDlet-Jar-URL: hello.jar
MIDlet-Jar-Size:
1063
MicroEdition-Profile: MIDP-1.0
MicroEdition-Configuration: CLDC-1.0
MIDlet-1: HelloMIDlet,, HelloMIDlet
In the last line of the preceding descriptor file, the double commas (,,) indicate that
there is no icon file associated with this MIDlet.
9.3.6 Testing the MIDlet on a Desktop System
You can test the complete MIDlet on a desktop system by running the midp executable
file on the descriptor file. The following sample command lines show how to test the
complete MIDlet. These examples assume the following:
• An environment variable, MIDP_HOME, has been defined to point to the root of the
MIDP installation directory. For example, on a Windows system where the default
installation directory was used, MIDP_HOME will be set to C:\j2me\midp-fcs.
• The MIDlet descriptor file, HelloMIDlet.jad, is stored in the same directory as
the preverified class file. In this example, the preverified class file is stored in the
directory preverified, a subdirectory of the directory containing the Java source
code.
To run the MIDlet on Windows, from the directory containing the MIDlet descriptor
file, type the following on one line:
%MIDP_HOME%\bin\midp -classpath preverified
-descriptor HelloMIDlet.jad
Note: If the descriptor file is not in the same directory as the preverified class file, the
emulator will not be able to find the MIDlet code without the option -classpath
preverified.
If everything is working properly, the emulator will start. The emulator contains an
image of a cellular phone with clickable buttons.
• To run HelloMIDlet, click the button with the dot that is surrounded by arrow
buttons.
• To exit the MIDlet, click the button immediately beneath the word Exit at the lower
right corner of the screen.
SUN MICROSYSTEMS, INC.
43 of 57
Developing Applications with the J2ME Wireless Toolkit
• To quit the simulator, do one of the following:
• Click the “Power” button in the upper left corner of the default skin
• Click the standard Windows X button
• Type CTRL-C in the command window
For more information on setting up and running a MIDlet, see
http://developer.java.sun.com/developer/technicalArticles/
wireless/midpsetup/.
9.4 Loading and Running a MIDlet on a Mobile Information Device
All devices capable of running MIDlets must have application management software.
This software is device specific and is used to install, interact with, and remove
MIDlets. A MIDlet may be made permanent, meaning that the MIDlet resides in
persistent storage on the MID. A user may run a permanent MIDlet repeatedly without
repeated downloads.
MIDlets have a well defined lifecycle consisting of five phases:
• Retrieval – The MIDlet must initially be downloaded from some source.
• Installation – The application management software must be able to install the
downloaded MIDlet on the device.
• Launching – The user must be able to select and launch the MIDlet.
• Version management – The user must be able to determine the version of the MIDlet
and upgrade the MIDlet if desired.
• Removal – The user must be able to remove an installed MIDlet.
9.5 Making HTTP Connections with MIDP
The JDC has published a Technical Tip entitled Making HTTP Connections With MIDP.
This article explains how to interact with the network using the Generic Connection
framework and is available from http://developer.java.sun.com/
developer/J2METechTips/2000/tt1218.html#tip2.
9.6 Optimizing MIDP Applications
There are methods available for optimizing applications that run on small devices
running MIDP. These are the same optimization techniques that are used with CLDC.
For information on these optimization techniques, see Section 8.3, “Optimizing CLDC
Applications.”
10.0 Developing Applications with the J2ME Wireless
Toolkit
The J2ME Wireless Toolkit is a development environment that can be used for
developing MIDP applications (MIDlets). The Wireless Toolkit provides development
tools, such as a bytecode preverifier and an emulator, as well as two different
SUN MICROSYSTEMS, INC.
44 of 57
Developing Applications with the J2ME Wireless Toolkit
development environments. The development environments allow the developer to use
the tools in an integrated manner. The J2ME Wireless Toolkit:
• Supports application development from start to finish: from Java source files to
MIDlet Suite, including JAR and JAD files, ready for deployment. The following
processes are simplified:
• Compiling the Java source files
• Preverifying the class files
• Packaging class files into JAR files
• Creating descriptor files
• Allows the developer to choose between three ways to use the development tools:
Two GUI-based development environments and operation by command line.
• Provides an emulator that allows the developer to run the application on different
emulated target devices.
The user’s guide provides complete instructions for using the Wireless Toolkit as a
development environment. After downloading and installing the Wireless Toolkit as
described in Section 7.0, “Downloading, Installing, and Uninstalling the J2ME Wireless
Toolkit,” the User’s Guide is available in the doc subdirectory of the installation
directory.
10.1 Developing Applications with the J2ME Wireless Toolkit
The development cycle for creating MIDlets with the J2ME Wireless Toolkit is the same
as the development cycle for creating MIDlets directly from MIDP. The Wireless
Toolkit automates and simplifies some of the steps, making the development cycle
easier. The MIDP development cycle is described in Section 9.3, “MIDP Application
Development Cycle.”
The J2ME Wireless Toolkit provides two GUI development environments, the
KToolBar and a plug-in to the Forte for Java Community Edition, and a command line
interface. No matter which development environment you use, the development cycle
when using the J2ME Wireless Toolkit is the same:
• Create a new project.
When using KToolBar, it prompts for the name of the project, then builds a directory
for that project in the default location C:\J2MEWTK\apps.
• Edit Java files using a program editor.
No program editor is included with the J2ME Wireless Toolkit, but if using the
Wireless Toolkit with Forte for Java, you can use the Forte for Java program editor.
Save the Java file in the directory C:\J2MEWTK\apps\<ProjectName>\src.
• Build the project.
The following steps are performed automatically when the project is built:
• Compile the project – If the source file has not been compiled, it is compiled
using the J2SE SDK compiler, verifying that the application is not using any
packages, classes or methods that are not part of the CLDC or the MIDP APIs.
SUN MICROSYSTEMS, INC.
45 of 57
Developing Applications with the J2ME Wireless Toolkit
The compiled .class files are stored in the directory
C:\J2MEWTK\apps\<ProjectName>\classes.
• Preverify the project – The MIDP preverifier is used to process the Java class files
and to check for the use of floating point operations and finalize methods in the
Java classes.
• Package project into a MIDlet Suite – The J2SE SDK JAR tool packages all the
preverified class files and the application resource files into a MIDlets Suite JAR
file. The Wireless Toolkit creates a JAD file and a manifest file containing the
appropriate MIDlet Suite attributes. The JAR, JAD, and manifest files are stored
in the directory C:\J2MEWTK\apps\<ProjectName>\bin.
• Test the project.
• Test the project using the emulator available as part of the J2ME Wireless
Toolkit. The emulator allows you to simulate the operation of the application on
different target devices.
• Test the application against a vendor specific emulation environment, such as the
environment available from
https://commerce.motorola.com/idenonline/iDEVELOP/.
• Test the application on the target device. The procedure for installing and
deploying the application on the device will vary depending on the device and the
implementation of the CLDC and MIDP for the device.
For complete instructions on building and running an application with the J2ME
Wireless Toolkit, see the appropriate section in the User’s Guide:
• Chapter 3 – Operating with KToolBar
• Chapter 4 – Operating with Forte for Java Community Edition
• Chapter 5 – Operating from the Command Line
The User’s Guide is available in the doc subdirectory of the installation directory.
10.2 Using the Emulator Available With the J2ME Wireless Toolkit
The emulator provided with the J2ME Wireless Toolkit allows you to test your
applications on a PC while simulating the behavior of the target devices for which the
application can be deployed. The emulator supplies run-time logging of various events,
including method tracing, garbage collection, class loading, and thrown exceptions.
Four types of devices are provided with the J2ME Wireless Toolkit emulator, allowing
you to test the portability of your application. They represent a range of displays and
features that are found in Mobile Information Devices. All are supported by the MID
Profile API Specification, so any MIDP-compliant application must be able to run on all
of them.
The four device types are:
• DefaultColorPhone
• DefaultGrayPhone
SUN MICROSYSTEMS, INC.
46 of 57
Developing Applications with the J2ME Wireless Toolkit
• MinimumPhone
• Pager
You can define additional devices, allowing you to emulate other devices, as described
in the following section.
10.3 Customizing the J2ME Wireless Toolkit
The Wireless Toolkit includes four emulated devices that run with the default emulator
that is included with the Wireless Toolkit. The default emulator is built primarily with
the source code for both CLDC and MIDP, with the addition of code that allows for
device customization. The Wireless Toolkit allows you to emulate new devices by
adding new device property files and new device emulators that have been developed
specifically for those devices.
You can customize the Wireless Toolkit by:
• Customizing the Default Emulator by changing its device property files but not its
code. In this case you continue to use the Default Emulator.
• Customizing the Default Emulator by changing or adding to its API code and
changing its device property files. In this case you build a new emulator to add to the
J2ME Wireless Toolkit, in addition to the Default Emulator.
• Customizing the J2ME Wireless Toolkit Development Environment to
accommodate the additional emulators you have built.
Only the first of these three customizations can be done by a developer using the J2ME
Wireless Toolkit binary product. If you have a source code license for the Wireless
Toolkit, you will be able to do all three of the customizations listed. Source code
licensees are provided with the document Java 2 Platform, Micro Edition, Wireless
Toolkit Customization Guide, which describes the customization process in detail.
With Version 1.0 of the Wireless Toolkit, the customization guide is only available
externally to licensees. Sun employees can access the customization guide from
http://javaweb.israel/kvmemul/midp/releases/1_0-fcs/
CustomizationGuide.pdf.
With later versions of the Wireless Toolkit, there will be a basic customization guide
and an advanced customization guide. The basic customization guide will be available
with the binary release. The advanced customization guide will be available to
licensees.
SUN MICROSYSTEMS, INC.
47 of 57
Troubleshooting CLDC
11.0 Troubleshooting CLDC
11.1 Product Limitations
11.1.1 Java Native Interface Not Supported by CLDC
For both size and security reasons, CLDC does not support the Java Native Interface™
(JNI™). Any native code called from the virtual machine must be linked directly into
the virtual machine at compile time. Invoking native methods is accomplished through
native method lookup tables, which must be created during the build process.
Macros are provided to make the implementation of native methods as easy and errorfree as possible. However, native methods are inherently complex, and the
consequences of mistakes are frequently severe. It is best to study the KVM Porting
Guide carefully before attempting to write your own native methods. The KVM Porting
Guide is available with the CLDC download.
11.1.2 No End-to-End Security Available
CLDC does not provide end-to-end security for any solution such as WAP that includes
a gateway for doing protocol conversion. The CLDC and MIDP specifications do not
cover security because there are already existing specifications developed by
IETF/W3C for TLS, which can be used on mobile devices. A team in Sun Labs has
developed a 60 KB SSL stack that can be used with CLDC, that completely circumvents
a WAP gateway on packet-based networks. Sun intends to make the KSSL source code
available for device manufacturers so that they can speed up the deployment of
SSL/TLS enabled devices.
11.2 Common Developer Questions
11.2.1 Published Lists of Frequently Asked Questions
Sun maintains a list of frequently asked questions (FAQs) for CLDC at
http://java.sun.com/products/cldc/faqs.html.
Sun maintains a list of FAQs for J2ME at http://java.sun.com/j2me/faq.html.
The jGuru website maintains a FAQ page for J2ME at
http://www.jguru.com/jguru/faq/faqpage.jsp?name=J2ME.
11.2.2 Building the CLDC Executable Files
The release notes and other documentation provided with the CLDC download give
detailed information on how to build the CLDC executable binary files. This
information is intended to be used by device manufacturers who wish to port CLDC to
their devices. When developing CLDC applications, it is not necessary to build the
CLDC binary files. The binary files are included with the download in the directory
bin. See Section 5.3.3, “Directories Created When Installing CLDC,” for a description
of the files and directories available with the CLDC download.
SUN MICROSYSTEMS, INC.
48 of 57
Troubleshooting CLDC
11.2.3 Palm Development Questions
In 1998 Sun developed a proof-of-concept implementation of CLDC for Palm devices.
This implementation is not supported, but still, many developers choose to use it to
develop applications for Palm devices. MIDP includes APIs that complement the
CLDC, and ideally, developers should wait to use the MIDP implementation for Palm
OS that will be available as an early access release in the first quarter of 2001 and as a
released product in the second quarter of 2001.
If developers choose not to wait for the MIDP implementation for Palm OS, there is
information available describing how to use the CLDC implementation for Palm and for
using the Palm OS emulator. The following are some articles that provide this
information:
• Sun’s Java Developer Connection has published an article that describes how to use
Sun’s CLDC with Palm, Setting up the KVM on your Palm and Getting Started with
the KVM, available from
http://developer.java.sun.com/developer/technicalArticles/
wireless/palm/
• Bill Day, a Sun technology evangelist, has published an article, Program your Palm
in Java: The PalmOS Emulator, available from
http://www.javaworld.com/jw-11-1999/jw-11-device_p.html
• Robert Evans, a computer scientist from Johns Hopkins University, has created a
tutorial, KVM on the Palm Pilot, available from
http://webdev.apl.jhu.edu/~rbe/kvm/
• The EarthWeb site has a tutorial, Creating Palm Pilot Software Using J2ME at
http://www.earthweb.com/dlink.resourcejhtml.72.1397.|repository||softwaredev|content|article|2000|0
8|03|SDfoxj2mekvm2|SDfoxj2mekvm2~xml.0.jhtml?cda=true
11.2.4 Abstract Windowing Toolkit for CLDC
Trantor has developed an Abstract Windowing Toolkit (AWT) for use with CLDC
called kAWT. Information on the kAWT is available from
http://www.trantor.de/kawt/.
kAWT is a proprietary set of APIs that has not been developed through the Java
Community Process (JCP). While kAWT may answer the requirements of some
developers, it does not provide the cross device compatibility that is offered by MIDP or
the PDA Profile.
11.3 Troubleshooting Utilities
Currently, adding System.out.println statements to the application is the only
method available for debugging in CLDC applications. The J2SE tools cannot be used.
Future versions of CLDC, MIPD, and the Wireless Toolkit will include source level
debugging support.
SUN MICROSYSTEMS, INC.
49 of 57
Troubleshooting MIDP
11.4 Known Bugs and Their Workarounds
To see a list of current bugs related to CLDC and the KVM, go to
http://developer.java.sun.com/developer/bugParade/index.jshtml
and choose the category K Virtual Machine.
12.0 Troubleshooting MIDP
12.1 Product Limitations
12.1.1 Palm OS Implementation Not Available With MIDP
Many developers have asked for a reference implementation of MIDP for the Palm OS.
Sun has recently announced that it will ship MIDP for the Palm OS platform. An early
access release will be available in the second quarter of 2001 and the final release will
be in the summer of 2001.
Palm applications can be developed using the CLDC implementation supplied by Sun,
but this implementation is not supported. See Section 11.2.3, “Palm Development
Questions,” for more information.
A Java Specification Request (JSR) submitted by Palm Computing for a PDA Profile
has been approved and is under development. The PDA profile will provide additional
APIs that will take full advantage of these devices’ capabilities, such as enhanced
database access and UI navigation system.
12.2 Common Developer Questions
12.2.1 Published Lists of Frequently Asked Questions
Sun provides a list of FAQs for MIDP available from
http://java.sun.com/products/midp/faq.html.
Sun maintains a list of FAQs for J2ME at http://java.sun.com/j2me/faq.html
The jGuru website maintains a FAQ page for J2ME at
http://www.jguru.com/jguru/faq/faqpage.jsp?name=J2ME
12.2.2 Building the MIDP Executable Files
The release notes and other documentation provided with the MIDP download give
detailed information on how to build the MIDP executable binary files. This information
is intended to be used by device manufacturers who wish to port MIDP to their devices.
When developing MIDP applications, it is not necessary to build the MIDP binary files.
The binary files are included with the download in the directory bin. See Section 6.3.3,
“Directories Created When Installing MIDP,” for a description of the files and
directories available with the MIDP download.
If you need to port and build MIDP, see the MIDP Porting Guide available with the
MIDP 1.0.1 release.
SUN MICROSYSTEMS, INC.
50 of 57
Troubleshooting the J2ME Wireless Toolkit
12.2.3 Running a MIDP Application in Color
The MIDP reference implementation supports several color ranges. The color ranges are
controlled by the environment variable SCREEN_DEPTH. To set the display to color, set
SCREEN_DEPTH to the value 8.
12.2.4 Creating a Socket Connection
The socket protocol is not part of the MIDP 1.0 specification or CLDC 1.0 specification.
Unofficial support might be available if you define the environment variable
ENABLE_CLDC_PROTOCOLS to any string, however, this is not supported.
12.2.5 Running MIDP Applications from Behind a Firewall
Set the environment variable HTTP_PROXY to identify the HTTP proxy to be used when
working through a firewall.
12.2.6 Other Environment Variables
Other useful environment variables may be described in the documentation shipped
with the device.
12.3 Troubleshooting Utilities
Currently, adding System.out.println statements to the application is the only
method available for debugging in MIDP applications. The J2SE tools cannot be used.
Future versions of CLDC, MIPD, and the Wireless Toolkit will include source level
debugging support.
12.4 Common Developer Problems
The most common problem reported is forgetting to preverify the class files before
running them.
12.5 Known Bugs and Their Workarounds
There is a list of known bugs in the release notes for MIDP. The release notes are in the
file index.html available at the root of the installation directory after extracting the
download file.
To see a list of current bugs related to the MIDP reference implementation, go to
http://developer.java.sun.com/developer/bugParade/index.jshtml
and choose the category JSR-37 Specification and RI.
13.0 Troubleshooting the J2ME Wireless Toolkit
13.1 Product Limitations
The J2ME Wireless Toolkit contains the following limitations:
• Limited platform support:
• No support for Linux or Solaris
SUN MICROSYSTEMS, INC.
51 of 57
Troubleshooting the J2ME Wireless Toolkit
• No official support for Windows NT or Windows 2000
• No support for Windows 95
• No source level debugging support. Source level debugging support will be added in
the future release based on CLDC 1.1.
• Full internationalization support not available with version 1.0, although it will be
available with version 1.0.1.
• Only integrated with Forte for Java. It is hoped that future releases will be integrated
with additional IDEs.
13.1.1 J2ME Wireless Toolkit Only Supported on Windows 98
The feature most requested for the J2ME Wireless Toolkit is a version that will run on
Linux or Solaris. The current release of the J2ME Wireless Toolkit is supported only on
Windows 98. While not supported on Windows NT and 2000, it should run on those
platforms. The J2ME Wireless Toolkit cannot be used with Windows 95.
13.1.2 J2ME Wireless Toolkit Emulator Limitations
There are three device behaviors that cannot be tested with the J2ME Wireless Toolkit
emulator:
• Application management behavior – An application manager is used on a device to
control installation, removal, and other operations on applications. The emulator
does not emulate application management.
• Speed of execution – The emulator does not include a mechanism that simulates the
speed of application execution on a target device. Thus the application may execute
at a different speed on the target device than it does on the emulator.
• Memory capacity – The emulator does not include a mechanism that simulates the
Java heap size that is available on a target device. Thus, the memory available for the
application to store objects and classes on the emulator may be different from the
one available on a real device.
13.1.3 No Source Level Debugging Available
The J2ME Wireless Toolkit does not support source level debugging at this time, but
this feature will be added in a future version of the product.
13.1.4 Pointer Devices Not Supported by Emulator
In the J2ME Wireless Toolkit 1.0, pointer device events are supported in the Canvas
class of MIDP, but the emulator implementation in the J2ME Wireless Toolkit does not
currently include support for pointer devices. Support will be added in version 1.0.1.
13.2 Common Developer Questions
13.2.1 Published Lists of Frequently Asked Questions
Sun provides a list of FAQs for the J2ME Wireless Toolkit available from
http://java.sun.com/products/j2mewtoolkit/FAQ.html
Sun provides a list of FAQs for MIDP available from
http://java.sun.com/products/midp/faq.html.
SUN MICROSYSTEMS, INC.
52 of 57
Troubleshooting the J2ME Wireless Toolkit
Sun maintains a list of frequently asked questions (FAQs) for J2ME at
http://java.sun.com/j2me/faq.html
The jGuru website maintains a FAQ page for J2ME at
http://www.jguru.com/jguru/faq/faqpage.jsp?name=J2ME
13.2.2 Problems Installing the J2ME Wireless Toolkit
Some developers run into problems when installing the J2ME Wireless Toolkit. For
details on common problems and solutions, see Section 7.6, “Common Problems with
Installation.”
13.2.3 Displaying Japanese Characters
Japanese is not supported in J2ME Wireless Toolkit 1.0. However, if you are using a
Japanese version of Windows and your MIDlet uses Unicode Japanese characters, then
they may be displayed correctly. The ability to input Japanese characters is not
supported in version 1.0. Version 1.0.1 will be internationalized. Internationalization for
input and output characters, including Japanese, will be available.
13.2.4 Using the J2ME Wireless Toolkit to Develop Applications for Palm OS
The J2ME Wireless Toolkit can be use to develop applications for any device for which
there is a compliant MIDP implementation. At this time, Sun does not provide a MIDP
implementation for devices using the Palm OS; Sun plans to offer a MIDP
implementation for the Palm OS in the second quarter of 2001. The Wireless Toolkit
does not currently provide emulation capabilities for testing a MIDP application
intended for a Palm device, but might include Palm emulation capabilities in a future
release.
13.2.5 Creating New Devices for the Emulator
Emulator files for new devices are usually created by device manufacturers. The source
release of the J2ME Wireless Toolkit includes documentation on customizing the
Toolkit to add new devices.
13.2.6 Creating an HTTP Connection
If you are working from behind a firewall and you cannot create an external connection
using HttpConnection, set the appropriate proxy connections in the Emulator
Preferences window. The Preferences window is available on the KToolBar from the
Edit menu and in Forte for Java from the Project Settings window.
13.3 Troubleshooting Utilities
When running an application from the J2ME Wireless Toolkit emulator, traces can be
turned on to aid in debugging.
When running KToolbar, traces are turned on from the Emulator Preferences window.
The Preferences window is available on the KToolBar from the Edit menu.
When running from Forte for Java, traces are turned on by selecting Project → Settings
on the main menu bar to get the Project Settings window. From the Project Settings
window, right-click KVM Emulator and click Customize.
SUN MICROSYSTEMS, INC.
53 of 57
Reference Information
The following traces can be selected:
• Trace garbage collection
• Trace class loading
• Trace Exceptions – causes all exceptions to be logged to the console window, even if
they are caught by the application code
• Trace method calls – generates lots of output
13.4 Known Bugs and Their Workarounds
There is a list of known bugs in the release notes for the J2ME Wireless Toolkit. The
release notes are in the file BinaryReleaseNotes.html available at the root of the
installation directory after installing the download file.
14.0 Reference Information
14.1 Product Information
14.1.1 CLDC Product Information and Downloads
• CLDC product page –
http://java.sun.com/products/cldc/.
• CLDC 1.0 specification –
http://java.sun.com/aboutJava/communityprocess/final/jsr030/
• CLDC reference implementation –
http://www.sun.com/software/communitysource/j2me/
download.html
14.1.2 MIDP Product Information and Downloads
• MIDP product page –
http://java.sun.com/products/midp/
• MIDP 1.0 specification –
http://java.sun.com/aboutJava/communityprocess/final/jsr037/
• MIDP reference implementation –
http://www.sun.com/software/communitysource/midp/
download.html
14.1.3 J2ME Wireless Toolkit Product Information and Downloads
• J2ME Wireless Toolkit product page –
http://java.sun.com/products/j2mewtoolkit/
• Product download page –
http://java.sun.com/products/j2mewtoolkit/download.html
SUN MICROSYSTEMS, INC.
54 of 57
Reference Information
14.1.4 Other J2ME Information
• J2ME product page –
http://java.sun.com/j2me/
• Bill Day’s J2ME Archive –
http://www.billday.com/j2me/
• KVM World –
http://www.kvmworld.com/
14.1.5 Information on Related Products
• Java 2 Standard Edition –
http://java.sun.com/j2se/
• Forte for Java Community Edition –
http://www.sun.com/forte/ffj/ce/.
14.2 Frequently Asked Questions
• Sun’s J2ME FAQ page –
http://java.sun.com/j2me/faq.html
• jGuru’s J2ME FAQ page –
http://www.jguru.com/jguru/faq/faqpage.jsp?name=J2ME
• Sun’s CLDC FAQ page –
http://java.sun.com/products/cldc/faqs.html
• Sun’s MIDP FAQ page –
http://java.sun.com/products/midp/faq.html.
• Sun’s J2ME Wireless Toolkit FAQ page –
http://java.sun.com/products/j2mewtoolkit/FAQ.html
14.3 Training Courses
• Sun Education Web-based course, An Introduction to J2ME and the MID Profile
(Course number WJ-4500-V1) –
http://suned.sun.com/USA/wlc/wlcjava_live.html.
• Code Camp J2ME Wireless Programming –
http://www.sun.com/developers/edu/camps/
14.4 Books, Articles, and Tutorials
14.4.1 Books
• Java 2 Micro Edition: Professional Developer’s Guide by Eric Giguere –
Information about the book is available from
http://www.ericgiguere.com/j2mebook/
14.4.2 J2ME White Papers
• Java 2 Platform Micro Edition Technology for Creating Mobile Devices –
http://java.sun.com/products/cldc/wp/KVMwp.pdf
SUN MICROSYSTEMS, INC.
55 of 57
Reference Information
• Applications for Mobile Information Devices –
http://java.sun.com/products/midp/midpwp.pdf
• Java Technology and the New World of Wireless Portals and mCommerce –
http://java.sun.com/products/midp/mcommerce.html
14.4.3 Java Developer Connection Articles and Tutorials
• Wireless programming using J2ME –
http://developer.java.sun.com/developer/technicalArticles/
wireless/
• Quick start guide to the J2ME Wireless Toolkit http://developer.java.sun.com/developer/technicalArticles/
wireless/wirelesstoolkit/
• Introduction to Wireless Programming with the MID Profile –
http://developer.java.sun.com/developer/technicalArticles/
wireless/midp/
• Setting up the MIDP environment –
http://developer.java.sun.com/developer/technicalArticles/
wireless/midpsetup/
• J2ME Development Cycle –
http://developer.java.sun.com/developer/J2METechTips/2000/
tt1218.html.
• Making HTTP Connections With MIDP –
http://developer.java.sun.com/developer/J2METechTips/2000/
tt1218.html#tip2.
• Setting up the KVM on your Palm and Getting Started with the KVM –
http://developer.java.sun.com/developer/technicalArticles/
wireless/palm/
14.4.4 Webcasts and Transcripts of Online Chats
• Transcript of J2ME Basics with Eric Giguere–
http://developer.java.sun.com/developer/community/chat/
JavaLive/2000/jl1205.html
• Transcript of J2ME for Wireless with Bill Day and Roger Riggs –
http://developer.java.sun.com/developer/community/chat/
JavaLive/2000/jl1024.html
• Audioast: “Developing Wireless Applications using J2ME,” presented October 18,
2000 by Bill Day –
http://developer.java.sun.com/developer/onlineTraining/
webcasts/amsterdam/bday.html
• JavaOneSM 2000 conference session webcasts –
http://java.sun.com/javaone/javaone00/replay.html
• Replay of Cyber Seminar “Wireless Java Technology Solutions,” presented on
November 30, 2000 http://www.sun.com/software/cyber/replay.html
SUN MICROSYSTEMS, INC.
56 of 57
Reference Information
14.4.5 Palm Development Articles and Tutorials
• Bill Day’s Program your Palm in Java: The PalmOS Emulator –
http://www.javaworld.com/jw-11-1999/jw-11-device_p.html
• Robert Evans’ KVM on the Palm Pilot –
http://webdev.apl.jhu.edu/~rbe/kvm/
• The EarthWeb site’s Creating Palm Pilot Software Using J2ME –
http://www.earthweb.com/dlink.resourcejhtml.72.1397.|repository||softwaredev|content|article|2000|0
8|03|SDfoxj2mekvm2|SDfoxj2mekvm2~xml.0.jhtml?cda=true
SUN MICROSYSTEMS, INC.
57 of 57