CEE-J for communication devices
 About
the Communication Device Profile
The CEE-J communication device profile is a specification of a
compact Virtual Machine and class libraries. The profile has
support for graphics, networking, limited database support,
and contains selected classes from the io/lang/util packages.
This profile is targeted for handheld wireless devices such
as cell phones, messaging devices and wireless PDAs.
For small devices, the smaller profile has many benefits over
the full size pofile. One key advantage is size. A full size
implementation can take several megabytes of combined static
storage and RAM. In contrast, a the miniture implementation
can often run comfortably in 512k or less. Additionally,
the GUI components are designed for devices with smaller
screens and limited keyboard/keypad input.
An evaluation kit from Skelmir is available for our
CDP implementation. It consists of the VM, the standard
class libraries and a Win32 emulation environment.
Contact us if you
are interested in evaluating it.
Here are some useful links for more information.
CEE-J for for communication devices
Size
Size is an important consideration when evaluating
any virtual machine implementation. CEE-J provides a
solution that requires a minimal amount of both RAM
and static storage (ROM, flash). The virtual machine
and class libraries require approximately 250k of
static storage on the device, depending on the target
OS and chipset. Finally, at runtime CEE-J requires
approximately 250k of RAM to execute simple midlets.
The exact amount of RAM required is dependant on the
executing midlet's memory requirements.
CEE-J provides support for the creation and execution of ROMized
class files. These files are pre-linked and are executed directly
out of ROM thereby reducing the amount of RAM required for
their execution.
Platforms Supported
The miniturized version of CEE-J runs on the same platforms as
the full CEE-J VM. We support numerous chips, operating systems,
and compilers with ongoing support for additional configurations.
Some of the chips supported include PPC, MIPS, XScale, ARM,
StongARM, 68k, SH3/4, and x86. See the
CEE-J Technical Specifications
page for more information.
Compatibility
The full version of CEE-J passes several publicly available test
suites, including the extensive Modena and Mauve test suites.
Additionally, the CEE-J's miniture VM complies with the
Mobile specification.
Availability
Immediately! CEE-J is available today for licensing.
Contact us for
more information on licensing or evaluating CEE-J.
 Features
and Benifits of CEE-J
Cross-platform Graphics Library
CEE-J uses CWT (CEE-J Windowing Toolkit),
a cross-platform graphics library, in it's implementation
of the LCDUI package. CWT provides drawing primitives,
font rendering, and event notification. Because CEE-J is
not tied to a specific platform's graphics API, it is
possible to port CEE-J quickly to other platforms.
Also, CEE-J can target platforms and operating systems
without their own graphics APIs.
No File System Necessary
The CEE-J virtula machine implementation does not require a
file system. This can be useful for devices with minimal
operating systems.
Record Management System
The Record Management System (RMS) provides a simple
database/record storage system. Midlets can use this
to store preferences, cache web pages, or save PIM-type
information.
CEE-J's implementation of RMS uses abstract storage
layers. The RMS code talks to the storage layer, which
handles the task of reading/writing
the data on persistent storage. This abstraction layer
allows CEE-J to easily handle different types of
persistent
storage mechanisms. For example, on PalmOS the RMS system
takes advantage of the native DBS system and uses it
to store/retrieve records. The default storage layer
uses POSIX file system-calls to read/write to a
database..
Midlet Manager
The Midlet Manager coordinates various midlets
on the device: launching, pausing/resuming,
and stopping them. This portion of the class libraries
typically needs to be customized for each target device.
Skelmir has an implementation of a generic Midlet Manager.
Flexible Keyboard/Keypad Input
A virtual machine implementation needs to handle input
from several types of devices: keyboards, numeric
keypads, and touch-screens. CEE-J handles these
various devices by implementing different input method classes.
Each class corresponds to a particular input device.
The specific input method used can be selected at compile-time
or run-time. This flexible architecture gives CEE-J
the ability to handle input from keypads, keyboards,
or touch screens.
Input/Output Connection Types
CEE-J uses a flexible input/output streaming architecture.
Input/output streams are created using the standard Connector
class. For example, you would call Connector.open("http://www.skelmir.com")
to create a HTTP stream.
CEE-J supports several different types of IO streams including
HTTP, TCP/IP sockets, TCP/IP datagrams, POSIX's files, and
resource streams. More types are available as necessary.
Flexible Feature Set
CEE-J deployments offer the ability to add additional features to the
VM as required. For instance, a customer can add JNI (or the smaller,
faster CEE-J Native Interface) in order to write native methods. These
native methods can expose platform specific functionality or be used to
tune the system's performance. Optionally, the VM could be configured to
exclude unneeded components, lowering the installed VM's footprint.
Additional VM features can include
-
JNI (Native Interface) / SNI (Skelmir Native Interface) - allows
native software evocation from the virtual machine environment.
-
JDWP (provides
the ability to debug your source code on the target device)
-
Real-time extensions
|
