Such: Tool zum *.jad oder *.java zu *.class konvertieren

[Enqui]

Hallo,

ich suche nur ein Tool, kein kompleziertes Programm etc, mit dem man Java Datein in Class datein konvertieren kann.

Weis da jemand eins ?

Gruß,
Enqui

[MudGuard]

Hi,

ich suche nur ein Tool, kein kompleziertes Programm etc, mit dem man Java Datein in Class datein konvertieren kann.

Wie wärs mit dem Java Compiler (samt dazugehörigem JDK)?

cu,
Andreas

[Enqui]

Wie wärs mit dem Java Compiler (samt dazugehörigem JDK)?

.. was für ein JDK Java Compiler denn?
Hab bis jetzt nur das komplette JDK Pack gefunden..und das waren ~95 MB.. ^^ ich dachte da eher an so eine kleine exe die maximal 1 MB groß ist. Gibts so was?

Gruß
Enqui

[MudGuard]

Hi,

Wie wärs mit dem Java Compiler (samt dazugehörigem JDK)?
.. was für ein JDK Java Compiler denn?
Hab bis jetzt nur das komplette JDK Pack gefunden..und das waren ~95 MB.. ^^ ich dachte da eher an so eine kleine exe die maximal 1 MB groß ist. Gibts so was?

Das Compiler-exe reicht aber nicht, Du brauchst ja auch die ganzen Standard-Klassen...

cu,
Andreas

[Slyh]

Hallo,

Wie wärs mit dem Java Compiler (samt dazugehörigem JDK)?
.. was für ein JDK Java Compiler denn?
Hab bis jetzt nur das komplette JDK Pack gefunden..und das waren ~95 MB..

Mal nicht übertreiben. Es sind 50MB.

Du kriegst das auch anderweitig kompiliert, ja. Aber, glaub mir, du willst
dir das JDK auf jeden Fall runterladen, wenn du sinnvoll was in Java
machen willst.

http://java.sun.com/j2se/1.4.2/download.html
Dort "J2SE v 1.4.2_04" SDK. (Das ist unter dem 3. großen blauen Balken.)

Gruß
Slyh

[Christoph Schnauß]

morgens Slyh,

http://java.sun.com/j2se/1.4.2/download.html

Was hältst du eigentlich von j2sdk-1_5_0-beta? Und überhaupt: wie kommt jemand auf die Idee, daß es "jad"-Dateien geben kann, die sich zu "class"-Dateien kompilieren lassen könnten *g*?

Grüße aus Berlin

Christoph S.

[Slyh]

Hallo,

http://java.sun.com/j2se/1.4.2/download.html

Was hältst du eigentlich von j2sdk-1_5_0-beta?

Von der Beta halte ich nicht viel. Die hat mit Eclipse ziemlich rumgezickt.
Außerdem scheint sie erheblich langsamer zu sein und ungefähr doppelt
soviel Speicher für das gleiche Programm zu benötigen, als es die
JRE 1.4.2 tut.
Ich nehme an, daß dies auf den Beta-Status zurückzuführen ist. Wenn
nicht, dann wäre das ziemlich schlecht. ;)

Von den Erweiterungen von Version 1.5 bin ich -- soweit ich sie bisher
gesehen habe -- ziemlich angetan. Vieles, was man bisher vermißt hat,
wird jetzt nachgeliefert. (Wird auch Zeit.)

Nicht so toll finde ich allerdings, daß es sich bei den meisten
Erweiterungen primär um Tipp-Erparnisse handelt, weniger um grundlegend
Neues.
Intern werden enums auf Klassen gemapped. Auch die Generics werden
intern in "alten" Java-Code umgewandelnt. Na gut, immerhin kommt eine
gewisse Typsicherheit hinzu.

Grundsätzlich ist das ja nicht problematisch. Leider wird dadurch aber
auch keine Performance-Verbesserung erreicht.
Man spart sich praktisch nur Tipp-Arbeit.

Was ich gerne sehen würde, wäre ein Java 2.0, das nicht mehr mit dem
alten Java kompatibel ist. Hier sollten einige Sprachaspekte verbessert
werden und einige Design-Fehler in der API ausgebügelt werden.
Klassisches Beispiel:
   meinArray.length <-> meineArrayList.size() <-> meinString.length()

