richtig. im klartext heisst das -> java wurde nach der ersten euphorie aus den clients richtung server verbannt, weil sie eben schwer heavyweight ist.
Java wurde nicht vom Client verbannt, sondern fand dort einfach wenig Anklang, weil die anfänglich mitgelieferte Oberflöche, das AWT, einfach grauenvoll war. Erst mit Java 2 (JDK/JRE 1.2) kam mit Swing ein wirklich gutes GUI, das es mit den nativen GUIs aufnehmen konnte.
wer spielt noch mit applets heutzutage?
Map24.de
Ich entwickle Desktop-Anwendungen und manchmal auch Applets in Java. Und fürn Desktop gibts doch so einiges...
auch richtig. niemand mehr bei gutem verstand wird so viele systemunabhängige classes packages neu entwerfen.
ein beispiel: ein telekommukationsunternehmen, wo ich gearbeitet habe, hat sich ein komplexes crm-tool zugelegt, mit dem ganzen datenbanknetz, middleware und verschiedenen front ends dazu. das einizige, das nicht richtig bis nie funktioniert hatte (das hat eine weltberühmte consultingfirma implementiert) waren java teile, vor allem web interface. die ausführenden entwickler aus aller welt haben sich stark gewundert, warum man die datenbank logic nicht mit einfachen pl/sql funktionsaufrufen statt komplizierten und anfälligen enterprise beans entworfen hatte.
Java ist ja nicht Schuld daran, wenn IT-Manager die falschen Entscheidungen treffen. Ich war immer ein Anhänger von Das-geeignete-Werkzeug-für-die-jeweilige-Aufgabe, ganz egal ob das nun hieß, dass ich mich in PHP einarbeiten oder mit Perl und Shellskript rumhantieren musste.
Und wenn die nunmal nur Peilung von EJB und keinen Bock haben sich in PL/SQL einzuarbeiten, dann machen sie es eben mit EJB. Persönlich halte ich auch nichts davon Arbeiten außerhalb der DB zu erledigen, die da besser drin bleiben. Daher freue ich mich bei MySQL auch auf die Stored Procedures (leider nutzen wir nicht PostgreSQL).
ich denke die legacies sind so unterschiedlich, dass man die zukunft in einfachen handles-systemen sehen wird, die die daten untereinander austauschen. xml ist ein _guter_ weg in diese richtung.
Übrigens sind nahezu alle Referenzimplementationen für irgendwelche XML-Technologien alle in Java geschrieben..
auf jeden fall es ist ein fehler, wenn man die systeme zwangsweise harmonisieren und unifizieren will, auch die neuesten, die gerade entstehen. es gibt für verschiedene aufgaben optimale lösungen, die mal mit vb oder php oder c# oder java oder sogar perl und shell-scripten bewältigt werden können. die zukunft ist in der schlanken kommunikation miteinander, denke ich.
Ist grundsätzlich richtig und entspricht meiner oben gemachten Aussage. Im Grunde ist das ja eine alte Angewohnheit und Stärke von Unix-Systemen einzelne Komponenten mit etwas Glue-Logic zu komplexen Systemen zusammenzuschalten.
Allerdings können diese Komponenten neben kleinen Kommandozeilentools auch sehr komplexe Anwendungen und Systeme aus Anwendungen sein. Wenn ich ein komplexes Projekt vergebe, dann wird der Ausführende wohl kaum ein halbes Dutzend Sprachen auf einer Unix-Umgebung zur Umsetzung nutzen., sondern er wird sich auf sehr wenige Technologien beschränken und diese stark einbringen, weil er vermutlich auch vom Know-How her in der Breite die notwendige Tiefe nicht bieten kann - kleiner Tribut an den Spezialisierungszwang und möglichst geringe Projektzeiten und damit auch Kosten.
Manche füllen ihren Wagen auch stets mit Billig-Baumarkt-Öl und wundern sich, warum die Karre im Winter so ruppelt und warum der Motor verreckt.. - aber man hat erstmal gespart.
In der Praxis ist es nunmal häufig einfacher und kostengünstiger für einen Auftraggeber ein wenig mehr in Hardware zu investieren oder eben ne Sekunde länger zu warten, als viel mehr fürs Projekt auszugeben und länger drauf zu warten - hat auch immer firmenpolitische Gründe.
Ich sehe es ja bei uns. Wir müssen auch immer möglichst schon vorgestern die neuesten Features in die Software integrieren und möglichst gestern schon liefern, um heute noch die Rechnung stellen und mir nen neuen Wagen gönnen zu können...
Die freie Marktwirtschaft lässt wenig Raum für Idealismus. Drum haben wir auch technisch veraltete SGIs zum Hobby, weil wir wenigstens privat in einigen Nischen die Möglichkeit haben den Idealisten in uns auszupacken. Aber wer von uns verdient schon an einer SGI sein Geld?
