Home

  Specifications
  Java Docs
  The ESR Consortium
  Become Member

  Log In

  Contact

  Links

Java™ is also a Sun Microsystems' trademark (see legal).

Log in

 

List of released and in-progress ESRs

Number Name Quick Description Lastest Released Version Current Working Version APIs Java doc
001 B-ON Beyond

This B-ON specification focus on devices that have non-volatile memories and volatile ones (eeprom, flash, ram,...). At the application level, it focuses on applications that have some sort of initialization phase before entering into a mission phase that then exists forever until the device gets shutdown or reboots.

B-ON allows to fully control both memory usage and start-up sequences on devices with limited memory resources:
  • controlling the initialization sequence in a deterministic way,
  • defining persistent immutable read-only objects that may be placed into non-volatile memory areas, and do not require copies to be made in ram to be manipulated: they are alive at system startup.
  • defining immortal read-write objects that are always alive.
B-ON serves as a very robust foundation for implementing embedded Java software.
1.2


(rev D)
n/a
021 EDC Embedded Device Configuration

Embedded Device Configuration defines the “lowest common denominator” standard APIs for a wide range of embedded devices, and is transversal accross many markets and provide APIs that are generic.

1.0


(rev B)
n/a
002 MicroUI User Interface for embedded systems

MicroUI, Micro User Interface, aims at providing the minimal cornerstone for the quick construction of advanced, portable and user-friendly applications for a wide and heterogeneous range of cost effective devices with just-what-is-needed resources. MicroUI has many notable characteristics that makes it a very attractive solution for embedded software development. MicroUI serves as a very robust foundation for implementing complex widget and/or windowing systems. Typical devices have some form of display, some input sensors and potentially some sound rendering capabilities. This specification spans a potentially wide set of devices.

MicroUI takes its roots from established patterns such as MVC and MVP. It allows anyone to use MicroUI with minimal learning cost: MicroUI is a straightforward framework to design with. The main asset of MicroUI is probably its flexibility to fit customer needs at minimal cost: rapid design of HMIs without jeopardizing the Bill Of Material of the device.

MicroUI is multi-displays ready and multi-touch ready. Other main features are:

  • Models, Listeners, Events, Event generators, Event handling, Pumps, Thread safe
  • Screens, Display, Displayable, View, CompositeView, Alphanumeric Display, LEDs, Audio Tones
  • 2D rendering, Image transformation, Tranparency, Flying Image, Fonts
  • Command, Button, Keyboard, Pointer, Keypad, State

A MicroUI device must have the following minimum characteristics:
  • Display: optional (several displays are permitted); size: any, type: graphic or alpha-numeric, depth: 1-bit or more, pixel aspect ratio: approximately 1:1, alpha numeric: at least one line with one character
  • Input: optional; Any user-input mechanisms: buttons, rotary switches, keyboards, multi touch screens, mouse-like-pointers, etc ...
  • Output: optional; Any sound mechanisms that provide the ability to play tones: buzzer, PWM, etc ..., Any kind of LEDs.
  • Memory: about 30 kilobytes of non-volatile memory if the whole MicroUI implementation is required by an application. For graphical screens, at least one display size of volatile memory for each graphical screen. For a 128x128 monochrome display, this is 2 kilobytes of ram; for a 320x240 16bit color display, this is 150 kilobytes.
1.4


(rev I)
n/a
009 HRTJ Hard Real Time Java

Deterministic Java for safety critical systems.

  • [HRTJ] is about hard real-time, not soft real-time. A hard real-time system (i.e. software & hardware), is a system that guaranties that expected behaviors will occur at the right time. The distinction between hard and soft real-time is between guaranteeing and best-effort.
  • Determinism. Although hard timing constraints may be specified using any usefulness functions or probabilistic constraints, the HRTJ specification uses deterministic hard real time constraints: hard real-time means determinism.
  • Certification. [HRTJ] is designed with one goal in mind: to make it possible to have Java software certified at the highest possible certification levels, like DO178 level A or IEC61508 SIL3 for example. Therefore [HRTJ] targets libraries that “due-to-their-sizes” can be certified at a reasonable cost.
  • [HRTJ] relies on deterministic GC. A Java system with no Garbage Collection (GC) is NOT ANYMORE a Java system, while the GC massively contributes to building reliable valuable software at low costs, by freeing the programmer from the complex and error prone explicit memory management.

0.7

Need to Log in
(rev D)
0.8
010 OSGi-ED OSGi-ED : OSGi for Embedded Devices

The OSGi ED profile proposal (RFP126) for a wide range of electronic devices, addressing cost and robustness concerns.

