Objektorientierte Programmierung, Teil 1 Grundlegendes zur Programmiersprache Realtime Java

Autor / Redakteur: Stefan Kuntschar* / Dipl.-Ing. (FH) Hendrik Härter

Viele Softwareprojekte der Embedded-Systeme werden in C geschrieben. Einzig C++ konnte sich teilweise gegen C durchsetzen. Im ersten Teil unserer Serie zur objektorientierten Programmiersprache Java stellen wir Ihnen die Grundlagen vor.

Firmen zum Thema

Gerade für mobile Anwendungen eignet sich Realtime Java besonders gut
Gerade für mobile Anwendungen eignet sich Realtime Java besonders gut
( Archiv: Vogel Business Media )

Das Thema „Realtime Java“ ist sehr umfangreich. Deshalb wird eine Untergliederung in mehrere Artikel vorgenommen. Der Erste gibt eine Einführung in das Thema Java und zeigt die ersten Schritte der Sprache in Richtung Embedded Systems auf. Der zweite Teil befasst sich mit der Erweiterung der Java Spezifikation „The Real Time Specification for Java“ (RTSJ) und den Vorteilen gegenüber den unterschiedlichen Standard Java Editionen. In einem weiteren Teil zeigen wir Ihnen kommerzielle und Open Source „Realtime Java Virtual Machines“ und deren Unterschiede.

Die Programmiersprache Java ist in vielen Bereichen bereits fest etabliert. Von riesigen Client-Server-Anwendungen und Datenbankapplikationen über Desktopprogramme bis in den Bereich der mobilen Geräte, wie Handys und PDAs, ist Java auf Grund seiner geschätzten Vorteile nicht mehr wegzudenken. Hierbei sind vor allem die Objektorientierung, Einfachheit der Sprache, Sicherheit (Speichermanagement), Portabilität und die einfache Implementierung von Multithreadingapplikationen erwähnenswert. Eine der wenigen Bastionen, in denen sich Java bisher noch nicht richtig durchsetzen konnte, ist der Bereich Embedded Systems. Dort werden Voraussetzungen benötigt, die Java mit dem Standard Konzept teilweise bewusst nicht erfüllen kann:

  • Zugriff auf physikalischen Speicher und Register
  • Zeitauflösungen im Nanosekundenbereich
  • Deterministische Ausführungszeiten
  • Präzises, vorhersagbares Scheduling
  • Harte Echtzeitfähigkeit
Die Programmiersprache Java und ihre verschiedenen Pakete (Archiv: Vogel Business Media)

Dabei wurde Java ab 1992 für ein Embedded System entwickelt. Es handelte sich hierbei um ein kabelloses PDA namens „*7“. Die Grundlage des Gerätes war ein auf einer SPARC-Architektur basierender Prozessor mit einem stark eingeschränkten Betriebssystem ohne Echtzeitfähigkeit. Der „*7“ wurde im Laufe seiner Entwicklung eingestellt, während Java weiterentwickelt und 1995 veröffentlicht wurde. Seitdem erlebt Java ein gigantisches Wachstum und eine fast beispiellose Erfolgsgeschichte. Inzwischen muss die Programmiersprache bereits in mehrere Pakete („Editions“) unterteilt werden, damit der Überblick gewahrt werden kann.

  • Die J2EE („Enterprise Edition“) bietet maximalen Umfang und wird vor allem im kommerziellen, industriellen Sektor bei großen Applikationen mit mehreren Servern und Datenbanken verwendet.
  • Die J2SE („Standard Edition“) beinhaltet alle Klassen und Pakete, die zur Programmierung von Standard Applikationen für Desktop PCs benötigt werden, einschließlich grafischer Bibliotheken.
  • J2ME („Micro Edition“) wurde für den Markt der kleinen, mobilen Geräte geschaffen.

Bis vor einiger Zeit bot allein die J2ME auf Grund ihres gegenüber der J2SE stark eingeschränkten Umfangs der Schnittstellen für die Applikation („Application Interface“, API) und des damit verbundenen kleinen Speicherverbrauchs („Memory Footprint“) die Möglichkeit, Software für Mikroprozessoren zu implementieren. Der Fokus dieser abgespeckten Version lag dabei auf mobilen, vernetzten Endgeräten wie Handys und PDAs. Andere wichtige und weit verbreitete Arbeitsbereiche wie zum Beispiel die Automatisierungs- und Steuertechnik blieben außen vor.

Java Version für Mikrokontroller

Da die J2ME die erste Java Version für Mikrokontroller ist, soll sie hier näher beleuchtet werden. Die J2ME definiert drei Softwareschichten. Die „Java Virtual Machine“ (JVM) ist die ausführende Schicht und interpretiert den Programmcode. Die VM ist einer der Vorteile der Programmiersprache Java. Sie sorgt für die Portabilität der Applikationen.

Nicht die Java Programme müssen auf unterschiedliche Plattformen angepasst werden, sondern eine VM muss für die Plattform nach Spezifikation entwickelt werden. Danach kann jedes in Java geschriebene Programm auf der VM laufen. Eine VM braucht immer ein darunterliegendes OS, dessen API für Threads und andere betriebssystemabhängige Implementierungen genutzt wird. Die VM der J2ME erweitert nicht die Standard VM, sondern schränkt deren API sogar weiter ein (kein Floating Point Support).

Spezifikation von zwei Konfigurationen

