Java Vor-/Nachteile (was: Java-Source kompilieren)

[derMani]

Java erinnert mich irgendwie immer an Halbautomatik : Interpretiert und langsam, aber trotzdem kompilieren müssen und noch nicht mal weniger Code schreiben müssen als in C++ (was ja sonst der große Vorteil von interpretierten (Skript-)Sprachen ist). Und dazu (zumindest bislang) sogar noch proprietär.
Keine Ahnung, warum Leute sowas benutzen :roll:.

Viele Grüße

Java wird schon seit langer Zeit nicht mehr interpretiert, sondern von der ExecutionEngine Just in Time kompilliert. Leider scheint das an den meisten vorbeigegangen zu sein. Die Ausführungszeit ist über die Jahre hinweg deutlich besser geworden und ist sogar mit c++ vergleichbar (wenn zumindest keine GUI-Elemente ins Spiel kommen).

http://www.freewebs.com/godaves/javabench_revisited/

Java ist eben keine Skriptsprache, sondern eine vollwertige Programmiersprache. Das "kompillieren" ist doch kein Nachteil, wenn die Java-Sourcen in ein unabhängigse class-Format gespeichert wissen. Hier hilft es, wenn man grob die Funktionsweise der virtuellen Maschine (JVM) versteht. Durch die kompillierte Datei ist eine Umsetzung des Bytecode auf systembedingten assemblycode performant möglich. Zur Arbeitsweise der JVM kann ich folgendes Buch empfehlen
Wer sich mehr mit Java beschäftigt wird auch den Vorteil des reibungslosen Updaten (on the fly) von Class-Dateien schätzen.

http://java.sun.com/docs/books/jvms/

Übrigens bietet die "geschützte" Java-Umgebung (in der JVM) zusätzliche Sicherheit bei der Ausführung von Programmen.
Es sind halt die vielen kleineren Dinge, die die Sprache so elegant machen.

Das proprietäre Argument kann ich nicht vollständig nachvollziehen. Zwar gibt es mit gcc einen freinen C-Compiler, aber gängige andere Compiler anderer Firmen sind auch nicht in den Quellen frei und werden oft für Softwareentwicklungen eingesetzt. Dem eigentlichen Entwickler kann es doch größtenteils sowieso egal sein, er entwickelt in der Regel seine Software mit einer Sprache und nicht für eine Sprache.
Die Spezifikationen der JVM waren übrigens schon immer frei, das sieht man an den vielen frei verfügbaren Implementierungen einer JAVA VM. Nur die offizielle SUN-Java-Version war bis vor kurzem noch nicht vollständig frei verfügbar. Dank IcedTea ist das openJDK jetzt vollständig frei.

Mehr infos zum freien Java:

http://openjdk.java.net/

Keine Ahnung, warum Leute sowas benutzen .

Weil die Sprache unheimlich flexibel ist, weil es so viele hochqualitative frei verfügbare APIs gibt. Weil mit JAVAEE hervorragend betriebliche Informationssysteme geschaffen werden können.

 

[bike]

Weil die Sprache unheimlich flexibel ist, weil es so viele hochqualitative frei verfügbare APIs gibt. Weil mit JAVAEE hervorragend betriebliche Informationssysteme geschaffen werden können.

Weil es immer leichter wird irgendein Tool zu schreiben, dass keiner braucht und das den Entwicklern für die Parxis sprich den Kunden das Leben erschwert.

