# *.exe erstellen?



## Stealth Cyborg (16. Juli 2004)

Hallo, 

ich hab eine Frage!

Ist es möglich, in JAVA eine *.exe zu erstellen (wie z.B. bei C++)?

Wenn nein, wie kann ich es dann schaffen, die Datei ohne dem befehl java in der Komandozeile, auszuführen.

Danke im voraus

-Stealth Cyborg-

PS.: Kennt einer ein perfektes Skript, in dem man ganz leicht awt und swing beigebracht bekommt?


----------



## squeaker (16. Juli 2004)

Es geht nicht wenn die Plattformunabhängigkeit gewahrt werden soll. Das beste eigentlich ist es ein jar-File mit allen benötigten Dateien zu erstellen und dort eine Manifest.MF Datei zu platzieren (sollte eigentlich dein IDE können).
Andernfalls gibt es noch ein Projekt welches exes erstellt - gcj glaube ich - ist aber noch nicht ausgereift.


----------



## Stealth Cyborg (16. Juli 2004)

*ah*

cool danke! Kennst du den befehl um eine *.exe zu ertellen? Die Plattformunabhängigkeit muss bei mir erstmal nicht bewart werden ;-)

Und das andere, wie erstelle ich so ein jar-file? Ich bin noch relativ neu in der JAVA-Programmierung......

Danke für Beantwortung


----------



## squeaker (16. Juli 2004)

es gibt keinen "Befehel" für die exe - du brauchst das Programm gcj.

Mit welcher IDE arbeitest du?


----------



## Christian Fein (16. Juli 2004)

Was bringt dir ne exe?

Das du per Mausklick das Programm starten kannst.

um das zu erreichen brauchst du aber keine exe.
Es gibt 2 einfache und plattformunabhängige Lösungen:

1) packs in eine jar. Eine Jar wird auch bei Doppelklick mit javaw gestartet, das heisst die jar verhält sich wie eine Exe.

2) Wenn du ganz sicher sein willst schreib ein kurzes .bat script das java und die mainmethode aufruft. Auch dieses ermöglicht dir das selbe wie die exe


----------



## Snape (16. Juli 2004)

*Re: ah*



> _Original geschrieben von Stealth Cyborg _
> *cool danke! Kennst du den befehl um eine *.exe zu ertellen? Die Plattformunabhängigkeit muss bei mir erstmal nicht bewart werden ;-)
> 
> Und das andere, wie erstelle ich so ein jar-file? Ich bin noch relativ neu in der JAVA-Programmierung......
> ...



Es gibt keinen Befehl um aus einer Java Anwendung eine .exe zu generieren. Aber es gibt Tools die das können. Z.B. JexePack (http://www.duckware.com/). Allerdings muss ich zugeben, dass es mir damit noch nicht gelungen ist, eine .exe zu erstellen...
Auch der JBuilder hat eingebaut eine Funktionalität zur Erstellung von ausführbaren Dateien, nicht nur für Windows, sondern auch für Linux, Mac, Solaris. Das funktioniert auf jeden Fall. Allerdings müsstest Du mal schauen, bei welcher JBuilder Version das integriert ist. Ich vermute, nicht bei der freien...


----------



## Snape (16. Juli 2004)

> _Original geschrieben von Christian Fein _
> *Was bringt dir ne exe?
> 
> Das du per Mausklick das Programm starten kannst.
> ...



Ich nehme an, seine Frage zielt darauf ab, der Zielperson die das Programm bekommen und starten soll, das Java-Umfeld zu ersparen, also ohne JRE/JVM. Ich kenne auch Leute, die das so wünschen. Daner wird Dein Hinweis vermutlich nicht helfen...


----------



## Christian Fein (16. Juli 2004)

> _Original geschrieben von Snape _
> *Ich nehme an, seine Frage zielt darauf ab, der Zielperson die das Programm bekommen und starten soll, das Java-Umfeld zu ersparen, also ohne JRE/JVM. Ich kenne auch Leute, die das so wünschen. Daner wird Dein Hinweis vermutlich nicht helfen... *



Wenn es um das JRE erspaaren geht, dann hast du recht. 
Wenn es aber nur um das "exe" Startlike geht dann nicht 

Vielleicht kann Threadstarter genau sagen was ihm wichtig ist


----------



## squeaker (17. Juli 2004)

hier der link zu gcj

http://gcc.gnu.org/java/


----------



## Terrance & Philipp (18. Juli 2004)

Wie sieht das eigentlich Performancemässig aus? Nützt die Kompilierung zu einer Exe Datei etwas?


----------



## Kuniberd (22. Juli 2004)

Also ich habe mit jsmooth sehr gute Ehrfahrung gemacht. 
http://jsmooth.sourceforge.net/ 
Hat ne sehr schöne GUI.

Ob es was für die Performence bringt kann ich leider nicht beantworten. Ich habe bis jetzt keine Geschwindigkeitssteigerung festgestellt.


----------



## squeaker (22. Juli 2004)

> _Original geschrieben von Terrance & Philipp _
> *Wie sieht das eigentlich Performancemässig aus? Nützt die Kompilierung zu einer Exe Datei etwas? *



vermutlich nicht, da sie noch nicht so weit in der Entwicklung sind um etwas auf Geschwindigkeit zu optimieren.


----------



## squeaker (22. Juli 2004)

> _Original geschrieben von Kuniberd _
> *Also ich habe mit jsmooth sehr gute Ehrfahrung gemacht.
> http://jsmooth.sourceforge.net/
> Hat ne sehr schöne GUI.
> ...



Das macht keine Executable sondern verpasst dem Ganzen nur einen Wrapper der die VM aufruft. Der Sinn einer exe wäre, die VM nicht mehr zu benötigen.


----------



## Cybernd (22. Juli 2004)

Es ist unmöglich Java Bytecode ohne VM auszuführen ;o)

