Startseite > Messen + Testen > Oszilloskope > Java am Edge: Interpretieren statt Debuggen

D&E Black Book / Safety&Security

Java am Edge: Interpretieren statt Debuggen

1. Juli 2019, 10:33 Uhr | Dr. Constantin Tomaras, Ressortredakteur für Systemdesign, DESIGN&ELEKTRONIK

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Java versus C

Ob objekt-orientierte Programmierung für ressourcen-beschränkte Anwendungen einen Sprachvorteil bedeutet ist sicherlich fragwürdig: ihre starken Anwendungsfälle liegen im Bereich des Desktop-Computings, während C semantisch nah zur Sprache der Mathematik liegt. Zunächst wird der C-nahe Embedded-Anwender von Variablen und Funktionen (und den Zeigern darauf) auf Klassen, Attribute und Methoden übergehen.

Der modulare Programmaufbau muss mit Timing-Konstrukten den gewünschten sequenziellen Ablaufplan in der JavaVM realisieren. Eine Klasse wird dabei als Thread begriffen, die zugehörige implizite run()-Methode leistet die Ablaufplanung [1]. Anstelle eines Interrupts treten in der JavaVM zeitgeplante Exceptions.

Wer »Brute-Force« unter vorgegebener Modulstruktur auf vorhandene Java-Klassen zugreift, hat mit Javas lua-Semantik ein ähnliches Programmiererlebnis wie ein Python-Anwender. Den wesentlichen Unterschied zur C-Programmierung stellt Javas Trail- and Error-Konzept: Code-Abschnitte können in einem try{}-Block gesetzt werden - löst dieser eine Laufzeitverletzung aus, erklärt der zugehörige catch{}-Block die System-Antwort darauf. Sofern der catch{}-Block auf einem separaten Watchdog-Prozessor stattfindet, ist das äquivalent zum Debugging-Probe-Ansatz.

Eine Klasse wird mit ihren Variablen, Methoden wie Funktionen oder Ausführungsverhalten arche-typisch definiert, und daraus auf oberster Ebene ein Arbeitsexemplar abgeleitet.