Heutezutage ist es leider sehr einfach z.B. mit java ein Tool oder Applikation zu schreiben, dadurch wird nach meiner Erfahrung vermieden zuerst einmal nachzudenekn und dann zu Programmieren. Es geht ja so schnell und einfach. leider :-(

bike

 

[derMani]

Öhm führ das mal bitte weiter aus....

Also wenn ich dich richtig verstehe, sollte eine Programmiersprache möglichst kompliziert sein, damit bessere Programme entworfen werden? Warum programmieren wir dann nicht alle wieder pures Assembler, so wie früher? Wer braucht schon c++, java, python, ruby, delphi, c# und co
Alles viel zu einfach, die leute denken ja gar nicht mehr nach!


Also ich weiß nicht genau wie du das nun meinst, aber bis auf einige kleine Sachen, wie die automatische Speicherverwaltung (GarbageCollection), ist Java nun nicht unbedingt sehr viel leichter zu schreiben als c++, die syntax ist doch sogar nahezu identisch. Die vielen frei zugänlglcihen APIs erleichtern einem die Arbeit.

Auch bei Java-Anwendungen kommt man - wenn man sauber arbeiten will - nicht um ein paar Vorüberlegungen (z.B. modellieren) herum.

Führ doch mal bitte weiter aus, was du genau meinst

 

[Alf72]

Hehe... wieso Assembler... ist noch zu einfach... bitte direkt in Maschinencode... kann doch jeder :twisted:

 

[jengelh]

Das proprietäre Argument kann ich nicht vollständig nachvollziehen.

Bytecodefiles erlauben es, Programme verlässlich ohne Source zu vertreiben — eine Schande für die freie Welt!

Weil die Sprache unheimlich flexibel ist, weil es so viele hochqualitative frei verfügbare APIs gibt.

Das ist eine ihrer Schwächen — der ganze Apparat ist dadurch aufgeblasen.

 

[Alf72]

Darf ich fragen welche Sprachen Du verwendest oder als deutlich besser bezeichnest?

 

[derMani]

Bytecodefiles erlauben es, Programme verlässlich ohne Source zu vertreiben — eine Schande für die freie Welt!

Das erlauben reine binäre programme auch, oder hast du schonmal den sourcecode einer winword.exe erblickt? oO
Oder habe ich dich jetzt falsch verstanden?

Das ist eine ihrer Schwächen — der ganze Apparat ist dadurch aufgeblasen.

Wenn dir das zu aufgeblasen ist, nutze halt keine externen APIs und bastel dir deinen eigenen brei

Erst kürzlich habe ich mich mit der freien Bibliothek JGraph beschäftigen müssen, die es erlaubt Graphen und Baumstrukturen grafisch darzustellen und mit kanten zu versehen. Ich bin wirklich dankbar darüber, dass diese Bibliothek existiert. Eine eigene Implementierung hätte deutlich höhere Kosten verursacht und den zeitlichen Rahmen meines Projektes deutlich gesprengt. Dass das Programm anschließend aufgebläht war, kann ich nicht behaupten.

Übrigens: das Internetportal mobile.de ist von seiner Perl basierten Lösung komplett auf eine java/jsf seitige Lösung umgestiegen mit enormen Erfolg, bzw. Performancegewinn.

http://www.heise.de/kiosk/archiv/ix/2008/3/98

Der Artikel lohnt sich übrigens.

Da sage nochmal einer, dass java langsam sei...


Warum muss eigentlich jede java diskussion in die richtung laufen ach egal

 

[Alf72]

Das Java langsamer sei als andere Sprachen ist ein Relikt aus alten Zeiten... manche machen sich eben keine Gedanken darüber ob sich etwas geändert oder weiterentwickelt hat und bleiben bei Ihren "altmodischen" Vorstellungen.

Aktuelle Java VMs "kompilieren zur Laufzeit" (es wird nicht mehr interpretiert wie früher)... damit sind die Geschwindigkeiten schon vergleichbar mit z.B. C Programmen. Dazu kommen viele Faktoren, die auf die Geschwindigkeit Einfluss haben. Manches ist sicherlich langsamer als z.B. bei C... aber einiges ist auch schneller... und auch bei C hängt Vieles vom Compiler ab

Ich denke mal, dass ein extrem langsames Java Programm einen eher "schlechten" Urheber hat... das krieg ich aber auch in C so hin... wobei ich mir in C über viele Sachen Gedanken machen muss, die mir in Java abgenommen werden

Und zum Thema "freie Welt"... Java Code ist um einiges leichter zu dekompilieren als ein kompiliertes C Programm. Mal abgesehen davon was überhaupt erlaubt ist oder nicht.

Und wie Mani schon sagte... auch ich bin immer wieder froh darüber, dass sich einige Leute schon die Arbeit gemacht haben um für mich etwas zu implementieren. Wenn ich es nicht so "aufgeblasen" haben möchte, muss ich es ja nicht nutzen. Aber vielleicht denkt jengelh ja, dass man alle JARs dieser Welt benötigt um ein "Hello World" zu schreiben :mrgreen:

Meiner Meinung nach haben viele Sprachen ihre Daseinsberechtigung... es gibt immer "Sonderfälle" für welche die eine oder andere Sprache besser oder eben schlechter geeignet ist. Man kann nie sagen: "Die Sprache ist schlecht"... das wäre zu pauschal.

@jengelh
Mich würde immer noch interessieren welche Programmiersprache Du bevorzugst?

 

[jengelh]

Das erlauben reine binäre programme auch, oder hast du schonmal den sourcecode einer winword.exe erblickt? oO
Oder habe ich dich jetzt falsch verstanden?

Würde es den intermediären Bytecode nicht geben, wären Programme öfter als Sourcecode verteilt weil man öfter diesen bräuchte um die Kompilation durchzuführen -- so wie bei C, C++.

Das ist eine ihrer Schwächen — der ganze Apparat ist dadurch aufgeblasen.

Wenn dir das zu aufgeblasen ist, nutze halt keine externen APIs und bastel dir deinen eigenen brei

Das Problem ist nicht Java, sondern die Implementation in Sunjava. GCJ erscheint mir um einiges leichter im Gewicht.[/quote]

Übrigens: das Internetportal mobile.de ist von seiner Perl basierten Lösung komplett auf eine java/jsf seitige Lösung umgestiegen mit enormen Erfolg, bzw. Performancegewinn.

Mag ja sein, aber ich frag mich wieviele Köpfe dabei wohl zerbrochen sind.

Bevorzugen tu ich was immer angemessen ist. Das mag je nach Anwendungsfall Shell, Perl, PHP, C oder C++ sein.

 

[bike]

Öhm führ das mal bitte weiter aus....

Also wenn ich dich richtig verstehe, sollte eine Programmiersprache möglichst kompliziert sein, damit bessere Programme entworfen werden?

Führ doch mal bitte weiter aus, was du genau meinst

Programmieren ist nicht kompliziert, sondern der User ;-)