The “embedded world” has two characteristics that makes it appealing and challenging for software engineers: (1) resources may be scarce, (2) software cannot fail. OSGi-ED intends to address these two characteristics by making it easier to design software with these two constraints in mind. Embedded software is not just "software on electronic machines". Embedded applications usually involve optimizations that strive to create software for specific hardware. System integration is one of the most important aspects, heavily impacting testing and debugging. This is one big difference between a PC-based system and an embedded device. For PC-based systems, the development machine is the machine that will execute the application (or a machine really similar). For embedded systems, there are actually two systems: one used to design the application (usually a PC-like desktop) and one to run the application (the embedded device). If OSGi-R4 brings benefits in terms of software architecture for PC-like systems, OSGi-ED intents to bring the same benefits to the embedded world, perhaps even greater benefits given its focus on strong robustness. The OSGi-ED robustness philosophy may be summarized as: A faulty bundle cannot cause the failure of the entire platform.

The OSGi-ED profile specification introduces high robust semantic:

  • a thread-safe framework.
  • true bundle context from which private classes cannot escape.
  • no stale reference, introducing a notion of object ownership.
  • transactionnal bundles life cycle.
  • a controlled initialization sequence upon each reboot/restart.
  • DSDO, DSD1 and DSD2 that characterize how software is loaded into devices.

OSGi-ED is related to the RFP 126 of the OSGi Alliance:"RFP 126 : An OSGi Profile for Embedded Devices".

0.9.1


(rev A)
1.0
011 MWT Micro Widget Toolkit

MWT is a widget toolkit designed for wide range of devices, including embedded devices with limited processing power. Although this specification defines minimal requirements, devices with more resources may also benefit from MWT's special care in employing resources to their best advantage.
MWT defines a graphical environment that avoids portability problems so that an application running on a constrained device would run on other hardware devices such as cellphones-PDA or PC. The aim of this library is to be sufficient to create complex applications with a minimal framework.
MWT defines three distinct roles: Widget Designers, Look and Feel Designers and Application Designers.
  • Widget Designers : Widget Designers create new widgets by specifying widget contents and behavior. They defined listeners that the application rely on in opposition to internal events that are not exposed to application designers, create new animations, etc.
  • Look and Feel Designers : Look and Feel Designers create consistent sets of rendering systems in order to define the way the widgets are displayed on screens.
  • Application Designers: Application Designers create the HMI and the functional parts of the application. Their role is similar to the role for other toolkits: they use widgets defined by Widget Designers and should not consider widget look and feel.
The same binary HMI application works the same on all devices that provide a compliant MWT framework (embedded devices, cellphones, Android-based devices, setopbox-TV, PC, etc...) allowing for true ubiquity of applications accros product lines.

1.0


(rev D)
n/a
012 SNI Simple Native Interface

SNI is intended for implementing native Java methods in C language. It is declined in two specifications: full-featured SNI, and a lighter edition SNI-GT.

SNI allows to:

  • SNI allows to call a C function from a Java method using base types arguments and arrays of base types arguments.
  • SNI allows to call a Java method from a C function using base types arguments and arrays of base types arguments.
  • SNI allows to access a Java Immortal array in a C function.
  • SNI allows to create an Immortal array in a C function.
  • SNI allows to access a C struct in a Java method.

SNI-GT, Simple Native Interface for GreenThread Context, is a dedicated specification for greenthread vm architecture.

  • SNI-GT allows to call a C function from a Java method using base types arguments and arrays of base types arguments.
  • SNI-GT allows to access a Java Immortal array in a C function.
  • SNI-GT allows to manage in C the life cycle of the Java world (aka the vm) from the RTOS.

1.1

SNI (rev G)

----

SNI-GT (rev G)
n/a
014 SP Shielded Plug

SP provides segregation of the processes, which can be written either in C or in Java. It allows the certification of each individual part separately.
The data sharing between processes uses the concept of shared memory blocks, with introspection on those blocks. Facilities provided include: notification when the content changes, reinitialization of the block, testing the presence of data in the data block, and a mechanism for serialization and de-serialization.
SP allows the creation of several data stores. These can be defined entirely statically, or increase in number during the execution of a program.
Reading and writing in the shared memory are operations with predictable performance characteristics

1.0

SP (rev K)
n/a
015 eClassptah embedded CLASSPATH

eClasspath takes roots in GNU-CLASSPATH v0.98, but tuned for the embedded world. Compiling against eClasspath allows binary Java applications to be fully portable across all the existing different Java Runtime execution environment (J2ME-CLDC, J2ME-CDC, Foundation, J2SE J2EE, OSGi Minimum Environment, ...). eClasspath provides APIs for concepts such as File System, Sockets, Collections, Time Zone, ... . Eclasspath fills the gap between embedded devices and PC-like devices.
eClasspath is split in separated sub-profiles to limit the use of the whole library when only depending on sub-profiles (core, fs, net, collections, format, locale, math, nio, properties, sql, streams, timezone, timer, url, zip).

0.8

Need to Log in
(rev A)
1.0
Copyright©2009-2012 ESR Consortium Legal