JAVA schneller wie C++ ? Stimmt das??? [Archiv]

Neomi

2006-06-09, 20:59:14

C++ wird nicht ausgeführt, sondern vom Compiler (und Linker) in ausführbaren nativen Code umgewandelt. Wie schnell das Ergebnis letztendlich ist, hängt vom Compiler und dessen Optimierungen ab.

Kein von einer virtuellen Maschine interpretierter Code kann jemals so schnell sein, wie vollständig optimierter nativer Code. Die virtuelle Maschine ist nur ein Zwischenlayer und basiert ebenfalls auf nativem Code. Und es ist absolut unmöglich, daß ein Zwischenlayer weniger als gar keine Rechenzeit benötigt.

noid

2006-06-09, 21:00:22

ich kenne zwar den Test nicht, aber wenn die wirklich call-by-value gegen call-by-ref gebenchet haben, dann ist das ziemlich arm.

PS: reine Themen-Foren sind enorm arm...

Gast

2006-06-09, 21:02:50

loooooool, wenn man in dem Benchmark bei c++ call-by-ref macht, wird das c++ doppelt so schnell :D

Kabelsalat

2006-06-09, 21:16:48

Basiert die JVM auch in den neuesten Versionen rein auf einem Interpreter, oder wird ein Konzept ähnlich des Runtime-Compilers aus .Net verwendet: Der Code wird zur Laufzeit kompiliert und zwar nicht am Stück sondern lediglich Abschnittsweise. Das Ergebnis wird dann jedoch gecached und muss nicht abermals in nativen Code umgewandelt werden, somit kann .Net-Code durchaus schneller sein als mit C++ geschriebener Code (wenn man davon ausgeht, dass das Framework aus den dort implementierten Funktionen das Optimum herausholt, was der "Otto-Normal"-C++ Programmierer bei seiner eigenen Implementierung jedoch nicht immer schafft, wird das in der Realität sogar desöfteren zutreffen).

HellHorse

2006-06-09, 21:18:37

Neomi[/POST]']
Kein von einer virtuellen Maschine interpretierter Code kann jemals so schnell sein, wie vollständig optimierter nativer Code. Die virtuelle Maschine ist nur ein Zwischenlayer und basiert ebenfalls auf nativem Code. Und es ist absolut unmöglich, daß ein Zwischenlayer weniger als gar keine Rechenzeit benötigt.
Ja und? Java wird ja nicht interpretiert. Bei ScanEgale ist die Echtzeit Java Implementation ja doppelt so schnell wie die Referenzimplementation von Boeing in C++. Das sind grosse Anwendungen mit um die 300k LOC. Von dem her ist es sicher möglich dass realworld Java Code schneller ist als C++ Equivalente. Dass das Umgekehrte auch gelten kann versteht sich von selbst. Java ist sicher nie so schnell wie handgetuntes C++. Bloss ist halt die Frage ob man die Resourcen (Zeit, Leute) und Notwendigkeit hat derart zu optimieren.

Und es heisst schneller ALS.

Und die ganze Diskussion ist echt AAAAAAALT

Neomi

2006-06-09, 21:35:29

Dann wird Java eben auch compiliert, aber für einen Just-in-Time-Compiler gilt genau das gleiche. Letztendlich hängt die erreichbare Performance alleine vom Code ab und nicht von der Sprache, in der er geschrieben wird.

Ein herkömmlicher Compiler (also einer, der einmal nativen Code ausspuckt), muß evtl. für viele leicht unterschiedliche Prozessoren handhabbaren Code erzeugen, das ist sein Nachteil. Der Vorteil dagegen ist, daß er nahezu beliebig viel Zeit und Ressourcen in aggressive Optimierungen stecken kann und daher kein Potential verschenken muß. Ist der Code gut geschrieben und die einzelne Zielmaschine bekannt, ist sehr viel möglich.

Ein Just-in-Time-Compiler hat nicht beliebig Zeit, sondern muß recht zügig was ausführbares ausspucken, das ist sein Nachteil. Hier ist der Vorteil natürlich, daß er keine Kompromisse für verschiedene Maschinen eingehen muß, sondern nur für jeweils eine einzelne bekannte Maschine. Außerdem kann er nativen Code durch schnelleren nativen Code ersetzen, wenn er z.B. merkt, daß bestimmte Abfragen mit hoher Wahrscheinlichkeit immer dieses oder jenes Ergebnis liefern.