In vielen Firmen wird Java als universelle und heilsbringende Lösung aller IT Angelegenheiten betrachtet.
Es ist in diesem Umfeld nur schwer möglich zu vermitteln, dass es Anwendungen gibt die mit Java nicht zu realiseren sind.
Ausserem ist leider sehr leicht mit Java so mal eben ein Tool zu schreiben, dasss keiner braucht aber zum Standard erklärt wird, da es ja in Java geschrieben ist.
Ich meine damit, dass auch mit Java eine Metalität entstanden ist, alles in Java schreiben und Java ist gut.

Mir ist es absolut egal in welcher Sprache programmiert wird, die Anwendung muss ihren Zweck erfüllen.

bike

 

[derMani]

In vielen Firmen wird Java als universelle und heilsbringende Lösung aller IT Angelegenheiten betrachtet.
Es ist in diesem Umfeld nur schwer möglich zu vermitteln, dass es Anwendungen gibt die mit Java nicht zu realiseren sind.

Für das erfassen von Geschäftsprozessen ist java ideal geeignet, in den wenigsten Fällen braucht man in solchen Dingen maschinennahe programmierung. Deshalb eignet sich java in diesem Umfeld ja so gut. Aber Java-Entwickler, bzw. Informatiker, die nicht wissen, wo die Grenzen von java liegen und wann man lieber Alternativen verwenden sollte, verdienen diese Bezeichnung nicht wirklich. Man sollte stets wissen was machbar, bzw. nicht machbar ist.

Ausserem ist leider sehr leicht mit Java so mal eben ein Tool zu schreiben, dasss keiner braucht aber zum Standard erklärt wird, da es ja in Java geschrieben ist.

