APHELION JREs (JavaTM Runtime Environments)

Each Aphelion JRE is a software middleware that facilitates reliable and high performance runtime execution of bytecode JAR files of Java applications created with Aphelion Java Development Environment (JDE) on the RTOS/processor platform targeted by this JRE. In addition, each JRE is fully capable of executing Java applications created with any other JDE (for example the Embedded Eclipse JDE), as long as each such application only uses the Java class libraries and API packages included in the JRE.

Ahelion JREs are comprised of Apogee-created RTOS/processor ports of Java technologies licensed from IBM. In addition, each JRE can include the ports of Java technologies obtained from providers of open-source Java software (Apache.org, for example), or Java technologies developed by Apogee. The technologies licensed from IBM include the relevant components (the J9 Java Virtual Machine, for example) from WebSphere Everyplace Micro Environments (WEMEs). In addition, Apogee may include, if needed for running customer's Java applications, suitable components from IBM's WebSphere Everyplace Custom Environments (WECEs).

Aphelion JREs are available in four configurations: Mobile device JREs (MJREs), Foundation JREs (FJREs), Extended JREs (EJREs), and Custom JREs (CJREs).

MJREs are suitable for running Java applications that use Java API packages defined for the J2ME CLDC platform by Mobile Information Device Profile v2 (MIDP2) and by various J2ME CLDC targeted Java Specification Request (JSRs).

FJREs are suitable for running Java applications that use Java API packages defined for the J2ME CDC platform by Foundation Profile.

EJREs are suitable for running Java applications that use Java API packages defined by CDC Foundation Profile, and one or more Java API packages defined by J2ME CDC targeted JSRs. In addition, each EJRE may include the ports of client-side "runtimes" for various server-client services, and/or the ports of various application-level packages, as long as each such runtime or application-level package only uses the Java API packages the ports of which are included in the EJRE.

CJREs are suitable for running Java applications that use one or more Java API package from the J2SE platform. In addition, each CJRE may include the ports of client-side runtimes and/or application-level packages, as long as each such runtime or application-level package only uses the Java API packages the ports of which are included in the CJRE.

Components of MJREs

Each MJRE is comprised of RTOS/processor ports of the following components:

  • IBM's J9 Java Virtual Machine (J9VM) compatible with the J2ME CLDC VM defined by JSR-139.

  • IBM's micro JIT (Just-In-Time) compiler integrated with the port of J9VM.

  • IBM's Mobile Device Class Library (MDCL) compatible with the J2ME CLDC MIDP2 defined by JSR-118.
In addition, a given MJRE can include customer requested RTOS/processor ports of optional Java API packages defined for the J2ME CLDC Platform by various JSRs, such as: the Bluetooth API defined by JSR-82; Mobile Media API defined by JSR-135; Security and Trust Services API defined by JSR-177; Mobile Location API defined by JSR-179; Wireless Messaging API defined by JSR-205; Mobile Internalization API defined by JSR-238; etc..

Every MJRE is compatible with Sun's CLDC J2ME platform, which means that it can pass all tests in Sun's J2ME TCK test suites for the CLDC VM, MIDP2, and relevant JSR-defined packages. For example, an MJRE that includes a port of IBM's implementation of Mobile Media API can pass all tests in Sun's J2ME TCK test suites for the CLDC VM, MIDP2, and JSR-135 Mobile Media API.

Components of FJREs

Each FJRE is comprised of RTOS/processor ports of the following components:

  • IBM's J9VM compatible with the J2ME CDC VM defined by JSR-218. If the FJRE is compliant with the Real-Time Specification for Java (RTSJ), the port of J9VM also includes the implementations of RTSJ features that must be directly implemented in a Java VM.

  • IBM's RTOS/processor-targeted JIT (Just-in-Time) compiler integrated with the port of J9VM. Or, in case of the RTSJ-compliant FJRE, Apogee's RTOS/processor-targeted JAOT (Just-Ahead-of-Time) compiler derived from the corresponding IBM's JIT compiler and integrated with the port of J9VM. (Note that JIT compilers cannot be used with RTSJ-compliant JREs because of their non-deterministic behavior.)

  • IBM's Foundation Class Library (FCL), which includes the Java API packages compatible with API packages from the CDC J2ME Foundation Profile (java.io, java.lang, java.math, java.net, java.security, java.text, java.util, and javax.microedition) defined by JSR-219.

  • Apogee's RTSJ Class Library (RTSJCL) if the FJRE is compliant with RTSJ. The library provides the implementations of RTSJ features that need not be implemented in a Java VM.
