MixedMode RealtimeJava VirtualMachine
Werbung
Realtime Java und die Wahl der Virtual Machine: Fachartikel 1 von 3 http://www.elektronikpraxis.vogel.de/index.cfm?pid=5416&pk=3403... Echtzeitentwicklung mit Java, Teil 3 Realtime Java und die Wahl der Virtual Machine 24.11.2011 | Autor: Stefan Kuntschar * Die Wahl einer geeigneten Virtual Machine für Realtime Java ist nicht einfach. Doch welche Punkte müssen bei der Wahl der richtigen Virtual Machine beachtet werden? Realtime Java oder kurz RTJ ist mit all seinen Vorteilen gerade für Entwickler von Software für EmbeddedSysteme als Alternative zu C/C++ interessant geworden. Ein wichtiger Aspekt bei der Arbeit mit Realtime Java ist die Wahl der „Virtual Machine“. Egal ob kommerziell oder Open Source, kompakt oder umfangreich, der Markt bietet bereits eine große Auswahl. Die Wahl der Virtual Machine: In welche Richtung soll es gehen? Neben Architektur und Betriebssystem stehen kommerzielle oder Open-Source-Anwendungen zur Wahl. (Foto: Egon Häbich, pixelio.de) Ein Grundsatz von Java ist die Portabilität der entwickelten Software. Der Entwickler einer Applikation soll sich keine Gedanken um Hardware und Betriebssysteme machen müssen, sein Programm soll auf jedem System laufen. Applikationen für Windows, Linux und MacOS Damit das gelingt, wurde die „Java Virtual Machine“ (VM) definiert. Sie abstrahiert die Hardware und stellt das Interface einer oder mehrerer Java Edition(en) zur Verfügung. So gibt es zum Beispiel die Standard VM von Sun, die das Interface der „Java Standard Edition“ (J2SE) für die x86-Architektur implementiert hat, für unterschiedliche Betriebssysteme. Das sind im einzelnen Windows, Linux und MacOS. Demnach kann ein Software-Entwickler seine Applikation auf jedem dieser Betriebssysteme entwickeln und sie wird ohne Mehraufwand auf allen anderen genannten Systemen laufen. Der gerade genannte Vorteil soll für Embedded-Systeme genutzt werden. Dieser Gesichtspunkt ist allerdings nicht so leicht umzusetzen wie im Desktopbereich. Der Markt der Mikrocontroller bietet massenweise unterschiedliche Architekturen und (Echtzeit-)Betriebssysteme. Anzeige Die Kombination aus beiden bietet eine Artenvielfalt, die so manchen Biologen 30.11.2011 14:14 Realtime Java und die Wahl der Virtual Machine: Fachartikel 2 von 3 http://www.elektronikpraxis.vogel.de/index.cfm?pid=5416&pk=3403... erblassen lässt. Demnach ist es für den Hersteller einer „Realtime Java VM“ unmöglich, den kompletten Markt abzudecken. Und damit ist die erste Frage, die gestellt werden muss: Auf die Architektur und das Betriebssystem kommt es an Bei der Wahl des Betriebssystems ist zu beachten, dass Realtime Java ein hart echtzeitfähiges Betriebssystem (RTOS) benötigt. Manche VMs setzen auch auf einen eigenen RTOS-Kernel und brauchen demnach kein darunterliegendes Betriebssystem. Nach Festlegung dieser Entscheidung muss die anvisierte „Realtime Java VM“ auf die Unterstützung der gewählten Architektur und der BetriebssystemKombination geprüft werden. Wenn die gewünschte Kombination nicht unterstützt wird, kann eine Anfrage auf Portierung der „Realtime Java VM“ beim jeweiligen Hersteller auch noch zum Erfolg führen. Dies ist allerdings abhängig vom jeweiligen Hersteller, von der Projektgröße, der Zukunftstauglichkeit der Kombination und/oder der Zahlungswilligkeit. Kommerzielle oder eine Open Source Virtual Machine? Ein weiterer wichtiger Gesichtspunkt ist die Frage, ob eine kommerzielle oder eine Open Source "Realtime Java VM" genutzt werden soll. Beide Varianten haben ihre Vor- und Nachteile. Eine Open Source „Realtime Java VM“ ist kostenlos und hat auf Grund des Open-Source-Gedankens wenige Bugs, die nach Bekanntgabe meist schnell ausgebessert werden. Nachteilig wirkt sich dabei aus, dass eine Portierung auf eine noch nicht unterstützte Architektur/RTOSKombination nicht einfach in Auftrag gegeben werden kann. Hier sind die Freundlichkeit der Entwickler des Projektteams sowie das Interesse an dieser Portierung von Bedeutung. Ein zweiter Nachteil ist der Support. Bei einem Open-Source-Projekt ist kein Support über Jahre gewährleistet. Projekte können zum Beispiel aus Zeit- oder Geldmangel des Entwicklerteams ohne Vorankündigung eingestellt werden. Eine kommerzielle „Realtime Java VM“ kostet Geld, bietet aber häufig eine flotte Portierung und jahrelangen Support. Auf der nächsten Seite lesen Sie: Vergleich von kommerziellen und quelloffenen Virtual Machines Vergleich von kommerziellen und quelloffenen Virtual Machines Bevor wir auf weitere Unterschiede der VMs eingehen, sollen beispielhaft einige bekanntere VMs sowohl aus dem kommerziellen als auch aus dem Open-SourceBereich genannt werden. Im Open-Source-Bereich gibt es beispielsweise ovm und Jrate. Das ovm-Projekt startete als eines der ersten VM-Projekte auf Basis eines Open-Source-Systems mit dem großen Ziel, eine Open Source Realtime Java VM zu entwickeln. Damit das Ziel umgesetzt werden konnte, kooperieren mehrere Universitäten und Firmen. Momentan ist es um dieses Projekt sehr ruhig geworden. Wie oben erwähnt, ist seit dem letzten Update einige Zeit vergangen. Drei kommerzielle VMs – weiche und harte Echtzeitanwendungen Das jrate-Projekt hingegen besitzt eine aktive Community, die Updates und neue Portierungen entwickelt. Es wurde auf der Entwicklerplattform Source Forge ins Leben gerufen. Der kommerzielle Bereich bietet alteingesessene Hersteller sowie Newcomer: Aicas JamaicaVM, Aonix PERC, Is2t MicroEJ und IBM Genuine. Die zurzeit am häufigsten eingesetzten VMs sind die JamaicaVM, PERC und Genuine. Dabei wird die IBM Genuine VM vor allem für Projekte mit weichen Echtzeitanforderungen verwendet, während die JamaicaVM und die PERC bei harten Echtzeitanforderungen zum Einsatz kommen. JamaicaVM und PERC unterscheiden sich in mehreren Punkten. Die JamaicaVM ist eine der ältesten Realtime Java VMs am Markt. Sie ist inzwischen sehr weit fortgeschritten und bietet eine breite Fülle an Architektur/RTOS-Kombinationen. Seit Version 6 kommt sie ohne Betriebssystem aus, da sie über einen Realtime Kernel verfügt. Des Weiteren hält sie die RTSJ in allen Punkten ein und unterstützt den Standard „Java Development Kits“ und „Connected Limited Device Configuration“. Vor- und Nachteile von PERC und JamaicaVM Bei so viel Fülle dürfen gute Konfigurationsmöglichkeiten nicht fehlen, um auf den kleinsten Systemen den Speicherplatz optimal zu nutzen. Erwähnenswert sind die Entwicklungstools. Die JamaicaVM bietet Entwicklungshilfen, wie einen 30.11.2011 14:14 Realtime Java und die Wahl der Virtual Machine: Fachartikel 3 von 3 http://www.elektronikpraxis.vogel.de/index.cfm?pid=5416&pk=3403... Analyzer und Profiler. Dieser schätzt den Speicher ab und optimiert diverse Debug-Hilfen wie den Thread Monitor zur Evaluierung des Zeitverhaltens der Applikation. Ein zusätzliches Gimmick wird allen Eclipse-Entwicklern angeboten. Hierbei handelt es sich um ein Plugin für die bekannte IDE, das die Konfiguration und Verwaltung der JamaicaVM erleichtert. Die PERC ist in vielen Punkten der Gegensatz. Sie ist ebenfalls bereits in vielen Architektur/RTOS-Kombinationen verfügbar. Außerdem existieren mehrere unterschiedliche Ausstattungspakete, wie die PicoPERC und die NanoPERC. Sie hält sich nicht gänzlich an die RTSJ und liefert viele Klassen mit eigener Interpretation. Dafür ist die PERC sehr schmal und gut durch C++ erweiterbar. Im Gegensatz zur JamaicaVM kann die PERC durch Annotationen im Source Code den Speicherverbrauch der Applikation noch in der Implementierungsphase sehr gut abschätzen. Eines haben alle Realtime Java VM Hersteller gemeinsam. Sie erzeugen am Ende des Build-Vorganges ein Binary, welches auf das Target geladen wird und sowohl die VM als auch die Applikation und dazugelinkten C/C++-Code enthält. Durch die für Java untypische statische Verlinkung wird die Codegröße optimiert und das Zeitverhalten der Applikation vorhersagbar. Dies wäre beim sonst eingesetzten dynamischen Linken nicht ohne Weiteres möglich. * Stefan Kuntschar ist Softwareentwickler bei Mixed Mode in München. Redakteur: Hendrik Härter Copyright © 2011 - Vogel Business Media 30.11.2011 14:14
