welches jdk?

[peschmae]

soweit ich weiss, gibt es derzeit mindestens vier jdks für linux.
Welches ist das beste?

- Sun Jdk
- IBM Jdk
- Kaffee
- Blackdown Jdk

ist eines davon schneller oder sind die alle gleich lahm? (unter windows scheint mir die sun jdk einiges schneller zu sein als die blackdown unter linux...)

MFG Peschmä

[Lin728]

Hi peschmae!

Nun, um einmal die Geschichte von java zu erläutern:
Irgendwann so um 1998 oder auch ein bisschen später hat die Firma Blackdown beschlossen, dass Sun-JDK auf Linux zu portiere

Hier eine kurze Zusammenfassung der einzelnen JDKs:

Sun JDK:
Basiert auf dem Blackdown-Quellcode und stellt "offizielle" Linux-Java Version dar.
So langsam ist dier JDK gar nicht, er braucht nur ziemlich viel RAM.

Blackdown:
Vorgänger des Sun-JDKs, einigermaßen auf aktuellem Stand. Ziemlich glaich schnell wie das "originale" JDK von Sun.

IBM JDK:
Eine (soweit ich weiß) Eigentwicklung von IBM, die "leichter" ist als jene von Sun oder Blackdown. Ob sie schneller ist, kann man generell nicht sagen. Bei Low-Level-Operationen ist sie schneller wie SUN, beim anlegen von Objekten langsamer.

Kaffe:
Kaffe wurde unter der Zielsetzung entwickelt, ein GNU-Java zu schaffen. Leider ist es in letzter zeit (seit 1,5 jahren) eher still um diese Projekt geworden und es vielen viele neue Features. So wird beispielsweise SWING gar nicht unterstützt. Der vorteil von Kaffe ist dass es extrem wenig Arbeitsspeicher braucht und sehr schnell startet. Die Verarbeitungsgeschwindigkeit hinkt aber der von Sun hinterher. Wie gesagt, wenn man Programme (ohne GUI) entwickelt, aknn Kaffe ganz OK sein, aber so als Java-VM dür den Anwender ist sie eher ungeeignet..