Each FJRE can also include the ports of IBM's implementations of optional API packages Java Secure Socket Extension (JSSE), Java Cryptography Extension (JCE), and Java Authentication and Authorization Service (JAAS) packages defined for the J2ME CDC Foundation Profile by JSR-219.

Every FJRE is compatible with Sun's CDC J2ME platform, which means that it can pass all tests in Sun's J2ME TCK test suites for the CDC VM and Foundation Profile.

Components of EJREs

Each EJRE is comprised of RTOS/processor ports of: (i) IBM's J9VM compatible with Sun's J2ME CDC VM and equipped with the RTOS/processor-targeted JIT or JAOT (if the EJRE is RTSJ-compliant) compiler; (ii) IBM's FCL compatible with Sun's J2ME CDC Foundation Profile (FP) v1.1; (iii) Apogee's RTSJCL if the EJRE is RTSJ-compliant; and (iv) any of the following components requested by a given customer:

  • IBM's implementations of JSSE, JCE, and JAAS packages. The port of each package is integrated with the port of FCL.

  • IBM's Personal Basis Class Library (PBCL) compatible with Sun's CDC Personal Basis Profile (PBP) v1.1 defined by JSR-217. The port of PBCL comes with a port of IBM's UGL (Universal Graphics Library) or Apogee-customized eSWT (enbedded Software Widget Toolkit) from the Eclipse Open Platform, each of which provides a transition layer between the graphical APIs of java.awt package of PBCL and the graphical functions of a low-level graphics library (LLGL) that comes with a given RTOS. The port of UGL is included in a given JRE if LLGL is GTK2 that comes with most "embedded" Linuxes, or GDI that comes with Windows CE or Windows Mobile, or Trolltech's Qtopia Core graphics library. The port of eSWT is included, for example, if LLGL is WindML that comes with Wind River's VxWorks, or OpenGL that comes, for example, with Green Hills' Integrity.

  • IBM's Personal Class Library (PCL) compatible with Sun's CDC Personal Profile (PP) v1.1 defined by JSR-216. If the Java applications targeted at a given EJRE use the Java AWT graphics of PCL, then the port of PCL comes with a port of IBM's UGL or Apogee-customized eSWT, each of which provides a transition layer between the graphical APIs of java.awt package of PCL and the graphical functions of LLGL that comes with a given RTOS. The port of UGL is included in a given JRE if LLGL is GTK2 that comes with most "embedded" Linuxes, or GDI that comes with Windows CE or Windows Mobile, or Trolltech's Qtopia Core graphics library. The port of eSWT is included, for example, if LLGL is WindML that comes with Wind River's VxWorks, or OpenGL that comes, for example, with Green Hills' Integrity. In case a port of PCL for a given JRE can have a port of either UGL or eSWT, the choice between the two is made according to the performance vs footprint and the level of graphics used by Java applications that will be running on the EJRE.

  • IBM's implementation of RMI (Remote Method Invocation) package defined by JSR-66. The package includes a subset of J2SE RMI APIs.

  • Apogee's implementation of the Bluetooth API defined for the J2ME CLDC platform by JSR-82, adapted by Apogee for use with EJREs compatible with the J2ME CDC platform and augmented by a special "native interface" that allows easier implementation of Bluetooth API "on top" of a low-level Bluetooth stack that comes with a given device.

  • IBM's implementation of the JDBC (Java Data-Base Connectivity) package defined by JSR-169. The package includes a subset of J2SE java.sql APIs. A given port of JDBC can be provided with a port of IBM's Java Data-Base Enabler, which facilitates the use of JDBC APIs for a wider range of databases (for example, the Oracle databases and IBM's DB2).

  • IBM's implementation of the XML Support & Web Services package defined by JSR-172. The package includes the XML parser, XML-handling APIs, and APIs for various Web services.

  • IBM's implementation of the PKI, CRYPTO, and APDU packages from the Security and Trust Services API (SATSA) defined for the J2ME CLDC platform by JSR-177, adapted by Apogee for use with EJREs compatible with the J2ME CDC platform.

  • Apogee's CDC-compatible implementation of JCRMI package defined for the CLDC platform by JSR-177 SATSA. This implementation is based on IBM's CDC-compatible RMI package defined by JSR-66, adapted and extended by Apogee to provide the functionality defined by SATSA's JCRMI. Specifically, we added to IBM's RMI package a socket factory running over SSL protocol, and a framework named "rmi-ssl" that allows creation of both secure ssl server sockets and client sockets through a "tunneling mechanism"..

  • IBM's implementation of the Mobile Location API defined for the J2ME CLDC platform by JSR-179, adapted by Apogee for use with EJREs compatible with the J2ME CDC platform.

  • IBM's implementation of Mobile Internalization API defined for the J2ME CLDC platform by JSR-238, adapted by Apogee for use with EJREs compatible with the J2ME CDC platform.

  • IBM's JXComm class library providing the APIs supporting various protocols (for example IPv6) for serial and parallel communications.

  • IBM's implementation of JINI package providing the APIs that facilitate sharing of various devices (printers, disk drives, etc.) by networked devices having the EJRE running on them.

  • Client-side runtime packages ("runtimes") facilitating the services needed by customer's Java applications or because of the way a device having the JRE running on it is used, as long as each such runtime only uses the Java APIs from J2ME compatible class libraries and packages. For example:

    • The eRCP (embedded Rich Client Platform) from the Eclipse open platform, which includes the Equinox OSGi R4 Framework, Configuration Admin Service, and the Extension Point Framework runtimes. Or, Apogee can include in a given JRE the ports of only those components of eRCP (for example, the OSGi R4 framework) that are needed by customer's Java applications. Note that the Equinox OSGi R4 Framework facilitates various OSGi functions on the client device it is running on, such as dynamic loading, installing, running, and un-installing of Java applications obtained from OSGi servers in form of OSGi R4 bundles.
    • The Remote Data Capture and Delivery runtime from IBM's RFID Data Capture and Delivery v6.0 product offering, which facilitates various RFID functions on a device it is running on (RFID reader or "edge" server, for example). This runtime is optionally available with Apogee's LLRP (Low Level Reader Protocol defined by ECPglobal in early 2007) adaptor, customized for use with a given RFID device (an RFID reader, for example) having the EJRE running on it.
    • The CORBA runtime, such as the OpenFusion from PrismTech Corporation or the ORBexpress from Objective Interface Systems.
    • The IPv6 (Internet Protocol Version 6) runtime based on the implementation of IPv6 that comes with IBM'sWebSphere MQ v6.0.
    • Runtimes for various services provided by IBM's Micro Environment Toolkit for WebSphere Studio (METWS), such as: Servlets, SyncML DS&DM protocols, and the runtime for accessing IBM's DB2 Everyplace and Cloudscape databases.
    • JSP (Java Server Pages) runtime from Sun's open-source Glassfish webtier.

  • Application-level packages providing various services needed by customer's Java applications or because of the way a device having the JRE running on it is used, as long as each such package only uses the Java APIs from J2ME compatible class libraries and packages. For example:

    • The Java Message Server from IBM's METWS.
    • The Xerces XML validating parser from Apache.org.
    • The Log4J package from Apache.org.
    • The DOM.Xpath package from W3.org.

Every EJRE is compatible with Sun's CDC J2ME platform, which means that it can pass all tests in Sun's J2ME TCK test suites for the CDC VM, Foundation Profile, and other relevant CDC profiles and JSR-defined packages. For example, an EJRE that includes the ports of PCL and IBM's implementation of RMI package can pass all tests in Sun's J2ME TCK test suites for the CDC VM, Foundation Profile, Personal Profile, and JSR-69 RMI package.

Components of CJREs

Each CJRE is comprised of RTOS/processor ports of: (i) IBM's J9VM compatible with Sun's J2ME CDC VM and equipped with the RTOS/processor-targeted JIT or JAOT (if the CJRE is RTSJ-compliant) compiler; (ii) IBM's FCL compatible with Sun's J2ME CDC Foundation Profile (FP) v1.1; (iii) Apogee's RTSJCL if the CJRE is RTSJ-compliant; and (iv) either the entire GNU Classpath library (all of its J2SE-compatible API packages), or an appropriate subset of Classpath if the Java applications, client-side runtime, or application-lebel packages that will be running on CJRE do not need all the J2SE-compatible Classpath packages.

In addition, each CJRE can include:

  • Any of the J2ME-compatible client-side runtimes listed above (the Equinox R4 Framework, for example), as well as other client-side runtimes that use J2SE APIs (for example, the runtimes for accessing some server-resident databases that need the java.beans and javax.sql J2SE APIs), in which case all such APIs are provided by the port of appropriate subset of Classpath.

  • Any of the the J2ME-compatible application-level packages listed above (the Log4j package, for example), as well as other application-level packages that use J2SE APIs, such as, for example, the Tomcat servlet container from Apache.org, or the JavaMAIL package from Sun's open-source Java software website, in which case all such J2SE APIs are provided by the port of appropriate subset of Classpath.
The GNU classpath presently includes the following API packages, a very large majority of which is compatible with the J2SE 1.5 platform:
  • java.applet, java.awt, java.beans, java.io, java.lang, java.math, java.net, java.nio, java.rmi, java.security, java.sql, java.text, and java.util.

  • javax.accessibility, javax.crypto, javax.imageio, javax.management, javax.naming, javax.net, javax.print, javax.rmi, javax.security, javax.sound, javax.sql, javax.swing, javax.transaction, and javax.xml.

  • org.ietf.jgss, org.omg, org.w3c.dom.
Every CJRE is compatible with the J2SE platform or a subset of J2SE platform to the same extend to which the port of Classpath or a subset of Classpath included in the JRE is compatible with the J2SE platform or the corresponding subset of J2SE platform. This is assured by making each CJRE pass all tests in Mauve test suite or its relevant subset. Note that Mauve is a very extensive test suite (with over 50,000 tests and sub-tests) used for testing the compatibility of Classpath with the J2SE platform.

Configurable CJREs

There are cases when Apogee's customers do not know which Classpath APIs should have their ports included in requested CJREs, and it is not possible to include in these CJREs the ports of entire Classpath because of the large runtime footprints of such ports. For example, a given CJRE will be installed on several devices targeted by Java applications that differ from one device to the other with respect to the Classpath APIs used by them. Or, a given CJRE will be installed on a device targeted by Java applications of various end-user of the device, and such applications differ from the end-user to end-user with respect to the Classpath APIs used by them.

Therefore, Apogee can provide to such customers "generic" CJREs, each of which includes a port of the entire Classpath or such a subset of Classpath that has the API packages possibly needed by various Java applications that will be running on the CJRE. Each generic CJRE comes with a special tool used to create the "instantiations" of CJRE for various devices or for various end-users of a given device. Thus, there will be one CJRE instantiation for each device, which will only include the ports of Classpath APIs actually needed by Java applications targeted at this device. Similarly, there will be one CJRE instantiation for each end-user of a given device, which will only include the ports of Classpath APIs actually needed by Java applications of this end-user.

Creation of JREs for Apogee's Customers

To assure the highest possible quality of JREs, Apogee creates a JRE for each customer-requested RTOS/processor platform by starting with a most suitable existing JRE and re-porting the relevant components of this JRE to the RTOS/processor platform, thus creating a base-line JRE. Then, we create the RTOS/processor ports of all additional Java API packages needed by customer's Java applications, customer-requested client-side runtimes, and customer-requested application-level packages, and make the ports work with the beseline-line JRE. If possible, all such additional packages are obtained from Apogee's repository of J2ME-compatible API packages. Otherwise, all such additional packages are obtained from the Classpath. Then, we add to the resulting interim JRE the RTOS/processorn ports of customer-requested client-side runtimes and/or application-level packages, and make the ports work with the interim JRE. Finally, we complete the JRE by: (i) making it pass all tests in relevant test suites (TCK tests suites, Mauve, or the appropriate subsetof Mauve); (ii) making it correctly execute customer's Java applications provided by the completion date of interim JRE: and (iii) tuning it for the highest possible runtime performance and the smallest possible runtime footprint when running such Java applications.

In spite of the above labor-intensive process, Apogee typically charges very reasonable porting fees for creating JREs because we can often leverage the work done when creating similar JREs for other customers. This is especially so when the customer-requested RTOS and/or processor architecture are among those targeted by existing JREs. Please, click here for the lists of such RTOSs and processor architectures.

Typically, Apogee provides each JRE with a corresponding (targeted at the same RTOS/processor platform) JDE. However, Apogee can also provide each JRE in a "stand alone" form, which can be installed on a RedHatLinux/x86 or Windows/x86 host platform and then downloaded on to the target device using Apogee-provided instructions and simple UNIX-like line commands.

Please, contact Apogee by email or phone for more information on features and capabilities of Aphelion JREs.

Home | Corporate Info | Products | Download | Order | News | Resellers






Google
www.apogee.com Web