Eine Frage. Ich möchte gerne ein Programm für Kleincomputer herausbringen.
Dieses soll als JINI/Apache River Client fungieren.
Da auf dem Computer es zwar theoretisch möglich währe,
eine JVM zu installieren, aber praktisch, wegen Resourcenmangel unmöglich, habe
ich gedacht, ich könnte den Client in C/++ schreiben.
Gibt es hier eine API, oder soll ich das via Sockets machen?
Danke schon mal im Vorraus,
schildi48
Ps.: Mir schwbt noch eine dritte Möglichkeit vor. Diese ist, denke ich, wegen Lizenzprobleme
nicht durchführbar. Mann könnte die gesammte River Api durch einen Java zu C++ Konverter
ziehen!
Noch eine Option: GCJ
Die gnu complier collection bietet einen Complier, der auch für embedded Entwicklung verwendet werden kann und Java Programme in nativen Code überführen.
An sich ist die Frage, ob es wirklich “unbedingt” ein solches properitäres Protokoll sein muss. Mir ist zumindest kein API/keine Implementierung in C oder C++ bekannt, die jetzt die Apache River Erweiterung von RMI unterstützt.
Natürlich kann man das ganze Protokoll selbst implementieren, auf Basis von Sockets. Hat aber mehrere Nachteile:
[ol]
[li]Es dauert
[/li][li]Fehler sind wahrscheinlich
[/li][li]Es muss jmd. Protokolländerungen implementieren
[/li][/ol]
Auch ein Java nach C++ Compiler ist problematisch, da der Code nur bedingt korrekt übersetzt werden würde. Erfahrungsgemäß gibt es da viiiel mehr Schwierigkeiten als man glaubt. Und sobald Apache River auf Bibliotheken aufsetzt, die nicht im Quelltext vorliegen kannst Du auch an eine Grenze stoßen, die nicht so leicht überwunden wird.
Aus meiner Sicht ist der bessere Ansatz wirklich ein Protokoll zu verwenden, dass beide Welten Unterstützen. Da gibt es ein paar Kandidaten, vom REST Ansatz unter HTTP-Verwendung, über XML Nachrichten á la SOAP bis hin zu Corba oder anderen “binären” Ansätzen.
Ehrlich gesagt sind die simplen (textbasierten) einfacher zu verwenden und Du hast viel leichtere Möglichkeiten zu testen, zu erweitern und so weiter. Dem steht immer die Performance gegenüber, aber selbst billige Mobiltelefone, Himbeer-Konstanten oder sonstige Umgebungen werden Dich kaum eine nennenswerte Verzögerung spüren lassen. Okay, ganz so pauschal ist es falsch, für viele Anwendungsfälle dürfte es aber sehr locker reichen. Dass man auch einen ganzen Haufen von einfachen Textnachrichten schnell verarbeiten kann zeigt jeder Webserver. Die Arbeiten alle “RESTful” unter Verwendung von HTTP und beantworten sogar mehrere tausend Anfragen pro Sekunde ohne einen modernen Rechner ins Schwitzen zu bringen.
Klarer Vorteil, Du wirst hier wirklich jede Plattform (nahezu) einbinden können, ob es ein IPhone/Pad, ein Android-Device oder ein Embedded System ist, so ziemlich für jede Umgebung/Plattform wird sich schon eine Bibliothek finden, die das unterstützt.
Besten Gruß
Danke.
Ich werde alle Möglichkeiten durchgehen.
Der Client (wird) sehr klein sein, und so fällt das Probieren
nicht so ins gewicht.
Es wird, denke ich aber bei gcj bleiben.
Die Möglichkeit eines eigenen Protokolles fällt
wahrscheinlich raus, da sehr viele (kleine) Objekte
ausgetauscht werden.
Danke nochmal,
schildi48
pS… Eine Alternative hätte ich auch noch gefunden: junc++ion. Das ist aber (denke ich) sehr kommerziel.