Letztendlich ein C# für Java, wenn man so will.
Und dann bitte gleich mit anständiger Kontrolle über den Garbage
Collector. (Ich will Speicherbereiche von Hand freigeben können. Man
kann einen Compiler durchaus so bauen, daß man trotzdem keine Speicher-
zugriffsfehler ins Programm einbauen kann.)

Naja, es gäb da so einiges zu verbessern... Wie überall...

Und überhaupt: wie kommt jemand auf die Idee, daß es "jad"-Dateien geben kann, die sich zu "class"-Dateien kompilieren lassen könnten *g*?

Naja, eine .jad-Datei ist ja auch nur eine .java-Datei mit anderem
Namen.

Gruß
Slyh

[Daniel Thoma]

Hallo!

Von der Beta halte ich nicht viel. Die hat mit Eclipse ziemlich rumgezickt.
Außerdem scheint sie erheblich langsamer zu sein und ungefähr doppelt
soviel Speicher für das gleiche Programm zu benötigen, als es die
JRE 1.4.2 tut.

Also Netbeans läuft damit und davon, dass sie langsamer ist, habe ich nichts gemerkt.

Intern werden enums auf Klassen gemapped. Auch die Generics werden
intern in "alten" Java-Code umgewandelnt. Na gut, immerhin kommt eine gewisse Typsicherheit hinzu.

Das enums auch Klassen sind, ist eigentlich ja nur konzequent. Auch dass bei generische Klassen nur automatisch Casts eigefügt werden  halte ich aber für keinen Nachteil. Geschickter kann man das eigentlich nicht implementieren.
Einige Bytecodeerweiterungen gab es ja auch, damit Reflections zusammen mit Generischen Klassen und Annotations funktionieren.

Grundsätzlich ist das ja nicht problematisch. Leider wird dadurch aber auch keine Performance-Verbesserung erreicht.

Die erreicht man auch eher durch Verbesserung des Bytecodeinterpreters/compilers. Evt. natürlich auch durch einen besseren Bytecode aber ganz sicher nicht durch neue Sprachfeatures.
Außerdem soll 1.5.0 auch mehrere Anwendungen mit der selben VM laufen lassen können und die Standardklassen zwischen allen Anwendungen geteilt werden.

Klassisches Beispiel:
   meinArray.length <-> meineArrayList.size() <-> meinString.length()

Naja, das Methoden bei unterschiedlichen Schnittstellen unterschiedlich heißen, auch wenn sie etwas ähnliches tun, ist kein ausreichender Grund, eine inkompatible Version zu schaffen.

Und dann bitte gleich mit anständiger Kontrolle über den Garbage

Collector. (Ich will Speicherbereiche von Hand freigeben können. Man
 kann einen Compiler durchaus so bauen, dass man trotzdem keine speicherzugriffsfehler ins Programm einbauen kann.)
Den Kompiler kann man nicht so bauen, aber die Laufzeitumgebung.
Um mit Knappen Resourcen klar zu kommen, brauch man das aber eigentlich nicht mehr. Java läuft ja auch auf Handies und ähnlichen Geräten gut.
Interessant könnte es höchstens noch bei Echtzeitsystemen sein, da da die Gefahr besteht, dass der GC zur falschen Zeit aufräumen will und das Hauptprogramm zu lange unterbrochen wird.
Mit speziellen VMs, deren GC mit sehr niedriger priorität läuft, soll aber auch dieses Problem gelöst werden können.

Grüße

Daniel

[Martin Jung]

Hi,

Auch dass bei generische Klassen nur automatisch Casts eigefügt werden  halte ich aber für keinen Nachteil. Geschickter kann man das eigentlich nicht implementieren.

Hmmm, erstens kostet die Konvertierung/Autoboxing natürlich Performance - das muss nicht, kann aber ein Problem darstellen.
Was mich zweitens mehr interessiert: Kann man per Reflection den konkreten Typ des Generics zur Laufzeit ermitteln?

Viele Grüße,
Martin Jung

[Daniel Thoma]

Hallo Martin,