Letztendlich kann man nicht die Performance von Sprachen vergleichen, sondern nur die Performance von unterschiedlichen Programmen, die grob das gleiche tun, aber mit unterschiedlichen Compilern und Libraries erstellt wurden.

Gast

2006-06-09, 21:40:25

Vielleicht ist das der Grund, warum die gängigen Betriebssysteme alle so langsam sind. Schließlich sind die, sowie nahezu alle dazugehörigen Treiber ja in C/C++ geschrieben. Die hätten mal Java nehmen sollen.

medi

2006-06-09, 21:59:58

Gast[/POST]']Vielleicht ist das der Grund, warum die gängigen Betriebssysteme alle so langsam sind. Schließlich sind die, sowie nahezu alle dazugehörigen Treiber ja in C/C++ geschrieben. Die hätten mal Java nehmen sollen.

und worauf läuft dann die java-runtime? :|

Coda

2006-06-09, 22:13:56

Das Thema hat nen Bart und den Fronten die wirklich darüber Flamewars führen kann man eh nicht helfen. The right tool for the job ist die Devise.

Monger

2006-06-09, 22:39:01

Zu dem Thema gibt es eine Meinung, und an die glaube ich:

Alles was Entwicklungszeit spart, macht das Programm auch zur Laufzeit schneller. Denn die Implementierung von vernünftigen Algorithmen steigern die Performance mehr als es jeder Compiler könnte.

Insofern: ja, für jedes Problem das richtige Tool. Wenn man damit schnell und effektiv zum Ziel kommt, darf die Sprache auch QBasic heißen.

Coda

2006-06-09, 23:01:18

Monger[/POST]']Alles was Entwicklungszeit spart, macht das Programm auch zur Laufzeit schneller.
Oder es verkürzt einfach nur die Entwicklungszeit. Was bei einem komerziellen Unternehmen eher der Fall sein dürfte ;)

Monger

2006-06-10, 00:07:40

Coda[/POST]']Oder es verkürzt einfach nur die Entwicklungszeit. Was bei einem komerziellen Unternehmen eher der Fall sein dürfte ;)

Damit triffst du zielsicher in eine offene Wunde! :D

Meistens ist es doch so: das Release Datum steht, und dann wird die Software verkauft - egal was nun daran funktioniert oder nicht. Wenn die Entwicklung erwartungsgemäß vorwärts kommt, gibt es wenigstens eine kleine Chance, dass auch das meiste implementiert wird. Performance und Usability kommen dann GANZ zuletzt, aber darüber will ich jetzt gar nicht nachdenken...

Coda

2006-06-10, 00:18:56

Wobei ich mal anmerken möchte, dass GUI-Entwicklung mit C++/Qt meiner Meinung nach sogar schneller gehen kann als mit Java.

Ach btw: "Java schneller als C++" bitte ;)

urbi

2006-06-10, 00:44:10

Hat wenig mit Programmieren zu tun, aber: Ich finde Programme die auf Java setzten generell doof. Es fühlt sich immer so "schwammig" an und mich nervt das JRE was sich immer in der Systray einnistet. Aber ich persönlich mag auch kein Flash, scheine also total unkewl zu sein.

Monger

2006-06-10, 00:57:36

Coda[/POST]']Wobei ich mal anmerken möchte, dass GUI-Entwicklung mit C++/Qt meiner Meinung nach sogar schneller gehen kann als mit Java.

Kunststück. Das was ich bis jetzt da gesehen habe (AWT, Swing) war auch selten scheiße. Das kommt halt daher weil man sich um jeden Preis plattformunabhängig machen wollte, und damit das Rad nochmal neu erfunden hat, statt das zu nehmen was einem das jeweilige Betriebssystem anbietet.

Ich hab bis heute kein Tool gefunden, mit dem man mit ein paar Klicks sich sein Swing Fenster zusammenbasteln könnte. Zumindest keins, was auf ergänzenden Code sauber reagieren würde. Stattdessen muss man megaumständlich mit irgendwelchen Layoutmanagern rumfrickeln, damit das Fenster ja auf jedem Betriebssystem und unter jeder Auflösung immer genauso reagiert...

In Sachen GUI ist Java GANZ schwach.