GCJ:
Kompiliert Java Quell und Bytecode in ausfürhbare binaerdaten ".exe". Untesrtützt Java2 fast vollständig aber alle GUI-Klassen (AWT und SWING) fehlen vollständig. Dafür kann man bei der Anwendungsentwicklung native widgets nutzen, ich entwickle derzeit z.B. mit java-gtk ( http://java-gnome.sourceforge.net ) eine Anwendung. GCJ ist bei einfachen Operationen viel schneller, wenns um Speicherreservierung geht (object anlegen etc.) fällt er aber zurück, da er seinen Speicher immer vom OS anfordert, eine normale Java-VM hat einen eigenen "Pufferbereich", somit kann aus einem Vorrat Speicher reserviert werden, das geht schneller.

[anda_skoa]

Original geschrieben von ceisserer

IBM JDK:
Eine (soweit ich weiß) Eigentwicklung von IBM, die "leichter" ist als jene von Sun oder Blackdown. Ob sie schneller ist, kann man generell nicht sagen. Bei Low-Level-Operationen ist sie schneller wie SUN, beim anlegen von Objekten langsamer.


Der JIT (Just In Time) compiler praktisch aller JVMs kommt von IBM.
Die haben großes Know-How im Bereich Compilerbau.




1. Keine ordentliche Thread-Unterstützung von Linux:
Die Thread-Untestützung von Linux ist echt scheiße. Für jeden Thread wird ein eigener Prozess gestartet, was natürlich viel Overhead schafft. Echt scheiße diese Lösung. Von IBM gibts einen Patch der Linux um "echte" Threads erweitert, die Linux-Entwickler wollen diesen aber anscheinend nicht aufnehmen ;-(


Ein Thread ist nicht ganz ein neuer Prozess.
Er wird zwar ähnlich erzeugt, aber hat nicht alle Strukturen, die ein Prozess hat.
Außerdem muß bein Thread switching nicht soviel gesichert und wiederhergestellt werden, der Adressbereich, etc. belibt ja gleich.

Man muß auf jeden Fall aufpassen, dass man keine JVM mit GreenThreads erwischt.
In der 1.2er Serie waren die JVMs von Sun eben solche.
Da kannst Threading vergessen, da gibt es Deadlocks auch bei sauberen Code.




Hier gäbe es allerdings viele Verbesserungsmöglichkeiten: Z.B. könnte java in ein SDL-Window zeichnen (unter allen plattformen) und würde sich so die Betriebsystemspezifischen Anpassungen sparen. Außerdem nützt SDL auf der platform auf der es kompiliert wurde, die jeweils optimalste beschlueigungsmethode (Windows:DirectX; Linux:DGA).
Aber wie gesagt, anscheinend sind wir Sun mehr oder weniger egal...


Darum benutzt IBM ja SWT als Widget Toolkit. Ist nicht hundertprozentig portable wie AWT, benutzt aber ein Plattformspezfisches Toolkit, unter Linux GTK, wenn ich mich recht erinnere.

(hab das gerade auf http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html gecheckt, GTK ist eine der Optionen)

Ciao,
_

[peschmae]

@ceisserer

nett, das ganze, das ich ziemlich bruchstückhaft schon wusste mal zusammengestellt zu bekommen :)

hab ich das richtig verstanden, dass du (für Leute, die swing benutzen wollen) das IBM jdk empfielst? Ich möchte nämlich zumindest vorläufig mal Swing (oder auch JavaGnome mit GCJ) verwenden, denn SWT, das eigentlich auch noch ganz nett daher kommt, unterstützt ja keine Garbage Collection - d.h. der Overhead ist für nix...

inzwischen habe ich übrigens auch einen LinuxMagazin mit einem "Benchmark" gefunden (allerdings ausm 99)
http://www.linux-magazin.de/Artikel/ausgabe/1999/12/SUNBlocker/sunblocker.html

MFG Peschmä

[peschmae]

wieso unterstützt eigentlich gcj kein awt/swing?

Swing ist doch 100% java, und der gcj compiliert java ...

oder muss da noch irgendein grafiksubsystem programmiert werden?

MFG Peschmä

[peschmae]

I, ich glaub ich kann meine Frage gleich selbst beantworten ;)

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

January 14, 2002 Richard Stallman has changed the licensing of the Classpath AWT implementation to match the licensing of the rest of Classpath. This means that the only remaining barrier to AWT for libgcj is manpower. Work has already begun to merge the Classpath and libgcj AWT implementations.

also ein lizenzproblem...
(und jetzt ein "manpower" - problem)

MFG Peschmä

[Lin728]

Servus!

Die Benchmarks die ich oben erwähnt habe, sind nicht wirklich brauchbar...
In der Realität ist windowsnt in Verbindung mit Sun-JDK etwa um 10-20% langsamer...

Mfg

[peschmae]

ich denke du hast recht...

allerdings hab ich da noch ne frage:
Du schreibst zu GCJ:

Kompiliert Java Quell und Bytecode in ausfürhbare binaerdaten ".exe". Untesrtützt

wie ist das zu verstehen? Heisst das, dass ich damit auch Windows - Binärdateien erstellen kann?

MFG Peschmä

[Lin728]

Hab nur nicht gewusst, ob du weißt, was eine binaerdatei ist, drum hat ich in klammer ".exe" dazugeschrieben, unter linux hat das executable dann natürlich keine endung ;-)

[anda_skoa]

Deshalb schreibt man üblicherweise executable :)

Binär sind auch andere Dateien, Bilder zB.

Außerdem muß ein executable keine Binärdatei sind, ein Shellscript ist ja auch eine executable.

Ciao,
_

[peschmae]

ja wa,

das weiss ich eigentlich schon ;)

aber was is es dann?
ein binäres executable oder so?

MFG Peschmä

[SeeksTheMoon]

nene, Leutz:

