Java2 C
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Java ist eine gut durchdachte objektorientierte moderne Programmiersprache. Algorithmen lassen sich gut in Java testen, auch unter Multithreadbedingungen. Java ist aber nicht für schnelle Echtzeit gedacht.

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:

Das wärs erstmal für heute, ich hoffe auf weitere Diskussionen. HartmutSchorrig.

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


StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 4. November 2009 9:07 (diff))
Suchbegriff: gesucht wird
im Titel
im Text