10 Essentials for Developing Embedded Applications
This chapter describes the fundamentals of developing Java applications that run on an Oracle Java SE Embedded custom JRE.
This chapter contains the following topics:
Host Development for a Target Device
The fundamental difference between conventional and embedded Java programming is the presence of a second computer, called the target. The target is embedded in a device — a printer, a medical instrument, an industrial tool, or whatever houses the embedded system.
If the target has sufficient resources and is supported by the Java SE Development Kit (JDK), you can develop an embedded application on it, as you would develop a Java desktop application or a Java server application. Resources include CPU cycles, memory, file system, display, pointing device, and keyboard. Click the Download button on the Java SE download page to see a list of the processor-operating system combinations for which JDKs are available: http://www.oracle.com/technetwork/java/javafx/downloads/
Resource-rich targets are rare. By contrast, desktop and laptop computers are common, inexpensive, familiar, and have resources in abundance. An array of software development tools, such as integrated development environments and code repositories, is also available for desktop and laptop computers. Accordingly, embedded application development is usually divided between a desktop or laptop computer, called a host, and the target.
You use the host computer to write and compile source code, to perform functional testing, to package the compiled application into an executable Java archive (JAR) file, and, possibly, to remotely start and stop applications on the target. See Develop and Test Your Embedded Application and Deploy Embedded Applications for details.
Host-Target Development Cycle
Figure 10-1 shows that embedded application development is the same as conventional Java application development, with an additional activity: performance testing on the target. Performance testing, as the term is used here, means running the application on the actual deployment hardware to discover hardware-specific issues. These might include excessive memory consumption, insufficient speed, race conditions, and problems with peripherals, including displays, sensors, and actuators. Functional testing on the host computer cannot reveal these conditions, but it can expose problems in core application behavior.
Figure 10-1 Fundamental Embedded Development Cycle
Description of "Figure 10-1 Fundamental Embedded Development Cycle"
Because custom JREs support networking and can support remote Java debugging and profiling, you can copy JARs to, and run performance tests on, a target that is located in another room, building, or continent.
APIs and Javadocs
The Java SE API documentation displays profile information. Figure 10-2 shows an example of an interface that is not in the compact1 profile APIs. Its definition explicitly names the compact2 and compact3 profiles. All interfaces are implicitly in the full JRE APIs.
Figure 10-2 Example Javadoc Showing an Interface in Two Profiles
Description of "Figure 10-2 Example Javadoc Showing an Interface in Two Profiles"
Native Methods
Embedded applications sometimes need access to target device hardware for which there is no Java API. Sensors and actuators are typical examples. Typically, device access functions are available in C. You can call these functions from Java by creating intermediating native methods. For a description of the Java Native Interface (JNI), see the JNI specification in the Java SE Developer Guides.
For a simple example of JNI, see the Oracle MoonOcean blog at https://blogs.oracle.com/moonocean/entry/a_simple_example_of_jni
JDK 7 Limitations
If you want to use JDK 7, observe this caution:
Note:
When using JDK 7, ensure that you use only APIs included in the custom JRE created for your device by the platform developer (See About Compact Profiles). If your application uses an API that is not present in the target device's custom JRE, the host's JDK 7 compiler and runtime mask your error. When you test the application on the target device, its custom JRE throws a ClassNotFoundException. Test early and periodically on the target to detect this error promptly.
Also, the jdeps tool is not available in JDK 7.