Ich verstehe einfach nicht was du meinst....
Es ist ja nun nicht so, dass man mit Java sich seine Anwendungen zusammenklickt... man muss ja schon noch einiges an Zeit reinstecken um ein Programm zu entwerfen. Wie gesagt, das Entwickeln von Anwendungen ist hier nicht wirklich einfacher als mit C++, nur muss man sich nicht um die Speicherverwaltung selbst kümmern und hat einige andere java spezifische Dinge, die man verwenden kann und die ggf. die Arbeit erleichtern (swing, jsf, oder was weiß ich). Dennoch schustert niemand "mal eben" ein funktionales Java-Programm zusammen.
Wenn jemand "mal eben" ein Programm entwickelt, was keiner braucht, ist das doch nicht die Schuld der Programmiersprache, sondern Fehlverhalten des Entwicklers, bzw. Fehlverhalten der IT-Abteilung oder ggf. des Projektmanagements. Entwicklerarbeitszeiten sind Kostenfaktoren die entsprechenden geplant werden müssen. Dass irgendjemand tools baut die keiner braucht ist nun wirklich kein Argument gegen Java, das kann doch mit jeder Hochsprache passieren.

Ich meine damit, dass auch mit Java eine Metalität entstanden ist, alles in Java schreiben und Java ist gut.

Punkt 1: Java ist gut.
Punkt 2: Ein betriebliches Informationssystem in einer einzigen Programmiersprache zu entwerfen bedeuetet Homogenität und Interoperabilität der Module. Das heißt, die Entwickler können sich auf eine Entwicklungssprache verlassen und arbeiten zusammen, bzw. kämpfen nicht an 100 verschiedenen Fronten. So bleibt die Software einheitlich gestaltet und erweiterbar. Das ist eher ein Vorteil als ein Nachteil. Die meisten Dinge lassen sich mit Java genauso gut realisieren wir mit anderen hochsprachen. Nur wenn es um systemnahe Entwicklungen geht, muss man wohl z.B. zu C greifen.
Ansonsten - so finde ich - sollte man sein Programm einheitlich entwickeln

Mir ist es absolut egal in welcher Sprache programmiert wird, die Anwendung muss ihren Zweck erfüllen.

Als Benutzersicht ist das defintiv wahr, für den Entwickler spielt natürlich noch die Erfahrungen und Kenntnisse mit einer Programmiersprache eine große Rolle.
Wenn aber z.B. eine Java-Anwendung den Zweck erfüllt, müsstest du doch dementsprechend auch mit der Java-Anwendung zufrieden sein!


Gruß
Mani

 

[abgdf]

Die meisten Dinge lassen sich mit Java genauso gut realisieren wir mit anderen hochsprachen.

Das ist eben leider nicht meine Erfahrung: Man muß viel mehr Code schreiben als nötig wäre, und man muß sich mit Kompilieren rumschlagen, obwohl man zusätzlich einen Interpreter oder was auch immer die JavaVM sein soll (Perl und Python erzeugen auch Bytecode, nennen das aber nicht "Just-In-Time-Kompilierung") auch noch mit sich rumschleppt.
GUI-Beispiele, jedenfalls mit awt, waren dazu noch allzu langsam, ja ruckelig und froren sogar manchmal ein, während sogar das einfache Python/Tkinter, Perl/Tk dagegen richtig flüssig und genauso plattformübergreifend läuft.

Wie ich oben schon sagte, irgendwie hat man mit Java immer das schlechteste von beidem ...

Vielleicht sollten die Befürworter mal ein schönes Beispiel mit einer flüssigen GUI und wenig Code in Java zeigen, oder ein Spiel, wenigstens vergleichbar "frozen-bubble" (Perl) oder "Solarwolf" (Python).

Sehr ärgert mich z.B. auch dieser Java WebStart-Kram hier:

http://www.egvp.de/software/index.php

Warum stellt man da nicht eine "egvp.zip"-Datei hin, die man mit "wget" abgreifen kann und gut ist ? Nein, da muß dieser Java-Blödsinn dazwischen.

Gruß

 

[jengelh]