Coda

2006-06-10, 01:10:08

Eben. Ich mach die ganze Zeit Zeug mit Qt auf Arbeit und das is mir 100x lieber als Java ;)

Ich schieß mir mit C++ auch wirklich nur noch seltenst in den Fuß. Was mir manchmal passiert sind Pointer auf einen std::vector den ich dann verlängere und dadurch die Pointer ungültig werden weil er sich im Speicher verschiebt durch den realloc. Das ist mies zu debuggen, weil das Ding sich ja nicht gleich verschiebt.

del_4901

2006-06-10, 01:18:46

Coda[/POST]']Eben. Ich mach die ganze Zeit Zeug mit Qt auf Arbeit und das is mir 100x lieber als Java ;)

Ich schieß mir mit C++ auch wirklich nur noch seltenst in den Fuß. Was mir manchmal passiert sind Pointer auf einen std::vector den ich dann verlängere und dadurch die Pointer ungültig werden weil er sich im Speicher verschiebt durch den realloc. Das ist mies zu debuggen, weil das Ding sich ja nicht gleich verschiebt.
Hahaha ... ich arbeite eh fast "ausschließlich" mit heterogenen Containern ... da kann ich mir die Zeiger hohlen. Ok, dafür vergess ich mal nen new. ^^
Früher hab ich mir mal gern Zeiger von Lokalen Variablen geholt ... wenn da darüber nachdenke wie dämlich das ist, wird mir schlecht ... und ich muss mich mit dem Gesicht zur Wand in die Ecke stellen.

Kabelsalat

2006-06-10, 01:20:41

Jepp, GUI und Java ist wahrlich doof... aber man macht ja nicht umsonst Webanwendungen^^ Der Gerüchteküche soll sich in Punkto GUI und Java demnächst aber etwas ändern... alles wird gut Jungs. Und falls nicht - es gibt immernoch .Net und Windows Forms.

Coda

2006-06-10, 01:32:54

AlphaTier[/POST]']Hahaha ... ich arbeite eh fast "ausschließlich" mit heterogenen Containern.
Wasn das jetzt fürn Quatsch? Du kannst ein dynamisch erweiterbares Array nicht sinnvoll durch etwas anderes ersetzen. Nimmst halt Offsets statt Pointer und gut is. Muss man sich nur hinter die Ohren schreiben.

Kabelsalat[/POST]']Und falls nicht - es gibt immernoch .Net und Windows Forms.
Das ist gegen Qt auch grauenhaft. Wenn sich etwas tut dann mit WinFX.

del_4901

2006-06-10, 01:40:18

Coda[/POST]']Wasn das jetzt fürn Quatsch? Du kannst ein dynamisch erweiterbares Array nicht sinnvoll durch etwas anderes ersetzen. Nimmst halt Offsets statt Pointer und gut is. Muss man sich nur hinter die Ohren schreiben.

Das ist doch dynamisch erweiterbar, nur anstatt der Objekte speichert man die Zeiger, es hat auch seine Vor und nachteile ... Vorteil man kann "mischen" ... Nachteil es ist etwas langsamer. Aber da ich eh meißens Oberklassenzeiger für meine Unterklassen speicher, komm ich nicht umrum, das so zu machen, sonnst gibs slicing ... ok, man könnte auch über eine Union arbeiten, aber das ist IMHO gaanz schlechter stil.

Wobei ich jetzt mal überlegen muss was ist schneller die offsets ausrechnen, oder die Dereferenzierung? Kommt sicherlich drauf an, wie oft man das macht.

Coda

2006-06-10, 02:09:47

AlphaTier[/POST]']Das ist doch dynamisch erweiterbar, nur anstatt der Objekte speichert man die Zeiger
Jetzt weiß ich auf was du hinaus willst. Sorry, aber so exzessiv new zu verwenden mag ich gar nicht. Weißt du wie lahm das sein kann?

Ich hab den absoluten Schlag was Performance angeht. Ich häng mich vorher auf bevor ich irgendwo ne Optimierung auslass die mir durch den Kopf geht (natürlich nur wenn es die Codequalität bzw. Wartbarkeit nicht signifikant einschränkt).

