Java gleich in Maschinensprache übersetzen?

[Djon]

Hallo!!!

Ich habe hier mal kurz nachgedacht, und konnte nichts feststellen was gegen ein Javaprogramm in Maschinensprache sprechen würde. Wieso gibt es keinen Compiler, der Javacode gleich, wie z.B. in C oder anderen Hochsprachen in die Maschinensprache übersetzt? Ich verstehe natürlich, dass der Javacode auf beliebigen Plattformen ausführbar sein sollte, doch wenn ich davon ausgehe, dass ich mein Programm nur auf x86 - Architektur ausgeführt wird, spricht doch nichts gegen oder? Oder ist es aus irgendwelchen tiefverborgenen technischen Gründen nicht machtbar?

mfg Djon

 

[DesertFox]

Ähhm meinst du sowas wie umformung in exe dateien, also die native übersetzung? Das gibt es, aber dann verliert man die Plattformunabhängigkeit: http://www.java-forum.org/de/viewtopic.php?t=1525

 

[bygones]

nein ich denke er will noch einen Schritt weiter gehen. Das erstellen von exe datein ist meist nur das erstellen eines Wrappers der ein jar aufruft

 

[Bleiglanz]

Class.forName("ich.komm.aus.dem.Internet.von.Irgendwoher";

dann mit reflection

method.invoke(...)

=> sowas wird man nie mit einem native Compiler erledigen können

 

[Djon]

also meine Frage war es, ob man .java-Dateien gleich in die "richtige" Maschienensprache, wie z.B. bei Assembler übersetzen kann. Also wenn ich dann anschliessend die .exe-Datei starte, brauche ich für die Ausführung nicht unbedingt die VM. Ist es möglich?

mfg Djon

 

[DTR]

Es ist eingeschränkt möglich. Ich habe mal von einem Compiler gelesen der dir direckt Maschienencode erzeugt. Aber wie schon oben angemerkt verlierst du dabei etwas an Javafunktionalität. Leider habe ich den Namen des Compilers vergessen.

 

[Djon]

ja, das ist mir vollkommen klar. Ich brauch wie gesagt den Compiler nur für meine eigenen Programme, die ich zu hause für mich selber schreibe. Wenn dir der Name wieder einfällt, dann melde dich bitte!

mfg Djon

 

[bygones]

schreibs doch dann in C oder C++ !

 

[Djon]

naja, in C oder C++ bin ich noch nicht mächtig, kommt erst im nächsten Semester

mfg Djon

 

[Roar]

ich glaub ihr meint den hier; http://www.excelsior-usa.com/jet.html
aber: ichversteh nicht wozu da sgut sein soll. ich seh keinen vorteil...
ob das soviel schneller sein soll...

 

[Bleiglanz]

wenn du linux hast, dann probier doch einfach mal den gcj, der ist eh mit dabei

witzig ist auch der versuch, SWT nochmal native zu übersetzen:

http://www.thisiscool.com/gcc_mingw.htm

 

[dark_red]

wobei ausführbare datien mit gcj langsamer sind, als wenn man das selbe in der vm ausführt. dafür spart es etwas ram

 

[0xdeadbeef]

Ich denke mal, der große Vorteil eines Exe-Compilers wäre die Möglichkeit der Distribution an Computer-Dummies. Eine Exe kann jeder Dödel ausführen. Wenn man aber erst erklären muß, daß man eine JVM braucht oder Webstart installiert haben muß, winken viele Leute schon dankbar ab.

 

[Roar]

Ich denke mal, der große Vorteil eines Exe-Compilers wäre die Möglichkeit der Distribution an Computer-Dummies. Eine Exe kann jeder Dödel ausführen. Wenn man abdr erst erklären muß, daß man eine JVM braucht oder Webstart installiert haben muß, winken viele Leute schon dankbar ab.

man kann auch gleich eine jre mit einer exe mitbundlen. viel größer als sone komische von jet erzeugte executable wird das nicht sein (programm + 30MB jre)

 

[dark_red]

zudem sind java-programme in native-code in der regel langsamer. also gleich beim bytecode bleiben. hat eine menge vorteile. selbst ms ist mit .net zu bytecode gewechselt.

 

[Gast]

> witzig ist auch der versuch, SWT nochmal native zu übersetzen
Der Versuch ist bereits geglückt.

 

[elchaschab]

auf www.excelsior-usa.com findest du einen nativ compiler für java2. funktioniert einwandfrei für win32 (linux support nur in beta).
ausserdem gibt es eine java erweiterung für gcc -> gcj. gcj unterstützt aber leider kein awt.

und zu den postern die meinen der code sei native-kompiliert langsamer.... erst probieren, dann posten.
mfg, elchaschab

 

[bronks]

... java-Dateien gleich in die "richtige" Maschienensprache, wie z.B. bei Assembler übersetzen kann. Also wenn ich dann anschliessend die .exe-Datei starte, brauche ich für die Ausführung nicht unbedingt die VM. Ist es möglich? ...

Was heißt "z.B."? Assembler ist das einzige, was hinten Maschinensprache rausspuckt. Das macht kein C- und ein C++Compiler schon gar nicht. In C kann man auch AssemblerCode unterbringen, aber es wird nichts daraus was man Maschinensprache nennt. Ausführbare Programme in Maschinensprache haben in MS-Umgebung die Endungs "*.com". Sie werden zwar vom Betriebssystem aufgerufen, brauchen das Betriebssystem zum Ablauf nicht.

Eine "*.exe" ist ein unleserlicher Zusammenschmiss von Funktionsaufrufen, in dem Maschinensprache teilweise, aber nicht immer, eher selten, enthalten ist. Um ein C-Programm mit brauchbarer Funktionalität ablaufen lassen zu können braucht man einen haufen Libs, die sich wichtig machen, aber sonst eigentlich in keiner Weise einen Vorteil gegenüber der aufgeräumten JVM bringen.

 

[Linuxhippy]

Ah, ich sehe als Laie also gleich: hier spricht ein Mann von Welt - der kennt sich aus und will das auch zeigen!

Was heißt "z.B."? Assembler ist das einzige, was hinten Maschinensprache rausspuckt. Das macht kein C- und ein C++Compiler schon gar nicht

Ahhh, so ist das! Ein C-Compiler spuckt hinten C-Sprache aus, drum heißt er auch Compiler - ich frag mich bloß was Sachen wie RTL im gcc dann machen. Man sieht hier deutlich: Man lernt nie aus ;-)