Hmmm, erstens kostet die Konvertierung/Autoboxing natürlich Performance - das muss nicht, kann aber ein Problem darstellen.

Autoboxing kostet Zeit ja. Die gefahr ist da aber höchstens, dass Programmierer durch dieses Feature vergessen, was da passiert und es dadurch an Stellen einsetzen, an denen das besser vermieden worden wäre.
Also an Stellen, wo man das bislang auch von Hand nicht gemacht hätte.
Casting kostet aber keine Zeit (jedenfalls nicht von Objekten, bei primitiven Typen schon) denn da wird ja nichts umgewandelt. Das ist ja nur ein Hinweis an den Kompiler, dass Du weißt, was Du da tust.

Was mich zweitens mehr interessiert: Kann man per Reflection den konkreten Typ des Generics zur Laufzeit ermitteln?

Ja kann man. Der Bytecode wurde dafür entsprechend erweitert. Wobei ich irgendwo gelesen habe, dass Generics abwärtskompatibel sind. Wenn man also für eine ältere VM kompiliert, geht es natürlich nicht mehr.

Grüße

Daniel

[Martin Jung]

Moin Daniel,

. Die gefahr ist da aber höchstens, dass Programmierer durch dieses Feature vergessen, was da passiert und es dadurch an Stellen einsetzen, an denen das besser vermieden worden wäre.

Bisher bin ich immer zu "Alt"-Projekten hinzugestoßen und sehe jetzt schon mit Grauen den Mischmasch der Code-Stile ;-)
Dies ist aber natürlich primär eine Frage von (Projekt)-Konventionen (und ihrem Controlling).

Was mich zweitens mehr interessiert: Kann man per Reflection den konkreten Typ des Generics zur Laufzeit ermitteln?
Ja kann man. Der Bytecode wurde dafür entsprechend erweitert. Wobei ich irgendwo gelesen habe, dass Generics abwärtskompatibel sind. Wenn man also für eine ältere VM kompiliert, geht es natürlich nicht mehr.

Letzteres wollte ich nochmal bestätigt wissen..

Viele Grüße,
Martin Jung

[Enqui]

http://java.sun.com/j2se/1.4.2/download.html
Dort "J2SE v 1.4.2_04" SDK. (Das ist unter dem 3. großen blauen Balken.)

Gruß
Slyh

DAaaanke.

[Noodles]

Hi Enqui

um aus java-Sourcecode ein Java-Programm zu erstellen benötigst du einen Compiler. Dieser wird mit dem Software Development Kit unter http://java.sun.com oder einer anderen Paketlösung (z.B. IBM JDK) geliefert. Der Compiler den du meinst heißt javac.exe. Aber du wirst ohne das gesamte SDK keinen Spaß an der Javaentwicklung haben. Eine geniale (und kostenlose!) Entwicklungsumgebung gibts unter http://www.eclipse.org. Solltest du dann doch nicht nur ein kleines Tool suchen, sondern richtig einsteigen wollen, dann bist du hiermit schon mal gut ausgerüstet.

Jad ist übrigens ein Decompiler, der genau das Gegenteil macht. Ergo .class -> Sourcecode

Grüße Noodles

[Enqui]

Jad ist übrigens ein Decompiler, der genau das Gegenteil macht. Ergo .class -> Sourcecode

Grüße Noodles

Aaah.. ^^ hab mich schon gewundert. *g*

Gibt es zum Kompelieren nicht ein tool mit GUI, das JDK Pack hab ich mir gerad runter geladen und irgendwie hat de javac.exe kein spass an meinen Java Datein ^^

Gruß
Enqui

[Noodles]

Gibt es zum Kompelieren nicht ein tool mit GUI, das JDK Pack hab ich mir gerad runter geladen und irgendwie hat de javac.exe kein spass an meinen Java Datein ^^

ich denke mal, der Java-Code wird auch mit graphischer Oberfläche des Compilers nicht besser *g*. Man muss dann halt den Compilermeldungen folgen (können), die manchmal nicht sehr vielsagend sind.
Am besten ist es, du holst dir Eclipse und bindest das SDK darin ein, dann musst du dich auch nicht mit Konsolenbefehlen rumärgern.

Noodles