Warum soll man sich abmühen und in C oder C++ programmieren? Entwurf in Java, Test der Algorithmen in Java, dann Implementierung in C, Ablauf im Zielsystem sehr maschinennah in C->Maschinencode.

Es geht nicht darum, typische Java-Programme auf C zu portieren, das wäre Unsinn, sondern: Typische C-Programme in Java zu designen und zu testen.

Ich habe einen Java-to-C++-Übersetzer realisiert, weitere Überlegungen haben mich zu dem Schluss geführt, dass die C++-Schiene unsinnig ist. C ist so nahe am Maschinencode, wie das der Entwickler von Steuerungen benötigt. Die typischen Programme in dieser Ecke lassen sich auch auf Java abbilden, Java lässt sich für diese Fälle nach C übersetzen.

Auf meiner Homepage http://www.vishia.de/Java/Java2c/Java2c.html habe ich einiges Zusammengeschrieben, und einige Sources eingestellt. Wer hat an diesem Thema Interesse?

Thema WiederverwendbareSoftware

--HartmutSchorrig

Diskussion

Warum das Rad neu erfinden? Der GCJ kann auch in nativen Maschinencode kompilieren. Wäre es nicht besser, da mit zu helfen? - Gut, der Code wird mit einer großen Bibliothek verlinkt und ist somit vielleicht weniger für den embedded Bereich geeignet, aber das Geschwindigkeit-Problem ist gelöst -- akf

Ich hab jetzt nochmal rumgeschaut, und tatsächlich ein noch ähnlicheres Projekt gefunden: JC. Der kompiliert Bytecode zu C Code. -- akf

Und noch welche Toba und Harissa - Warum wird das Rad immer wieder neu erfunden. :-( -- akf

Danke für die Tips, zuerst mal zur Frage: Warum das Rad neu erfinden: Es gibt mehrere Fahrradhersteller, und mit einem Rennrad fährt es sich nicht gut auf Schotterwegen. Also: Es gibt verschiedene Aspekte für Lösungen, und daher verschiedene Lösungen. Das interessante dabei wäre, wenn sie einander etwas kompatibel wären, damit man Leistungen des einen (Rads) beim anderen auch nutzen kann, dass es irgendwo zusammenpasst. Daher ist eine offene Diskussion unterm Wiki-Schirm auch interessant.

Nun konkret:

• GCJ lohnt sich anzuschauen. Mit Blick auf embedded systeme braucht man aber einen Compiler für den spezifischen Zielprozessor, ggf. angepasst an ein Zielsystem. Auch wegen der Debugbarkeit und Kontrolle was da im Maschinencode vor sich geht (bei embedded systemen oft wichtig, für PC-Applikationen in der Regel völlig uninteressant) ist eine Mehrstufigkeit Java -> C -> Assembler/Maschinencode wichtig. D.h. eine unabhängige Übersetzung Java nach C. Ich werde aber diese GC-Geschichte verfolgen.
• JC verspricht genau das was ich haben will. Ich werde dort auf jeden Fall genauer hinschauen. Es kommt möglicherweise auf das Detail an.
• Toba scheint auch ein solcher Versuch gewesen zu sein, wie ich ihn vorhabe, wird aber nicht mehr gepflegt. Aber Harissa lohnt sich wiederum genauer anzuschauen.
• Als Zielgruppe sehe ich diejenigen, die sich in C abquälen müssen (oder wollen), dabei sogar UML-Tools benutzten, und durch mühevolle Tricks sogar bei C sowas wie Interfaces und Vererbung aus dem UML-Tool nach dem C-Code entlocken. Oder diejenigen, die von der Objektorientierung noch nicht intensiv berührt worden sind. Persönliche Erfahrung: Ich habe erst im Herbst 2003 Java kennengelernt, zuvor ist es an mir einfach vorbeigegangen (es gibt genügend tägliche Kleinaufgaben der Programmierung, die einen beschäftigen). Java war damals Beispielsprache für einen UML-Kurs. Da ich die Konzepte der Objektorientierung und C++ prinzipiell recht gut kenne, habe ich sofort erkannt, dass Java eine sehr gute Sprache ist und welche Potentiale für meine eigenen Programmieraufgaben darin stecken. Es könnte anderen auch ähnlich gehen können.
• C ist deshalb als Zwischenebene notwendig, weil in C sehr gut abschätzbar ist, was im Maschinencode so abgehen könnte. C ist nahe am Maschinencode. Für embedded-Systeme wichtig (Es gibt auch die Aussage, C sei ein besserer Makroassmembler, was in dieser Beziehung eben zutreffend ist.) In dieser Beziehung sehe ich C gar nicht (mehr) als eine Sprache, in der man programmiert, sondern als eine Zwischensprache in der Toolkette der Codegenerierung für ein Zielsystem, so etwa wie es bei Assembler seit Jahren schon ist (nur noch wenige spezifische Dinge werden in Assembler programmiert, aber die Assemblersprache ist wichtig für die Kontrolle der Abbildung eines Codes auf CPU-Niveau - vor ca. 20 Jahren hat man noch viel öfter in Assembler programmiert).
• Nicht nur der Übersetzer Java nach C ist wichtig, sondern auch ein Laufzeitsystem, was Garbage-collection und dergleichen kann. Außerdem müssen die notwendigen Standard-Funktionen (String, List, java.lang) vorliegen, ggf. direkt in C optimiert. Deshalb kommt der GCJ auch mit einer umfangreichen Library daher. Und dieses muss wiederum auf die Belange der embedded Systeme abgestimmt sein. Ein solches Laufzeitsystem ist dann nicht nur sinnvoll für von Java nach C übersetzte Programme, sondern ggf. auch ohne den Java-Gedanken einfach so als Laufzeitsystem mit Java-ähnlichen C-like Schnittstellen (anstatt sich an einen anderen Standard anzulehnen, der ggf. mehr proprietär ist). Allein für ein solches Laufzeitsystem lohnt es sich bereits Gedanken zu machen.

Ein Gedanke zum GarbageCollector: So etwas zu haben, ist für Java-Entwickler essentiell, wird aber oft als zu ressourcenhungrig für den Embedded-Bereich angesehen. Einige SoftwarePatterns bauen kommentarlos auf die Existenz des GC, in C++-Umgebungen ohne GC werden sie nur innerhalb umfangreicher Frameworks implementiert. Es wäre interessant zu erfahren, ob ein GC-Äquivalent im Embedded-Bereich Fuß fassen kann. (Bei dieser Gelegenheit fällt mir ein, dass ich mal über DynamischeStackframes? nachgedacht hatte. Gibt es Compiler, die solchen Code erzeugen?) --WolfPeuker