Sobald ein GC in der Exe steckt, kann man von einer integrierten VM ausgehen.

Zur Geschwindigkeit: Es gab mal Benchmarks in der dclj. Der Gcj war irgendwo zischen Server und ClientVM angesiedelt. Zum Teil ein bissi schneller als die Client VM, aber langsamer als die Server VM.

Im übrigen ist die Frage performance belanglos, denn sowohl die VM als auch gcj arbeiten mit nativem compilat. Interpretiert wird schon lange nicht mehr.

cybi


----------



## squeaker (23. Juli 2004)

ich dachte der gcj kompiliert Java-Byte bzw. Quell-Code nach C/C++ und das mittels gcc nach nativ? Damit ist nicht mehr von einer "integrierter VM" zu sprechen. Bei einer solchen könnte man das ganze wieder zurückverwandeln quasi entpacken (was bei einem Wrapper geht). Beim nativen Compilat geht dies definitv nicht (dafür kann man es dann ordentlich disassemblieren).


----------



## Cybernd (23. Juli 2004)

Nur weil es als reines natives compilat vorliegt, heißt es noch lange nicht das auf diese Schicht namens "VM" verzichtet werden kann ;o)

Sie wird lediglich auf eine andere Art und Weise abgebildet.

cybi


----------



## squeaker (23. Juli 2004)

Ist deine CPU virtuell - also meine ist es nicht. Eine VM ist eine VirtualMachine. Der Code der dort ausgeführt wird hat nichts mit dem realen Code der Maschine zu tun auf der die VM läuft. Die VM übersetzt (wie auch immer) den eigenen Code in den Code der tatsächlichen Maschine.

Bei einem nativen Compilat fällt dieser Übersetzungsschritt weg - schliesslich liegt der auszuführende Code schon nativ weg. Dies ist - und wird nie - eine VM sein und hat auch nichts mit dem Konzept zu tun.

JIT-Techniken ändern daran auch nichts, und auch nicht die Tatsache, dass der Java-Quellcode über einen Zwischenschritt Bytecode in nativen Code compiliert werden kann.


----------



## Cybernd (23. Juli 2004)

Kleiner Querverweis ins Usenet:
http://groups.google.at/groups?hl=d...elm=c6tv47%24k3k%2405%241%40news.t-online.com

Alle Posts durchlesen (25).

cybi


----------



## squeaker (23. Juli 2004)

Ich bin jetzt zur hälfte durch, aber nur weil eine Bibliothek die Funktionen der VM übernimmt (und die der java bib) heisst das noch lange nicht, dass es eine VM ist. Es ist trotzdem nur eine Bibliothek.

Der Punkt ist:

eine VM (in Reinstform) interpretiert einen Maschinencode für die Maschine die sie virtuell darstellt. Dieses Konzept wird durch JIT-Compiler etwas verwässert, aber das Grundprinzip ist immer noch das gleiche - es liegt ein für die aktuelle Maschine nicht zwingend ausführbarer Code vor den die VM dann ausführt.

Ein natives Compilat hat nun andere Eigenschaften:
1. Ich kann z.B. verlinkte Bibliotheken (die auch nativ vorliegen müssen) statisch verlinken
2. Ich brauche ausser dem Binary keine weiteren Elemente mehr auf meiner Maschine.
3. Ich bin OS und Hardwareabhängig - könnte aber auch direkt Hardware ansprechen ohne die Java-Bibliotheken zu bemühen (das ginge dann allerdings nur über CodeInjection bzw. ähnlich wie bei einer Virusinfektion müsste Code zum Binary hinzugefügt werden.
4. Mein Compiler muss dafür sorgen, dass die von Java bekannten Mechanismen (z.B. GarbageCollection) entsprechend realisiert werden (z.B. durch zusätzlichen Code der mit compiliert wird oder aber durch Bibliotheken).
5. Das dynamische Nachladen von Klassen via Klassloader dürfte nicht mehr funktionieren, bzw. auf ganz anderen Mechanismen fußen z.B. Speicher allozieren, assemblierte Klasse laden, Zusatzinformationen für die Einsprungpunkte laden, Speicher ausführbar markieren, Einsprungpunkte in die entsprechenden Variablen bzw. Tabellen eintragen, ausführen).