Eine "*.exe" ist ein unleserlicher Zusammenschmiss von Funktionsaufrufen, in dem Maschinensprache teilweise, aber nicht immer, eher selten, enthalten ist.

Und was soll in einer Exe-Datei außer Konstakten/daten noch drinnen sein? Bytecode ;-)

Um ein C-Programm mit brauchbarer Funktionalität ablaufen lassen zu können braucht man einen haufen Libs, die sich wichtig machen. aber sonst eigentlich in keiner Weise einen Vorteil gegenüber der aufgeräumten JVM bringen.

Hmm, gut, das ist Ansichtssache, aber es gibt Vorteile:
* Ram-Verbrauch (shared libraries, keine Runtime, kein heap (im GC sinn).
* Laufzeitperformance (nicht erst 1500 invocations bis das ordentlich funtzt)
* Ladezeit
* nicht 100%ige abhängigkeit von SUN

Das heist jetzt nicht, dass ich java schlecht finden würde, aber alles dorthin, wo es hingehört. Ein modernes desktop-Programm würd ich kaum mehr in C++ anfangen, sohingehen eine JVM als Mustererkennungssoftware eher nicht zu brauchen ist.

lg Clemens

 

[Vatar]

Ich hab vor einiger Zeit mal etwas von einem Prozessor namens "Pico" gelesen. Der soll angeblich Javacode verstehen. Wie die Sache genau läuft weiß ich nicht, googlet einfach mal nach pico java

 

[Bleiglanz]

Hat mich schon immer interessiert, weils ein gutes beispiel für eine IT-Leiche ist:

Sun hat eine neue Generation von speziellen Java-optimierten Chips angekündigt. Diese CPUs sollen den Output des Java-Compilers direkt und ohne den Einsatz einer Softwareschicht abarbeiten können. Deshalb können sie die Java-Programme schneller als andere CPU-s ausführen. Allerdings eignen sie sich auch nur für die Java-Applets. Als erster Chip soll die "Pico-Java" Mitte 1996 erscheinen. Dieser Chip soll unter 25 $ kosten und in Peripheriegeräten und Mobilfunktelephonen Einsatz finden. Der nächste Chip - "Micro-Java" wird wahrscheinlich im ersten Quartal 1997 erscheinen und ist mit einem Stückpreis zwischen 25 $ und 100 $ für Netzwerkgeräte, Buchungssysteme, Mail-Terminals und Spielkonsolen bestimmt. Schließlich am Ende 1997 soll ein Chip namens "Ultra-Java" erscheinen. Ultra-Java wird etwas über 100 $ kosten. Er soll aber auch 2D und 3D-Graphik, Audio, Vidokompression, Netzwerke und Verschlüsselung unterstüzen und ist für die zukünftige Internet-PCs bestimmt.

1995 - 1996 -1997 -

muss irgendwas im Zeitplan durcheinander gekommen sein...

 

[0xdeadbeef]

Man sollte sich bei all diesen Diskussionen darüber im Klaren sein, daß die teils langsame Ausführung von Java-Programmen nicht wirklich darin begründet liegt, daß der Byte-Code von der JVM interpretiert werden muß, zumal bei engen Schleifen eh der JIT-Compiler einspringt.

Es gibt einige prinzipielle Designentscheidungen der Sprache, die dafür Sorgen, daß man mit Java nie wirklich die Geschwindigkeit von optimierten C-Code (oder gar Assemblercode) erreichen kann.
Einer dieser Punkte ist die Bounds-Überprüfung von Arrays. Ein anderer der Zwang, dauernd Objektinstanzen zu erzeugen und zu zerstören. Auch der in Java immer vorhandende Polymorphismus kostet viel Laufzeit. Nicht umsonst wird dieses Feature von vielen C++-Programmierern aus Performancegründen nicht benutzt.
Beides waren bewußte Designentscheidungen - den Gewinn an Sicherheit (Buffer Overflows) bzw. sprachlicher Eleganz und Einfachheit bezahlt man halt mit niedrigerer Geschwindigkeit.

Wobei man definitiv mal sagen muß, daß Java trotz allem eigentlich recht perfomant ist - zumindest solange man mit Basistypen operiert. Richtig schlimm wird es erst mit Swing. Warum auch immer: einige der JFC-Klassen sind atemberaubend langsam (insbesondere JTextPane usw.). Hier hilft eventuell der Umstieg auf SWT (z.B. per SwingWT). Die sogenannten Java-Exe-Compiler ändern daran jedenfalls leider nichts (eventuell bis auf den experimentellen GCJ mit SwingWT-Unterstützung).

 

[Beni]

Ein Teil der Langsamkeit von Swing kommt aus Bugs. Mit Java 6 soll sich im Swing-Bereich einiges tun, man kann nur hoffen...
(Das sind z.T. auch eher psychologische als echte Probleme. Dass bei einem Java-Fenster kurz graue Rechtecke bleiben können wenn man es herumzieht sieht exterm schlecht aus, aber wäre eigentlich keine grosse Sache zum eliminieren).

 

[Roar]

Ein Teil der Langsamkeit von Swing kommt aus Bugs. Mit Java 6 soll sich im Swing-Bereich einiges tun, man kann nur hoffen...
(Das sind z.T. auch eher psychologische als echte Probleme. Dass bei einem Java-Fenster kurz graue Rechtecke bleiben können wenn man es herumzieht sieht exterm schlecht aus, aber wäre eigentlich keine grosse Sache zum eliminieren).

in den java 6 snapshots ist es bereits eliminiert