AlphaTier[/POST]']Wobei ich jetzt mal überlegen muss was ist schneller die offsets ausrechnen, oder die Dereferenzierung? Kommt sicherlich drauf an, wie oft man das macht.
Das ist auf x86 exakt gleich um genau zu sein. Sogar Base+Offset*(2^n) mit n<=3 ist immer umsonst ;)

del_4901

2006-06-10, 02:14:20

Coda[/POST]']Jetzt weiß ich auf was du hinaus willst. Sorry, aber so exzessiv new zu verwenden mag ich gar nicht. Weißt du wie lahm das sein kann?

Ich hab den absoluten Schlag was Performance angeht. Ich häng mich vorher auf bevor ich irgendwo ne Optimierung auslass die mir durch den Kopf geht (natürlich nur wenn es die Codequalität bzw. Wartbarkeit nicht signifikant einschränkt).

Das ist auf x86 exakt gleich um genau zu sein ;)

hihihi, jo du hast schon recht ... du kannst ja dir eine eigene kleine Speicherverwaltung bauen, für Objekte die alle die gleiche Größe haben, und die du viel umherschiebst ... dann überlädst du dir den new Operator und jut ist. ... Aber bitte nicht den globalen new Operator überschreiben... das suckt. Ich kann dir nächste Woche da was in die Hand geben wenn du willst ... muss nur mein altes Linux Image wieder zum laufen bekommen ... und hoffen das es noch da ist wo ich vermute.

Coda

2006-06-10, 02:15:09

Man kann auch mit Kanonen auf Spatzen schießen...

del_4901

2006-06-10, 02:19:13

Coda[/POST]']Man kann auch mit Kanonen auf Spatzen schießen...
du kannst auch einfach dir das löschen spaaren und einfach alten Speicherplatz wiederverwenden. Must du dir halt nen Flag anlegen.

Aber das mit der eigenen kleinen Speicherverwaltung ist gar nicht so dumm ... das Funtioniert aber nur bei gleich großen Objekten, sonnst macht es keinen Sinn. Das hab ich aus BS2 mitgenommen ^^.

Und so schwer ist das wirklich nicht ... die Freispeicherliste ist sehr einfach zu implementieren ... nimmste schoen First Fit ... verschmelzen musste auch nicht alles super ^^

Abnaxos

2006-06-10, 03:41:49

Neomi[/POST]']Kein von einer virtuellen Maschine interpretierter Code kann jemals so schnell sein, wie vollständig optimierter nativer Code.
Das ist nicht wahr und dass es nicht wahr ist, ist heute sowohl empirisch als auch experimentell bewiesen.

Der Punkt ist der: Ein statischer Compiler hat viel zu wenige Informationen, um so effizient optimieren zu können, wie es ein dynamischer Compiler wie Hotspot kann. Zwei kleine Beispiele: Ein statischer Compiler hat ausser sehr groben (wie z.B. was ungefähr für eine CPU zum Einsatz kommt) keinerlei Informationen über die Zielplattform, während ein dynamischer Compiler die Zielplattform exakt kennt. Ein statischer Compiler hat keinerlei Informationen über das Laufzeit-Verhalten des Programms, er kann nur aufgrund von Heuristiken optimieren. Ein dynamischer Compiler kann das Programm beobachten und dann so optimieren, wie es das Programm erfordert. Da gibt es noch mehr derartige Faktoren.

Ob Java das alles perfekt umsetzt, steht auf einem anderen Blatt und diese Diskussion ist müssig. Aber, um das nochmal zu wiederholen, die zitierte Aussage ist mehrfach widerlegt und man weiss heute, dass virtuelle Maschinen grundsätzlich schneller sein können als die statischen Gebilde. Experimentell untermauert wurde das durch HP, die Maschinen-Code native auf eine CPU losgelassen haben, und dann den identischen Code mit einer VM à la Hotspot ausgeführt haben -- die VM war schneller, u.A. aus den oben genannten Gründen.

HellHorse

2006-06-10, 08:52:17