das Programm "java" aus dem Sun JDK ist auch ne ausführbare Datei, das die classes verwurstet. Warum also kompliziert so ein unfertiges Teil wie den GCJ oder Kaffee oder sonstwas benutzen, die die Hälfte nicht umsetzen können und wo man bei Sun immer auf dem aktuellsten Stand ist und wo es keine Probleme mit dem Ausführen der Programme gibt. (krasser Satzbau, ich weiß *g*)

Wenn ihr unbedingt executables haben wollt, dann macht doch jar-Files, die laufen auf jedem Rechner, auf dem ein vernünftiges Java läuft...

[Lin728]

Was da rauskommt ist in der tat ein binaeres executable. Also sowas, das du beim kompilieren von C-Code kriegst.

[anda_skoa]

das ist nicht das selbe.
gcj ist Teil der GCC (GNU Compiler Collection)

Er kompiliert Java Source- aber auch Bytecode so wie gcc C Code und g++ C++ Code compilieren, d.h. das Resultat ist ein native executable.

Java besteht ja im wesentlichen aus zwei Teilen.
Der Sprache Java und der Definition einer Abstrakten Maschine.
Diese ist dann meistens in Form einer virtuellen Maschine ausgeführt.

Es spricht jetzt aber nichts dagegen, einen Kompiler zu schreiben, der die Sprache auf eine andere Maschine kompiliert.
Das ist das was gcj macht.

Hat dann weniger Runtime Overhead, weil ja keine zweite Maschine Emuliert werden muß.

Ciao,
_

[SeeksTheMoon]

"komplett" OpenSource ist ja schön und gut, aber solange ich nur 50% der Leistungsfähigkeit einer Sprache benutzen kann, schnappe ich mir lieber das "Original".
Und solange Java nicht von Microsoft kommt, kann man das auch guten Gewissens machen *g*.

Übrigens kann ich den Quellcode vom SDK jederzeit einsehen wenn ich will....(zumindest solange bis Sun den code versiegelt)

[peschmae]

auf was beziehen sich die 50% ?

falls damit gcj gemeint ist halte ich da maln zitat von der gcj - website dagegen:

Most of the APIs specified by "The Java Class Libraries" Second Edition and the "Java 2 Platform supplement" are supported, including collections, networking, reflection, and serialization. AWT is currently unsupported, but work to implement it is in progress.

Was weitgehend auch meinen Erfahrungen entspricht...

Im übrigen ist gcj _nicht_ kompilizert zu bedienen, fast genau gleich wie der normale gcc/g++, nur das es da noch ein paar zusatzschalter gibt

Im übrigen macht die Sache durchaus Sinn, ist doch eine bessere Performance bei einem nativen Compiler durchaus wahrscheinlich. Zumindest die Startzeit ist erheblich kürzer! (Der Rest ist schwer zu beurteilen)

MFG Peschmä

[Lin728]

Und den Quellcode von Sun kannst du nicht einsehen, was du siehst, wenn du das src.zip aufmachst, ist bloß der Sourcecode der Klassen, nicht aber der Vm.
Aber darum gehts den GNU-Leuten ja nicht, sondern eher um Lizenzfragen.

[SeeksTheMoon]

mit 50% meinte ich AWT, SWING, J2EE, J2ME.
Vielleicht stimmt 50% nicht (zum guten oder schlechten), auf jeden Fall fehlen die oben genannten Dinge.
Lassen wir das mal nicht in einem Flamewar ausarten.

Wenn GPL mit Java nicht 100% kompatibel ist, welche Lizenz passt dann am besten?

[Lin728]

Soweit ich weiß, kann GCJ nun AWT. SWING-Support ist noch ausständig, J2EE und J2ME unterstützt eine normale Java-JM die du auf deinem Computer hast aber auch nicht.

[peschmae]

ok, kein flamewar

aber ich mags einfach nicht, wenn man gute freie softwareprojekte so heruntermacht, denn wenn gcj mal fertig ist (mit swing und allem schnickschnack) und auch einige optimierungen vorgenommen werden, dann ist dies sicher eine Super sache - java programme in C++ - tempo (ok. das ist auch variabel), und für die anderen Plattformen nur ne olle, lahme JVM...

MFG Peschmä