What Exactly is Java Micro Edition?

The term "Java Micro Edition" has historically been a trademark used to describe and sell a number of Java technologies under one moniker. It labels a software product line that organizes classes of resource-limited devices. The variant factors it identifies are the:

• cost of security run-time checks, a.k.a. the sandbox,
• footprint in memory of the built-in set of classes. a.k.a. the boot classpath ,
• way activities are dispatched a.k.a. the framework or lifecycle and
• facilities that are additionally available on the device a.k.a. optional packages.

For example, for a blue-ray disk player the applications will:

• have a limited and fairly fixed need for security checks,
• want to run in a medium memory space, and hence have very limited basic API without frills,
• want to respond to tray opening and closing events and input from a remote control
• want to build on vendor-features

The BD-J standard describes this application. We will use BD-J as our running example.

Anatomy of the ME Software Product Line

Every Java Micro Edition framework is different. Taking into account optional packages, even every specific device deployment may be different.
This is exactly the scope of a software product line. A software product line uses configuration rules to create software artefacts that are different, but have related sets of features. All Java Micro Edition applications are embedded in a corresponding framework that is specific to the domain of a device type, including tailoring to hardware and network resources typically available in that device domain.
The ME specifications express this software product line as a set of Java Specification Requests (JSRs) that define the foundation of the platform, plus a set of optional extension JSRs.
The class diagram below is intended to describe the variation points of the specification. In other words, it describes how the Java ME Standards are connected via concepts. We will take a walk around the diagram and explain the items step by step. As we walk around, we will provide examples as necessary.

Before we start, let me first explain how the diagram is organised and what is not shown on it. The diagram starts with the application at the top, as this is the view of software developers towards the infrastructure; we want to follow this perspective. The diagram focuses on packages rather than classes, as most discussion of infrastructure discussion revolves around this concept. The diagram highlights concepts that are relevant for security in red, because we focus on this aspect later in the series. It leaves out aspects connected to the syntax of the language. We will cover that aspect later in detail.
In the diagram, we find three top-level packages:
An Application is the portion of the ME application that is designed by the software developer. It is expressed as a set of classes. The classes are organized into packages and depend on other classes provided in packages that either directly represent the surface of the Java VM, or are contributed as a library from somewhere else.
Based on the Profile, the methods that form the entry points of activity of the application differ. While the Java Virtual Machine only has one entry point, the main() Method, in Java ME this method is never implemented directly in applications. Instead, the framework of the profile used by the application defines entry points. A profile is a set of packages provided for the application domain. The domain classes in the profile implement the original main method and then provide a dispatch mechanism for the application classes that fits the environment and models typical events, like expiry of a timer, push of a button, or pull-up of an IO line. The framework usually creates a thread and then has the thread enter the application through an entrypoint. In BD-J programming, pressing buttons on the TV remote control and updates to the digital TV channel guide are sources of events that can be used by the profile framework to dispatch the application. This dispatch mechanism is called Xlets and resides in the Java TV API ( JSR 927 ). Typical engagement areas for a profile are:

1. Cellular network support
2. Media support
3. Power management
4. Software management
5. Line-oriented user interfaces
6. Device user key-input abstraction

If the profile’s domain is intended for devices that usually include a network connection, then a corresponding package will usually be available.
Profiles can form a “stack”: More complex profiles can be built on simpler profiles by dependency. This is not an encapsulating relationship. The features of all profiles in the stack are available to the application. An example of such a stack is formed by the Foundation Profile (JSR 219), which is included in the Personal Basis Profile (JSR 217), which is included in the Personal Profile (JSR 216). The Personal Basis Profile is also the basis for the BD-J profile.
Ultimately, all events are received from the libraries of the operating system through the Java Virtual machine process. We will see later on that there are two different ways to achieve this transfer. These different ways to interact with the operating system distinguish Java ME and Java SE fundamentally.
Before we come to the next piece of the Java ME jigsaw, I would like to motivate why this piece is actually necessary. For anyone who has had a comparison of Java with compiled native code in C, C++, or Go it is clear that Java is not a naturally frugal language and its most salient features - garbage collection and reflection - can consume substantial processing time and resources. If we have a fast processor and a large amount of main memory, which is the case most contexts nowadays, we can implement these mechanisms elegantly and effectively. But if we need to squeeze into the resource space of an embedded system in a wrist watch or kitchen blender, we will need to resort to simpler and more frugal approaches of implementing these features if we insist on using Java in this Internet of Things context. Such considerations are also true for the design of the compiled class files we use. For size reasons, we may drop embedded debug symbols that allow us to correlate execution to source code and we may remove the corresponding mechanism from the virtual machine. We may decide to minimise the set of classes or restrict the ones we ship in the device based on actual usage in the application. And so on.
All of these choices do not in the end imply that we have a different language. It is still Java, but tailored to its environment. We can still work with it in much the same way, but with some limitations. However, in order to retain Java’s greatest advantage – the portability of compiled code – we need to describe clearly how we have tailored Java for our context. This clear definition is a Java configuration.
A configuration is a specified and documented way in which the features of a Java Virtual Machine environment are adapted for a certain performance footprint of the environment. The term configuration implies that all Java products are essentially variants of the same recipe, which always includes a virtual machine that executes the code, a core API that allows access to the virtual machine and a compiler that allows to produce new classes based on source code that build on the core. We merely configure some features to be on or off when we build the design. For the Blue-Ray Player mentioned in the example, the configuration is the Connected Device Configuration 1.1 ( JSR 218 ).
The current configurations in Java ME vary in the following factors:

1. The set of virtual machine runtime features, including a byte code format, security and networking features. All code based on a configuration must be produced by a compiler that produces compatible classes. These features are derived as subsets or variations of the Java Virtual Machine Specification.
2. The core platform API that exposes the features of the virtual machine. All code based on a configuration must be transitively linked against this API. These classes are either semantic subsets of classes in the Java SE API with identical fully qualified names, or independent designs with unique names that have been introduced for the purpose of simplification.
3. 3. Source code-level language features, i.e. a syntax format. All source code intended for the Java compiler of a configuration must use the language features defined. Otherwise, the compiler will not be able to accept them as input.
4. An implementation realizes the specification of the configuration. It provides
   1. a virtual machine ( JVM ),
   2. the classes on the boot classpath ( BootClassPathImpl ) that ultimately make use of VM features via native class implementation mechanisms and
   3. usually a compiler and associated tool chain to create classes from source code.
   4. For the CDC 1.1 in the Blue-Ray example there is a reference implementation, provided with the standard, and a HotSpot implementation developed by Sun Microsystems.
5. Finally, some profiles can be extended by optional packages . These packages may be present in the respective domain, but an application should not rely on them and should query for using a mechanism provided by the profile. For example, an SMS sender package could be missing, so features based on that should be disabled.

From this perspective, all Java Micro Edition applications are embedded in a corresponding framework that is specific to the domain of a device type, including tailoring to hardware and network resources typically available in that device domain. Every Java Micro Edition framework is different. Taking into account optional packages, even every specific device deployment may be different. This limits the Java mantra of ‘write once, run everywhere’.