Neomi[/POST]']
Ein herkömmlicher Compiler (also einer, der einmal nativen Code ausspuckt), muß evtl. für viele leicht unterschiedliche Prozessoren handhabbaren Code erzeugen, das ist sein Nachteil. Der Vorteil dagegen ist, daß er nahezu beliebig viel Zeit und Ressourcen in aggressive Optimierungen stecken kann und daher kein Potential verschenken muß. Ist der Code gut geschrieben und die einzelne Zielmaschine bekannt, ist sehr viel möglich.
Ja, in der Theorie schon. In der Praxis produziert ein herkömmlicher Compiler eben nicht optimalen Code, was am ganz schön daran sieht, dass Compiler mit neuen Versionen schnelleren Code erzeugen (ausser GCC, da produzieren neuere Versionen auch schon mal langsameren Code). Und falls man alle Optimierungen abschaltet (was doch erstaunlich häufig geschen soll, gerade auch bei Games) dann nutzen die selbstverständlich nichts.

Dass von Hand optimierter Code + normaler Compiler nicht zu schlagen versteht sich. Bloss wird halt nur selten von Hand optimiert.
Neomi[/POST]']
Ein Just-in-Time-Compiler hat nicht beliebig Zeit, sondern muß recht zügig was ausführbares ausspucken, das ist sein Nachteil. Hier ist der Vorteil natürlich, daß er keine Kompromisse für verschiedene Maschinen eingehen muß, sondern nur für jeweils eine einzelne bekannte Maschine. Außerdem kann er nativen Code durch schnelleren nativen Code ersetzen, wenn er z.B. merkt, daß bestimmte Abfragen mit hoher Wahrscheinlichkeit immer dieses oder jenes Ergebnis liefern.
Dafür hat ein JIT Laufzeitinformationen, die ein normaler Compiler nicht hat. Er kann z.B. virtuals inlinen wenn keine Klasse geladen ist, die die Methode überschreibt oder ein switch so umordnen dass der zu Laufzeit häufigste Fall zuerst kommt oder abs ohne branch mit SSE implentieren.

Das ist ein theoretisches Argument genauso wie deines für den traditionellen Compiler. Und ja, gerade die Client JVM ist weit davon entfernt optimalen Code zu erzeugen. Das Ziel ist dort ja auch nur so schnell wie möglich irgendwelchen nativen Code zu auszuspucken. Denn egal wie doof der ist, er wird auf jeden Fall schneller sein als Interpretation.
Neomi[/POST]']
Letztendlich kann man nicht die Performance von Sprachen vergleichen, sondern nur die Performance von unterschiedlichen Programmen, die grob das gleiche tun, aber mit unterschiedlichen Compilern und Libraries erstellt wurden.
Jepp.

Stone2001

2006-06-10, 11:01:15

Wei schlecht heutige Compiler manchmal sind, hat man ja am letzten (OpenMP-) Compiler-Vergleich der c't gesehen. Der handgeschriebene Code war um Faktor 10 schneller. ;)

Coda[/POST]']Das Thema hat nen Bart und den Fronten die wirklich darüber Flamewars führen kann man eh nicht helfen. The right tool for the job ist die Devise.
Das stimmt!

ScottManDeath

2006-06-10, 11:47:05

VC 8 hat profile guided optimization, mit der man die Ergebnisse eines "repräsentativen" Testlaufs mit in die Optimierung einbauen kann. Hab allerdings keine Ahnung wie sich das in der Praxis auswirkt.

Ich denke dass eine gute Mischung aus offline und online Optimierung das Beste ist; man kann teure Dinge offline machen, die man nicht online machen will.

Neomi

2006-06-10, 14:37:21

Abnaxos[/POST]']Das ist nicht wahr und dass es nicht wahr ist, ist heute sowohl empirisch als auch experimentell bewiesen.

Der Punkt ist der: Ein statischer Compiler hat viel zu wenige Informationen, um so effizient optimieren zu können, wie es ein dynamischer Compiler wie Hotspot kann. Zwei kleine Beispiele: Ein statischer Compiler hat ausser sehr groben (wie z.B. was ungefähr für eine CPU zum Einsatz kommt) keinerlei Informationen über die Zielplattform, während ein dynamischer Compiler die Zielplattform exakt kennt. Ein statischer Compiler hat keinerlei Informationen über das Laufzeit-Verhalten des Programms, er kann nur aufgrund von Heuristiken optimieren. Ein dynamischer Compiler kann das Programm beobachten und dann so optimieren, wie es das Programm erfordert. Da gibt es noch mehr derartige Faktoren.