Dies sind meiner Meinung nach gravierende Unterschiede zur VM. Es werden nur die Funktionen von der VM die für das funktionieren von Java nötig sind - nicht aber der Teil bei dem der Bytecode interpretiert/jit-compiled wird. Damit ist das native compilat keine VM.

Ich warte schon sehnsüchtig auf die Gegenargumente


----------



## Cybernd (23. Juli 2004)

Negativ es ist und bleibt eine Laufzeitumgebung. Nichts anderes ist eine VM.

Außerhalb dieser Laufzeitumgebung kann der weitere Code nicht ablaufen. Weil eben Java kein rein statisch verlinkter Code sein kann. (Okay können schon, aber nur wenn man auf nahezu alle wichtigen Features verzichten würde).

Ob es sich nun um Bytecode oder direktes natives Compilat handelt ist für die Funktionalität der VM wiederum egal. Sie wäre auch eine VM, wenn sie nur mit nativen Klassen gefüttert werden würde. 

cybi


----------



## squeaker (23. Juli 2004)

> _Original geschrieben von Cybernd _
> *Negativ es ist und bleibt eine Laufzeitumgebung. Nichts anderes ist eine VM.
> 
> Außerhalb dieser Laufzeitumgebung kann der weitere Code nicht ablaufen. Weil eben Java kein rein statisch verlinkter Code sein kann. (Okay können schon, aber nur wenn man auf nahezu alle wichtigen Features verzichten würde).
> ...



negativ? was meinst du damit?

Warum kann java nicht statisch verlinkt sein?

Ob es Bytecode oder direktes natives Compilat handelt ist für JAVA egal - es bleibt JAVA - aber nicht für die VM. Das eine mal wird sie gebraucht, das andere mal nicht.


----------



## Cybernd (23. Juli 2004)

Gängige VMs werden in c/c++ geschrieben. Sie sind danach Maschinencode.

Nur weil jetzt diese c/c++ Sourcen direkt mit den gewandelten c Sourcen der Klassen vermengt werden, heißt es noch lange nicht das diese VM jetzt nicht mehr vorhanden ist. Sie verbirgt sich trotz allem im compilat das z.b. von Gcj erzeugt wird. Das ist nunmal ein Fakt.

Beim einen male ist die VM und die darin ablaufende Applikation trennbar. Beim anderen male zu einem monolitischen Block verschmolzen. Fakt ist dennoch das beide Varianten diese Art der Laufzeitumgebung beinhalten.

cybi


----------



## squeaker (23. Juli 2004)

VM ist ein Konzept - nicht ausführbarer Code (für die aktuelle Maschine) wird durch ein Programm ausgeführt! Dieses Konzept ist nicht gegeben.


----------



## Cybernd (24. Juli 2004)

Achja, Bytecode ist also nicht direkt ausführbar? Erklär das mal einem Java-Prozessor.

cybi


----------



## squeaker (26. Juli 2004)

ein Java-Prozessor ist auch keine JavaVM mehr - nur eine "JavaM". Ein GB-Emulator ist auch eine VM, nur weil es einen GB gibt der es ausführt (nativ) heisst das noch lange nicht, dass der Emulator auf meinem x86 dafür keine VM ist.

Wichtig ist der Zusatz "für die aktuelle Maschine"


----------



## Cybernd (26. Juli 2004)

Du willst einfach nicht davon abkommen das die VM sich nur dadurch auszeichnet das CodeA in CodeB übergeführt wird. Dies ist für eine VM absolut irrelevant!

Formulierungen wie die hier (Wikipedia) erklären was VM wirklich bedeutet: "Die VM schottet die in ihr laufenden Prozesse vom Betriebssystem ab. Dies hat zur Folge, dass es nicht mehr möglich ist, mit systemeigenen Mitteln Prozesse zu kontrollieren. Sie stellt aber auch keine eigenen Funktionen zur Prozesskontrolle und -steuerung bereit. Somit können diese auch nicht von außen beendet werden, wenn sie auf Grund eines Fehlers das Gesamtsystem stören. Dazu muß dann die gesamte VM beendet werden."

Das Bytecode in MaschinenCode übersetzt wird ist nur ein zusätzliches schmankerl. Es hat aber im Grunde genommen nichts mit dem "Virtual Machine" zu tun.

Wenn der javac gleich nativen Code erzeugen würde, so würde dieser in exakt der selben VM ablaufen.

BemerkungA: Bald wird man auch Prozesse in der VM beenden können
BemerkungB: Diese Abschottung muß auch im nativen compilat eine gcj durchgeführt werden. Stichwörter: Policy, SecurityManager

cybi


----------

