Selbst Hardcore Java Junkies wie Axel haben die Gigabytes an Code noch nicht rechtfertigen können.
1. sehe ich mich nicht als hardcore java junkie. Ich arbeite z.Zt. mit LotusNotes, LEI, DWF, VisualBasic, C# und Java.
2. Ich bin z.Zt. überhaupt kein Gigabyte freak und sogar expliziter Gegner des IBM-Speicher-Gigantismus. Ich könnte (und werde müssen) den Arbeitsspeicher des Flagschiffes meiner Rechner (das Dell Lapptop) auf 2 GB ausbauen müssen. Z.Zt. hat es 512 MB Arbeitsspeicher. Das ist auch ein bischen albern und war mal mehr. Für die Eclipse/Java/Spring/Hibernate/ein_paar_weitere packages Sachen, die ich z.Zt. mit Java mache, ist das völlig ausreichend.
Die "Java Community" von der hier manchmal die Rede ist, existiert genauso wenig wie die Axis Berlin-Paris-Brusseles von der Amis manchmal in der Politik sprechen. Vielmehr handelt es sich um eine sehr heterogene und diskutierfreudige Gruppe mit sehr unterschiedlichen Zielen, Sichtweisen und Aufgaben. Lest bitte zumindest Bruce Tate (Better Faster Lighter Java). Das ist auch für Leute mit wenig Java-Erfahrung nicht so schwierig zu verstehen. Da wird aber ganz klar gezeigt, dass
a) IBM und verwandte Firmen haben eine gut funktionierende Marketing Maschinerie, die IT-Abteilungen in falsche Investitionsentscheidungen führen kann (nicht muss).
b) IBM sich über einen langen Zeitraum bzgl. einer wichtigen Architekturkomponente irren kann und zwar völlig (Entity EJB).
Jens sein Argument bzgl. neuer Hardware erinnert sehr stark um die Diskussionen rund um Entity EJBs im Jahre 2001, wo ich das auch geglaubt habe. Es hat sich aber gezeigt, dass es "Performance"-Probleme gibt, die sich nicht mit schnellerer Hardware lösen lassen. Um aus der Geschichte zu lernen, müsste hier jemand genauer analysieren, wo
genau die "Performance"-Probleme der Architektur liegen. Ich schreibe "Performance" in Anführungszeichen, weil mittlerweile nachgewiesen ist, dass der Begriff "Performance" verschiedenes meint und einfach zu unscharf ist. Werd mal die sehr interessante Aufschlüsselung posten, wie sie z.B. Martin Fowler beschrieben hat und die nun in jedes gute J2EE Buch übernommen wird.
Die Idee die Eclipse Plattform für den Client zu verwenden und dabei die komplette Notesfunktionalität zu erhalten gefällt mir ebenfalls.
Solange ich mich nicht damit näher beschäftigt habe, ist es Stochern im Nebel. Hier meine Punkte:
Abwärtskompatibilität hat seine Vorteile, unbestritten. Nur ist das der Punkt, wo ich meine stärksten Bedenken habe (wir müssen nicht alle einer Meinung sein). Ich glaube nicht, dass sich eine Funktionalität, wo es keine architektonischen Layer(Presentation, Business Logik, Persistenz) gibt, sauber in eine verteilt transaktionale und im Entwicklungsmodell stark Layer-fokussierte Plattform J2EE bringen lässt. Skripting auf J2EE Basis hat sich immer als BAD IDEA erwiesen. Genau deshalb werden JSPs heute praktisch nur noch sehr fest eingebunden eingesetzt.
Notes Programmiermodell auf J2EE Basis hört sich aber genau nach Skriptlet hoch 100 an. UND DAS FÜHRT ZU SCHWER ZU MAINTAINANDEN, UNÜBERSICHTLICHEN ANWENDUNGEN. Und das ist IMHO genau der Punkt, wo sich die meisten Kritikpunkte an einer Notes Umgebung ergeben. Zumindest bei meinen Kunden.
Durch eine substantielle Fortentwicklung von Notes und Domino bei gleichzeitiger Erweiterung um J2EE Funktionen (wenn möglich mit einem etwas schlankeren Ansatz z.B. Tomcat oder Geronimo statt Websphere, Derby statt DB/2) ließe sich evtl. viel mehr erreichen.
IBM ist nicht schlank und will es imho auch nicht sein. Alle Dinge die schlank sein sollen, werden ausgelagert (Eclipse Software Foundation ist unabhängig von IBM, Derby aka Cloudscape wurde an die Apache Software Foundation übertragen).
Das Ziel von IBM besteht imho mehr darin, Corporate Developern eine Umgebung zur Verfügung zu stellen, die
a) stark administrativ konfigurierbar ist. (deshalb will ich Websphere admin certi machen)
b) dem Programmierer möglichst viel Arbeit abnehmen will.
Dafür verzichtet man auf die schnelle Integration von allerneuesten Technologien und teilweise leidet unter diesem Ansatz die Flexibilität und vor allem auch die Austauschbarkeit von Komponenten.
Wer schlanke Sachen machen will, sollte sich imho openSource Java zuwenden (inkl. JBoss). Warum haben die sonst Rational gekauft?
Lotus Notes und Domino müssen sich verändern. Weiter so kann nicht das Motto sein sonst würde nicht so vielen Business Partnern die Luft ausgehen. Alleine an der Richtung habe ich Zweifel. Was für Daimler-Chrysler und die Deutsche Bank eine tolle Lösung ist muß für mich leider noch lange nicht passen.
Genau das ist auch mein Zweifel.
Am Ende möchte ich mich für J2EE entscheiden, weil es für mich die bessere Lösung darstellt und nicht weil IBM die Entwicklung im anderen Bereich auf Smartsuite Niveau heruntergefahren hat.
Es lässt sich nicht wegdiskutieren, dass das souveräne Investitionsentscheidungen von IBM sind auf die ich keinen Einfluss haben
darf. Business Partner sind für IBM Institutionen, die konsultiert werden. Die Entscheidung findet aber souverän bei IBM statt.
Axel