Deshalb habe ich ja von vollständig optimiertem Code gesprochen, nicht von halbwegs optimiertem. Was spricht denn dagegen, statisch auf exakt ein System hin zu optimieren? Und was die Informationen über das Laufzeitverhalten angeht: dafür gibt es Profiler. Man kann vereinfacht gesagt das Laufzeitverhalten zur Laufzeit analysieren lassen und dann das Ergebnis in einem finalen Build berücksichtigen lassen.

Es ist durchaus möglich, mit einem statischen Compiler Code zu erzeugen, den man für eine gegebene Maschine mit keinem anderen System schneller hinbekommt. Daß das in der Regel nicht gemacht wird, ist mir klar, und was anderes behauptet habe ich da auch nicht.

Edit:
Ich sollte vielleicht noch erwähnen, daß es mir um die theoretisch erreichbaren Sachen geht, nicht um spezielle tatsächlich vorhandene Compiler. Ich bin z.B. mit den Optimierungen von VC++ 2005 noch nicht zufrieden, beim Blick in das Assemblat bin ich teilweise schon richtig schockiert. Nur berücksichtige ich dann, daß man das mit einem zukünftigen Compiler noch besser machen kann, also statische Compiler allgemein da noch nicht ihre Grenze haben.

Abnaxos

2006-06-10, 15:22:28

Neomi[/POST]']Deshalb habe ich ja von vollständig optimiertem Code gesprochen, nicht von halbwegs optimiertem.
Also das, was HotSpot und andere VMs (theoretisch) erzeugen ...

Neomi[/POST]']Was spricht denn dagegen, statisch auf exakt ein System hin zu optimieren?
Theoretisch nichts, in der Praxis ist aber z.B. Gentoo, mit dem genau das ja möglich wäre, wenn die passenden Compiler existieren würden, schon etwas mühsam -- eine Nacht für ein Upgrade von OOo ... nein danke, ohne mich. ;) Aus Mangel an entsprechenden Compilern ist der Preis eben IMHO viel zu hoch für den relativen geringen (wenn überhaupt) Performance-Gewinn.

Neomi[/POST]']Und was die Informationen über das Laufzeitverhalten angeht: dafür gibt es Profiler. Man kann vereinfacht gesagt das Laufzeitverhalten zur Laufzeit analysieren lassen und dann das Ergebnis in einem finalen Build berücksichtigen lassen.
OK, Punkt für dich. Ich habe sogar etwas im Hinterkopf, dass gcc ein experimentelles Flag -Os besitzt, das in diese Richtung zielt.

Aber auch hier fände ich es interessanter, wenn HotSpot damit beginnen würde, seine Erkenntnisse zu cachen, um damit die "Warmlaufzeit" von Java-Applikationen mit der Zeit immer mehr zu minimieren.

Gast

2006-06-10, 15:29:36

Ich progge jedes Java-Programm mit C++ an die Wand.

Trap

2006-06-10, 16:07:41

Reale Compiler, sowohl JIT als auch ahead-of-time, sind alle soweit von einem idealen Compiler entfernt, dass die Unterschiede zwischen den idealen Compilern völlig belanglos sind. Im Moment erzeugen ahead-of-time Compiler in den meisten Fällen schnelleren Code.

Außerdem:
Kein Compiler kann den schnellstmöglichen Code für jede Eingabe erzeugen, wer in Berechenbarkeitstheorie aufgepasst hat kann das einfach beweisen.

Xmas

2006-06-10, 17:19:02

Es gibt mit Sicherheit einige Fälle bei denen ein aktueller Java-Compiler + VM bei gleichem Programmieraufwand schnelleren Code erzeugt als ein aktueller C++-Compiler.
Dann kommt es drauf an ob man die Zeit und Lust hat, richtig zu optimieren.

LordDeath

2006-06-10, 17:36:04

stimmt es, dass der intel c++ compiler spürbar schnelleren code erzeugt als andere windows compiler? aber dafür werden die binaries viel größer...

Trap

2006-06-10, 17:45:24

LordDeath[/POST]']stimmt es, dass der intel c++ compiler spürbar schnelleren code erzeugt als andere windows compiler? aber dafür werden die binaries viel größer...
Das braucht man nicht fragen, kann man entweder nachgoogeln oder selbst ausprobieren.

LordDeath

2006-06-10, 17:50:53

Trap[/POST]']Das braucht man nicht fragen, kann man entweder nachgoogeln oder selbst ausprobieren.

