3.12 [TOOLS] Java-Zusatz-Tool, zum Beispiel IDEs, Build-Tools, Profiler, etc.
Zurück zu "3 Häufig gepostete Fragen"
3.12.1 Welche IDE muss ich verwenden?
http://groups.google.com/groups?q=beste+%2B+IDE+%2B+Java++-emacs+-vi+-vim+-notepad+group%3Ade.comp.lang.java&hl=de&btnG=Google-Suche
Bietet eigentlich jederzeit einen guten Überblick, wobei
wahrlich auch ein guter Link ist.
Autor: Martin Erren
Zurück zu "3.12 [TOOLS] Java-Zusatz-Tool, zum Beispiel IDEs, Build-Tools, Profiler, etc."
3.12.2 Wie kann man eine Java-Anwendung in eine EXE-Datei umwandeln?
Ein nativer Compiler ist in der Lage, Quelltext oder Bytecode in eine
native Anwendung (statt wie üblich bei Java in Bytecode, also
.class-Dateien) umzuwandeln, etwa eine EXE-Datei unter Windows.
Auf http://www.geocities.com/marcoschmidt.geo/java.html sind u. a.
auch einige native Compiler und weiterführende Links zum Thema "native
compilation" aufgelistet.
Bei der Verwendung gibt es allerdings ein paar Punkte zu beachten.
- Gute native Compiler sind recht teuer und somit nur im
professionellen Umfeld sinnvoll einsetzbar. Der freie native Compiler
gcj unterstützt z. B. nur Java 1.1, und auch das nur teilweise (kein
AWT etc.).
- Obwohl das vom nativen Compiler erzeugte Programm aus nativem Code
besteht, muß oft trotzdem noch ein Java Runtime Environment
installiert werden, so daß der Vorteil der einfachen Verteilung des
Programms wegfällt - der Benutzer könnte genauso gut direkt das JRE
installieren und die Bytecode-Version der Anwendung starten.
- Der große Geschwindigkeitsvorteil durch nativen Code existiert
heutzutage nicht mehr, da moderne JVMs durch Just-in-time-Compiler in
den meisten Fällen sehr nah an nativen Code herankommen. In
Einzelfällen mag es aber durchaus Vorteile bei nativem Code geben.
- Da es native Compiler nicht für all diejenigen Plattformen gibt, für
die auch JREs existieren, schränkt man die Anzahl potentieller Nutzer
ein, wenn man auf nativen Code besteht. Allerdings dürften mit nativen
Compilern für Windows und ein paar der verbreiteteren Unix-Varianten
absolut gesehen der größte Teil aller Computerbenutzer abgedeckt sein.
- Wer nativen Code verwendet, muß eventuell mehrere Versionen des
Programms für verschiedene Plattformen pflegen. Durch die Verwendung
von Bytecode (.class-Dateien) hat man eine Version, die überall
ausgeführt werden kann ("write once, run anywhere").
Zum Schluß noch ein paar Vorteile durch die Verwendung eines nativen
Compilers.
- Native Programme starten meist schneller - dies ist für lang
laufende Server-Anwendungen nicht so wichtig, für häufig aufgerufene
Kommandozeilenprogramme allerdings schon eher.
- Es ist schwerer, nativen Code als Bytecode zu dekompilieren (also
wieder den Quelltext zu erhalten). Wer also Reverse-engineering seines
Programms fürchtet, hat bei Bytecode mehr Anlaß zur Sorge.
- Einige native Compiler ermöglichen es, daß gleichzeitig laufende
Instanzen der erzeugten Programme sich gewisse Ressourcen teilen und
so weniger Arbeitsspeicher verbrauchen. Aktuelle JVMs laufen stets
völlig unabhängig voneinander ab (dies wird sich vielleicht nach Java
1.4 ändern). Man kann mit nativen Anwendungen also mehr Instanzen
eines Programms auf demselben System laufen lassen.
Native Compiler haben in einigen Nischen also durchaus
Daseinsberechtigung. Allerdings sollte, wer sich um einfache
Verteilung seines Programms Gedanken macht, eine der folgenden
Möglichkeiten in Betracht ziehen:
Autor: Marco Schmidt
Zurück zu "3.12 [TOOLS] Java-Zusatz-Tool, zum Beispiel IDEs, Build-Tools, Profiler, etc."