Die meisten Dinge lassen sich mit Java genauso gut realisieren wir mit anderen hochsprachen.

Das ist eben leider nicht meine Erfahrung: Man muß viel mehr Code schreiben als nötig wäre, und man muß sich mit Kompilieren rumschlagen,

Ganz — genau.

 

[abgdf]

Danke für die Zustimmung !

Einmal hatte ich Java noch eine Chance gegeben mit

http://www.robocode.de/

weil ich mal das hier geschrieben hatte:

http://www.python-forum.de/topic-9104.html

Aber Robocode war ebenfalls ganz gruselig ruckelig.
Und wieder konnte mich Java nicht begeistern ...

Gruß

 

[Alf72]

Hat von Euch schon mal jemand versucht eine Client-Server Anwendung zu schreiben, die auf verschiedenen Zielplattformen läuft und weltweit ohne Installation verteilt werden kann? Und damit meine ich nicht irgendein "Onlinekram", sondern einen richtigen "Fat Client".

Da ist meiner Ansicht nach Java nicht nur eine Lösung, sondern die beste
Und auch der WebStarter ist eine sehr feine Sache

Deine negativen Erfahrungen beruhen - wenn ich das richtig herauslese - scheinbar alle auf irgendwelchen "Spielchen"... dafür würde ich wahrscheinlich auch kein Java verwenden... aber es gibt eben Problemstellungen, die ohne Java nur deutlich schwerer zu lösen wären.

Das z.B. die Grafik in anderen Sprachen schneller sein kann steht ja nicht zur Diskussion. Aber zu sagen Java ist schlecht, weil die Grafik bei Spielen mit XY schneller ist, wäre nicht fair.
Zudem hat sich auch hier bei Java schon einiges getan... und "normale" Anwendungen mit grafischer Oberfläche sind auf heutigen Rechnern auf jeden Fall schnell genug... zumindest wenn sie richtig programmiert wurden

Dein Beispiel mit dem WebStarter... es ist doch schön... einfach drauf klicken und alles läuft?!? Einfacher gehts doch nun wirklich nicht... und das kann jeder ohne irgendeine Python/Perl/... oder sonstwas Installation... Java ist ja meistens schon "drauf"
Wieso erst etwas herunterladen... auspacken... vielleicht noch irgendetwas installieren weil etwas fehlt... und dann ärgern weil doch irgendetwas nicht passt... und das alles für ein Programm, das ich vielleicht nur mal kurz anschauen möchte

 

[derMani]

Das ist eben leider nicht meine Erfahrung: Man muß viel mehr Code schreiben als nötig wäre und man muß sich mit Kompilieren rumschlagen, obwohl man zusätzlich einen Interpreter oder was auch immer die JavaVM sein soll (Perl und Python erzeugen auch Bytecode, nennen das aber nicht "Just-In-Time-Kompilierung") auch noch mit sich rumschleppt.

1. Je nach Anwendungsfall muss man mal mehr oder mal weniger Code schreiben, das ist doch in jeder Programmiersprache so. Ich finde es z.B. sehr schön in Java, wie einfach man Klassen extenden kann. Nehmen wir an ich benötige eine Integerklasse, will sie aber um zusätzliche Funktoinen versehen, dann reicht es einfach in meiner Klasse das Schlüsselwort extends und den Namen der entsprechenden Wrapperklasse Integer anzugeben und schon kann ich loslegen. Das ist definitiv eine Zeitersparnis.

