Oracle Java SE Embedded: Developer's Guide

1 Introducing Oracle Java SE Embedded

Learn the advantages of using Oracle Java SE Embedded technology on your devices, and which of the Java SE Embedded documents will be most relevant to accomplishing your goals.

This page contains the following topics:

Embedded Systems: The Wave of the Future

Embedded systems are computer-based but unlike desktop computers and their applications. An embedded system's computer is embedded in a device. The variety of devices is expanding daily.

Photographs of various devices
Description of device-list.png follows
Description of the illustration device-list.png

Many embedded systems are headless, meaning they have no conventional user interface: no keyboard, no mouse, and no display. These systems respond to sensor inputs, such as thermometers and accelerometers. They respond by adjusting actuators, such as indicating alarms or sending messages. A headless system that is connected to a network can run a web server and provide a web-based user interface.

As hardware costs decrease, headful embedded systems are increasingly common. Although users interact with such systems, typically by means of buttons or touch-sensitive displays, the devices do not look like, or behave like, a desktop computer. Figure 1-1 shows an example of a headful embedded system. In this example, for demonstration purposes, the embedded computer is visible through a window in the case.

Figure 1-1 Headful Embedded System Example: A Kiosk

Description of Figure 1-1 follows
Description of "Figure 1-1 Headful Embedded System Example: A Kiosk"

Embedded systems typically have attributes that make them quite different from desktop applications:

  • Their functions are fixed at the factory; they are dedicated, not general purpose. Their workload is predictable.

  • They use custom hardware (sensors and actuators).

  • They are carefully optimized in multiple dimensions to use the least computational resources that will meet requirements.

  • They do not tolerate malfunction. Usually, an embedded system cannot be fixed after it is deployed.

  • With few resources, special purpose hardware, and high demand for correct operation on day one, they are hard to develop software for.

Why Use Java for Your Embedded System?

Embedded system applications were once written in assembly language. But as embedded computer hardware resources grew, pressures such as time-to-market and development cost drove a shift to the more portable and less error-prone C and C++ languages. These languages required more memory and more CPU cycles, but declining hardware costs and rising software complexity made the trade worthwhile.

Continuing this progression, Moore's Law and other factors have more recently made Java increasingly attractive for embedded system development. These other factors include a worldwide population of Java developers who have trained in enterprise and other non-embedded domains. This talent and knowledge can be extended to embedded systems by developing their application code in the Java programming language.

Java is:

  • A modern, object-oriented, language without the error-inducing complexity of C++. Objects are natural representations for sensors and actuators.

  • Less prone to errors than C. For example, there are no pointers, and memory management is automatic.

  • Highly portable; Java classes do not need to be recompiled to run on a different CPU or operating system.

  • Security-oriented. Java libraries support encrypting sensitive data sent to or from embedded devices, and validating digitally signed code downloaded to update or extend embedded applications in the field.

  • Multi-threaded, enabling the natural expression of parallel activities and their simultaneous execution on platforms whose operating system thread model takes advantage of multiple CPU cores.

  • Equipped with a large collection of OS-independent libraries including database access and graphical user interfaces.

  • Tunable to match hardware resources and application needs. For example, there are multiple options for runtime compilation to native instructions, and for how and when unused (garbage) memory is reclaimed.

  • Extensible with native methods written in C that interact with special purpose embedded system hardware.

  • Debuggable on the desktop and remotely. A desktop Java Runtime Environment (see Which Java Embedded is Right for Your Device?) has the same APIs as one that runs on an embedded computer, except for hardware-specific interfaces and behaviors. Most functional debugging can be done on a desktop computer. An embedded system that has a network connection can be debugged and profiled remotely.

Which Java Embedded is Right for Your Device?

Oracle offers three Java Runtime Environment product families:

  • Java Platform, Standard Edition (Java SE): For Macintosh, Windows, Linux, and Solaris desktop and server class computers. Hardware resources for JREs and Java applications are rarely an issue on these computers. For more information, see

  • Oracle Java SE Embedded: For embedded systems with tens of megabytes of memory for a JRE and Java applications, with or without graphical user interface hardware. Oracle Java SE Embedded is described in this document.

  • Oracle Java Micro Edition Embedded (Oracle Java ME Embedded): For headless embedded systems on devices that have a megabyte or less of memory for a JRE and applications. For more information, see

A Java Runtime Environment (JRE) enables and supports the safe execution of portable Java program instructions (bytecodes) on a particular CPU and operating system. A typical JRE has several components, including:

  • A JRE's Java Virtual Machine (JVM) verifies and translates bytecodes into CPU instructions and arranges for them to be executed.

  • A JRE's memory manager interacts with the computer's operating system to allocate dynamic (heap) memory and automatically reclaim it (collect garbage).

  • A JRE's application programming interfaces (APIs) provide services, such as file systems, database access, and graphical user interfaces. These services are sometimes implemented on corresponding operating system services, but insulate Java applications from operating system dependencies.

  • A JRE's resource files store data such as time zones, fonts, and locales.

  • A JRE's launcher is an operating system command that starts a JRE running a Java application.

Although by definition, JREs must be similar to make Java application code portable, they can differ in composition. For example, different virtual machine designs can take advantage of resources available on some computers but not on others.

The Heart of Java SE Embedded: Customize Your Runtime Environment

The Java Runtime Environment (JRE) consists of a Java Virtual Machine (JVM) plus Libraries and Toolkits.

Oracle Java SE Embedded is a set of components from which you can build a custom JRE that meets your application's functional requirements without sacrificing memory to unneeded JRE features. All custom JREs are functional subsets of the Oracle Java SE JRE, which means that you can develop and functionally test embedded application code on desktop computers, except for classes that depend on the presence of special-purpose embedded hardware. You can also reuse application classes in desktop, server, and embedded applications.

You use the jrecreate tool to select the size of the JVM to be installed and the profile to be included as components of the custom JRE. The JVM you choose depends on performance characteristics, and the profile depends on the libraries used by the applications that will run on the device. As you develop applications, you can use the jdeps tool to determine the minimum profile required for your application.

Close Window

Table of Contents

Oracle Java SE Embedded: Developer's Guide

Expand | Collapse