wenn ich nicht zu fragen brauche, brauchst du auch nicht antworten!!

Trap

2006-06-10, 17:55:34

LordDeath[/POST]']wenn ich nicht zu fragen brauche, brauchst du auch nicht antworten!!
Ich antworte auch nicht, ich geb blöde Kommentare :tongue:

LordDeath

2006-06-10, 18:00:25

Trap[/POST]']Ich antworte auch nicht, ich geb blöde Kommentare :tongue: :uup:

Darkstar

2006-06-11, 11:44:29

medi[/POST]']und worauf läuft dann die java-runtime? :|
Zum Beispiel innerhalb von JNode (http://www.jnode.org/). ;)

Monger[/POST]']Ich hab bis heute kein Tool gefunden, mit dem man mit ein paar Klicks sich sein Swing Fenster zusammenbasteln könnte. Zumindest keins, was auf ergänzenden Code sauber reagieren würde. Stattdessen muss man megaumständlich mit irgendwelchen Layoutmanagern rumfrickeln, damit das Fenster ja auf jedem Betriebssystem und unter jeder Auflösung immer genauso reagiert...
Trifft das auch auf Matisse (http://form.netbeans.org/) zu?

Senior Sanchez

2006-06-11, 21:38:52

Auch jetzt mal auf die Gefahr hin völlig unkewl zu wirken und ohne Qt oder Windows.Forms genau zu kennen: Ich mag Swing :)

Im Grunde ist es eigentlich mehr ne Hassliebe. Es gibt Zeiten, da hasse ich Swing, weil es manchmal echt inkonsequent ist und manchmal bullshit baut, den ich gar nicht leiden kann (man mag sich hier vllt an bestimmte Threads erinnern ;) ).

Andererseits gibts auch Zeiten, wo ich es echt erstaunlich finde, wie mächtig Swing doch eigentlich ist und wie gut es doch an vielen Stellen designed wurde.

@Gast der Java-Apps schwammig fand

Das Aussehen, die Performance und vieles andere von Swing-Apps steigen oder fallen mit dem Können vom Programmierer. Es gibt da sonen Typen (mir fällt atm nicht der Name ein), aber der hat das oftgelobte Eclipse-L&F welches auf SWT basiert mit Swing nachgebaut..... und du siehst keinen Unterschied! Oder auch den Win XP Anmeldescreen.

@monger

Ich habe früher öfter den JBuilder benutzt und war damit eigentlich recht zufrieden. Auf Arbeit musste ich dann mit Eclipse arbeiten und habe da mal den GUI Builder ausprobiert und der war gelinde gesagt absolute Scheiße.
Ich bin jetzt dazu übergegangen den GUI-Code vollständig per Hand zu schreiben und im Grunde ist die Entwicklungszeit so maximal genauso lang wie beim GUI-Builder, wenn nicht sogar manchmal schneller. Es ist ne Sache des Trainings, aber mit der Zeit kann man genau wie die Layout-Manager "denken" und die GUI schreibt sich dann fast von alleine.

BTW, ich weiß gar nich warum due so auf die Layout-Manager fluchst. Haste mal mit Delphi GUIs gebaut? Die passt sich nämlich nicht unterschiedlichen Auflösungen an etc. und das ist irgendwie scheiße *g*

Ganon

2006-06-11, 22:23:17

Senior Sanchez[/POST]']Haste mal mit Delphi GUIs gebaut? Die passt sich nämlich nicht unterschiedlichen Auflösungen an etc. und das ist irgendwie scheiße *g*

Dann bau mal mit dem Cocoa InterfaceBuilder GUIs. Da ekelst du dich danach über GUI-Hand-Coding. ;)

Ich glaube der Qt Designer kann's ähnlich wie der IB. ;)

Monger

2006-06-11, 23:18:52

Senior Sanchez[/POST]']
@monger

Ich habe früher öfter den JBuilder benutzt und war damit eigentlich recht zufrieden. Auf Arbeit musste ich dann mit Eclipse arbeiten und habe da mal den GUI Builder ausprobiert und der war gelinde gesagt absolute Scheiße.

Genau das ist mein Problem! :D
Wobei ich Java ausschließlich zum Privatvergnügen mache.
Ich hab mich jetzt halt sehr auf Eclipse eingeschossen.