Mehr Codearbeit entsteht aber teilweise durch die verschiedene Art der Zeiger und Referenzsemantik in java (hier kann man teilweise durch Zeiger in c++ ein bisschen Code sparen, wenn man Eingangsparameter auch als Ausgangsparameter in Funktionen vewenden möchte.

2. Ich sag es gerne nochmal: Java wird seit Jahren schon nicht mehr interpretiert. Die Art und Weise wie Java-Programme ausgeführt werden unterscheiden sich deutlich von Pearl oder Python. So wie du es schreibst, scheinst du anzunehmen, dass Java trotzdem interpretiert wird und die einfach der Interpretierung den Namen "Just in Time Kompillierung" verpasst hätten. Das ist definitiv nicht der Fall, zumindest in SUNs eigener JVM-Implementierung.

Die JAVA-Specs sagen, dass die JVM aus drei dingen bestehen muss: Dem Class loader, der garbage collection und der Execution Engine. Wie die Execution-Engine realisiert wird, können die Entwickler der VM bestimmen. Sicherlich gibt es auch einige VMs die den Bytecode stumpf interpretieren, aber das ist nicht sehr performant.

In der ExecutionEngine mit Just in Time Kompillierung wird der kompillierte Code zwischengespeichert. Nehmen wir eine Standardschleife mit Loops / repeats an. Ein Standardinterpreter würde diese Schleife immer und immer wieder neu zur Laufzeit interpretieren. JIT hält aber bereits kompillierte Codesegmente für das potenzielle Wiederverwenden im Speicher.
Dadurch ist gerade bei schleifen JIT eine sehr (in Bezug auf die Zeitkomplexität) performante Geschichte.

Ich kann es auch kaum nachvollziehen, dass du dich immer über den zusätzlichen Kompillierungsaufwand beschwerst.
Jede bessere Java-IDE kompilliert den Quellcode schon während der Bearbeitungsphase (z.B. Eclipse) im Hintergrund. Das ganze ist sogar so komfortabel, dass du beim Debuggen das Hot Code Replacement verwenden kannst und Code zur Laufzeit verändern kannst.


Irgendwie kommt es mir so vor, als würden deine letzten Gehversuche mit Java in den späten 90ern gewesen sein.
Mit AWT hast du genau den Knackpunkt angesprochen, mit dem java (damals) zu kämpfen hatte. AWT hat das ganze sehr lahm gemacht und es sah auch noch hässlich aus. Das ist mittlerweile geschichte. Mit AWT programmiert seit Jahren kein Java-Entwickler mehr GUIs. SUN selbst hat für die GUI-Programmierung Swing mit in die Java-api eingebaut. Swing ist deutlich performanter als AWT und zugleich hübscher. Swing-Komponenten können sich dynamisch an das Look&Feel deiner Desktopumgebung anpassen. Eine Java-Anwendung sieht unter Windows dann aus wie eine Windows-Anwendung und unter macosx wie eine native mac-anwendung. Trotzdem bleibt die relative Anordnung der Komponenten bestehen. Die Programme sehen trotz unterschiedlicher widgets die verwendet werden gleich von der Anordnung her aus.

"Flüssige" Beispiele findest du hier: http://java.sun.com/docs/books/tutorial/uiswing/

Als gutes Beispiel für ein Swingprogramm kann man wohl den beliebten TV-Browser aufzählen.
Ebenfalls toll ist die mp3-abspielsoftware Atunes.
Unter linux verwende ich zum Hören von Musik immer Amarok, wenn ich aber gezwungen bin unter Windows zu arbeiten, verwende ich Atunes. Atunes ist meiner Kenntnis nach das einzige opensource-tool unter windows, welches ähnliche funktionalität wie Amarok bietet. Man möge mich aber hier korrigieren, wenn es weitere gute und freie Abspielalternativen für Win gibt.

http://de.wikipedia.org/wiki/ATunes

Als Alternative zu Swing kann man noch SWT erwähnen. SWT ist derzeit wohl die Creme de la Creme was GUI-Entwicklung mit Java angeht. Hier gebe ich dir auch gleich zwei Beispiele von Programmen die "flüssig" und toll sind: Der Bittorrentclient Azureus (nun Vuze) und die Entwicklungs-IDE Eclipse.

Dass auch 3d und 2d Anwendungen mit Java möglich sind zeigen die java2d- und java 3d apis. Ich habe mich kürzlich erst mit diesen Geschichten auseinandersetzen müssen und es sind damit definitiv flüssisige Animationen möglich. Ich würde nun kein neues World of Warcraft damit entwickeln wollen (dafür ist es nicht gemacht), aber man kann z.B. sehr schön damit chemische moleküle modellieren lassen.

Naja wie dem auch sei, Java auf dem Desktop wird denke ich nie eine eine große Nummer sein. Es hat seine stärken im Unternehmensbereich wo es nicht unbedingt auf zeitkomplexe Ausführung ankommt, sondern die Sicherheit und Flexibilität im Vordergrund stehen.

Gruß
Mani


PS: Das mit dem Webstart ist eine Entwicklerentscheidung. Die Entwickler wollen offensichtlich nicht, dass man sich das Programm herunterlädt, sondern möchten die Umgebung auf ihrer eigenen Seite anbieten. Das kannst du nicht java ankreiden, sondern dem Webmaster der entsprechenden Seite, bzw. den dortigen Entscheidungsträgern.


Und noch was für dich, da du dich für Robotic zu interessieren scheinst:

http://robocup.fh-wolfenbuettel.de/

Unsere FH ist da ganz oben bei der Robocup-WM mit dabei und und hat schonmal den Cup geholt. Weißt du was, die entwickeln ihre Robos mit java

 

[abgdf]

Deine negativen Erfahrungen beruhen - wenn ich das richtig herauslese - scheinbar alle auf irgendwelchen "Spielchen"...

EGVP z.B., das ich genannt hatte, ist das "Elektronische Gerichts- und Verwaltungspostfach", also der Zugang zum elektronischen Rechtsverkehr, das heißt Klagen und Mahnbescheidsanträge online an Gerichte übersenden.
Also so ziemlich die ernsteste Anwendung, die es gibt.

Gruß

 

[Alf72]

Und bei dieser Anwendung "stottert" die Grafik? Na dann würde ich aber mit den Entwicklern schimpfen

 

[jengelh]

Hat von Euch schon mal jemand versucht eine Client-Server Anwendung zu schreiben, die auf verschiedenen Zielplattformen läuft

"verschiedenen" = "wo es eine Java VM für gibt". Bis vor kurzem waren das, äh, noch sehr wenige.

und weltweit ohne Installation verteilt werden kann?

Das kann man auch ohne Java. Dazu braucht's zwei Dinge: Standalone-Binary mit allen nötigen Libs shipped oder linked-in (bspw. VMware), sowie einen Developer der das ganze in einer "portablen" Weise programmiert (findet sich in VMware leider nicht :-D ).

Da ist meiner Ansicht nach Java nicht nur eine Lösung, sondern die beste

Kaffee ist keine Lösung, sondern ein Filtrat. (Kann ich nun trotzdem bitte das Problem zurückhaben?)

 

[Alf72]

Du bist ja richtig lustig

Mit "verschieden" meine ich z.B. Windows, Linux und UNIX Systeme. Ich denke auch, dass damit die gebräuchlichsten Clientsysteme abgedeckt sind

Mit "weltweit ohne Installation verteilen" meine ich z.B. Browser aufmachen, Link klicken, glücklich sein
D.h. ich will nicht für alle möglichen Zielsysteme ein extra Binary bereitstellen und dem User vielleicht sogar noch die Auswahl überlassen was er drückt (da kann ich jetzt schon die Supportfälle sehen). Genauso wenig möchte ich durch die Lande ziehen und jedem irgendwelche Sachen installieren.
Zudem brauche ich eine Möglichkeit einfach Updates einzuspielen/bereitzustellen OHNE dass der Anwender irgendetwas Neues - ihm Unverständliches - machen muss.

Natürlich kann man alles auch anders machen... darf auch jeder tun und lassen wie er mag... ich kann auch wenn ich von Berlin nach München will zu Fuß gehen... die Bahn/ein Flieger/das Auto wären aber bestimmt schneller und einfacher... Java hat schon so seine Vorzüge

Aber ich sehen schon... Du akzeptierst sowieso keine Argumente oder Beispiele.
Mir ist es auch eigentlich egal... ich will Dich ja überhaupt nicht überzeugen.
Ich habe jetzt schon in einigen Sprachen entwickelt... und Java ist mir schon sehr sympatisch... nicht für alles, aber für vieles.

Aber ich denke diese Diskussion hier führt zu nichts.