Die zweite Schicht ist die Konfiguration („Configuration“). Sie definiert den minimalen Umfang an Funktionalität der JVM und der Java Klassenbibliotheken, die für ein bestimmtes Gerät zur Verfügung stehen. Die dritte Schicht ist das Profil („Profile“). Es definiert den minimalen Umfang an APIs, die in der gewählten Konfiguration auf dem Gerät verwendet werden dürfen. Applikationen werden für ein bestimmtes Profil geschrieben. Eine Konfiguration kann mehrere Profile unterstützen.

Die J2ME spezifiziert zwei Konfigurationen. Die „Connected Limited Device Configuration” (CLDC) ist für Systeme mit mindestens 192 kByte Speicher und einem 16- oder 32-Bit-Prozessor ausgelegt. Diese Konfiguration wurde speziell für Mobiltelefone entwickelt und erfreut sich in dieser Sparte großer Beliebtheit („Java Handys“).

Sie ist die am meisten abgespeckte verfügbare Java Konfiguration. Um den niedrigen Speicherverbrauch zu erreichen, werden nicht nur die zur Verfügung stehenden APIs limitiert, sondern auch der Umfang der VM eingeschränkt. Als VM kommt die „K Virtual Machine (KVM)“ zum Einsatz. Die Einschränkungen beinhalten unter anderem den Verzicht auf asynchrones „Exception Handling“ und das „Java Native Interface“ (JNI) zur direkten Einbindung von C-Code.

Des Weiteren fehlt die Unterstützung des „Floating Point“ Formates sowie des Datentyps long, der optional implementiert sein kann. Alle Einschränkungen sind in der aktuellen Spezifikationsversion der CLDC aufgelistet. Des Weiteren enthält die implementierte API nur einen Auszug aus den Funktionen der J2SE. Auch der Compilierungsprozess wurde auf Systeme mit eingeschränkten Ressourcen angepasst.

Die CLDC unterstützt „JavaCodeCompact“. Dabei werden die Java Klassen in C-Dateien umgewandelt. Anschließend wird der C-Code kompiliert und direkt mit der KVM verlinkt. Am Ende des Prozesses erhält der Entwickler das fertige Binary. Dadurch entfällt das dynamische Linken und Übersetzen von Java Klassen, welches viele VMs zur Laufzeit nutzen. Die Applikation wird auf geringen Speicherverbrauch optimiert, da nur benötigte Klassen gelinkt werden, und die Ausführzeit beschleunigt, da das dynamische Linken entfällt.

Die drei Profile des CDCs

Für die CLDC ist ein Profil spezifiziert: Das „Mobile Information Device Profile“ (MIDP). Es bietet ein Benutzerinterface für LCDs, einen Media Player und eine Spiele API. Die zweite spezifizierte Konfiguration ist die „Connected Device Configuration“ (CDC). Sie benötigt mindestens 2 MByte Speicher und einen 32-Bit-Prozessor. Die CDC ist für Systeme mit Netzwerkkommunikation definiert worden. Diese Konfiguration enthält keine Einschränkungen der JVM. Die genutzte VM heißt CVM und benötigt ein Betriebssystem als Basis. Hierdurch kann Tasking und Scheduling angeboten werden. Da auch in dieser Konfiguration „JavaCodeCompact“ unterstützt wird, ist die sofortige Generierung eines Binaries möglich. CDC definiert drei Profile:

  • „Foundation Profile“: Dieses Profil bietet Java APIs für Systeme mit eingeschränkten Ressourcen ohne Unterstützung graphischer Benutzeroberflächen („Graphical User Interface“, GUI). Die grundlegenden Klassenbibliotheken der J2SE wie zum Beispiel java.lang und java.net sind enthalten und werden um ein Vernetzungs-Framework erweitert, das Interface javax.microedition.io.
  • „Personal Basis Profile“: Dieses Profil bietet Java APIs für Systeme mit eingeschränkten Ressourcen und grundlegende GUI Unterstützung. Hierfür werden Teile des Abstract Windows Toolkit (AWT) unterstützt.
  • „Personal Profile“: Dieses Profil unterstützt die komplette AWT Bibliothek sowie des Applet Interface.

Die J2ME mit all ihren Konfigurationen und Profilen wurde über den „Java Community Process“ (JCP) entwickelt. JCP ist weder ein offener Standard noch Teil des Open-Source-Konzeptes. Die Community besteht aus mehreren großen Firmen und wenigen Einzelpersonen. Sie entscheiden über zukünftige Erweiterungen und deren Umsetzungen. Dieser Umstand macht die Weiterentwicklung von Java wenig flexibel für neue Ideen und Bedürfnisse außerhalb der Community.

Die Nachteile der J2ME

Die J2ME hat bei genauerer Betrachtung auch mehrere Nachteile. Obwohl die Bezeichnung J2ME nahelegt, das Java Version 2 genutzt wird, sind die meisten Technologien der Edition nach dem JDK 1.1 entwickelt worden.

Des Weiteren ist der ROM Verbrauch sehr hoch. Die CLDC JAR Datei hat eine Größe von 450 KByte und benötigt noch zusätzlich ein Betriebssystem. Und selbst in dieser Edition für Mikrokontroller sind keine direkten Hardwarezugriffe erlaubt. Es wurde Zeit für eine Innovation, um Java für den Markt der Embedded Systems tauglich zu machen.

*Stefan Kuntschar ist als Softwareentwickler beim Spezialisten für Systems Engineering, Project Resources und Consulting Mixed Mode GmbH tätig. Er besitzt umfangreiche Erfahrung in der Konzeption und Implementierung von Systemen mit harten Echtzeitanforderungen.

Artikelfiles und Artikellinks

(ID:359706)