Ich bin jetzt dazu übergegangen den GUI-Code vollständig per Hand zu schreiben und im Grunde ist die Entwicklungszeit so maximal genauso lang wie beim GUI-Builder, wenn nicht sogar manchmal schneller. Es ist ne Sache des Trainings, aber mit der Zeit kann man genau wie die Layout-Manager "denken" und die GUI schreibt sich dann fast von alleine.

Ich hab zwar vorher mal reingeschaut, aber so richtig reingekniet habe ich mich in die Layout Manager erst vor ein paar Tagen. Mit der Zeit geht es tatsächlich flotter von der Hand, wenn man erstmal die einzelnen Layoutmanager grob kennt.
Trotzdem ist es noch ein Gefrickel. Das pure Layout frisst fast genauso viele Zeilen wie der Rest der GUI, z.B. die ganzen Listener. Gemessen an dem was man bekommt, ist der Aufwand unbefriedigend hoch.

Senior Sanchez

2006-06-11, 23:29:15

Ganon[/POST]']Dann bau mal mit dem Cocoa InterfaceBuilder GUIs. Da ekelst du dich danach über GUI-Hand-Coding. ;)

Ich glaube der Qt Designer kann's ähnlich wie der IB. ;)

Von Apple erwarte ich nix anderes :D

Spaß beiseite, was macht ihn so toll? Was hat er so für features? Screenshots?

@monger

Joar, wenn dich das so nervt, dann schau dir mal das FormsLayout an. Ich selber habe mich noch nicht so reingefuchst und streube mich atm noch dagegen, aber es nimmt wirklich ne Menge Arbeit ab und macht den Code kürzer.

Ganon

2006-06-11, 23:41:51

Senior Sanchez[/POST]']Spaß beiseite, was macht ihn so toll? Was hat er so für features? Screenshots?

Hmm... finde gerade nichts "zum Zeigen", außer vielleicht hier CoreData-Videos-Tutorials:

http://developer.apple.com/cocoa/coredatatutorial/

Die Einteilung der Videos ist etwas lästig. Zu Video 13: Er hätte auch einfach "now()" im Defaul-Value vom DataModel eingeben zu brauchen. ;)

Ich kann morgen aber gerne meinen Desktop abfilmen, wenn gewünscht, und mal kurz was zeigen. ^^

Senior Sanchez

2006-06-12, 00:09:09

Ganon[/POST]']Hmm... finde gerade nichts "zum Zeigen", außer vielleicht hier CoreData-Videos-Tutorials:

http://developer.apple.com/cocoa/coredatatutorial/

Die Einteilung der Videos ist etwas lästig. Zu Video 13: Er hätte auch einfach "now()" im Defaul-Value vom DataModel eingeben zu brauchen. ;)

Ich kann morgen aber gerne meinen Desktop abfilmen, wenn gewünscht, und mal kurz was zeigen. ^^

das wäre natürlich richtig klasse, wenn de das machen könntest.

Aber bitte nen anständiges Video-Format ;)

Ganon

2006-06-12, 19:21:36

Welches ist anständig? ;) Hab jetzt Standard H.264. Kann es aber bei bedarf auch Konvertieren:

http://www.mhami.de/IB.mov

Ist leider nur ein Shareware-Tool zum Aufnehmen, daher dieser Schriftzug. Ich versuch noch die Qualität etwas anzuheben. ;)

Das der Mauszeiger etwas hinterherhinkt, liegt am Programm. Keine Ahnung warum, aber ich denke man sieht soweit alles.

Monger

2006-06-12, 19:32:49

Ganon[/POST]']Welches ist anständig? ;) Hab jetzt Standard H.264. Kann es aber bei bedarf auch Konvertieren:

http://www.mhami.de/IB.mov

Ist leider nur ein Shareware-Tool zum Aufnehmen, daher dieser Schriftzug. Ich versuch noch die Qualität etwas anzuheben. ;)

Das der Mauszeiger etwas hinterherhinkt, liegt am Programm. Keine Ahnung warum, aber ich denke man sieht soweit alles.

Jepp, das sieht schon VIEL besser aus als dieses dumme Eclipse Plugin! :D

Alleine wie man den "Glue" für bestimmte Achsen der Komponenten setzen kann, gefällt mir sehr gut. Genau so sollte es sein.