JBoss...Interessanterweise scheint es beim JBoss Issue keinen neuen Stand zu geben. Aber immerhin ist IBM so weit, Apache Geronimo jetzt
unter eigener Fahne zu verkaufen. Dadurch wird es für JBoss wahrscheinlich etwas schwieriger werden. Immerhin hat IBM mit Eclipse schon mal ein sehr mächtiges Open Source Projekt aus der Taufe gehoben.
Außerdem ist anscheinend die
erste EJB 3 Applikation live bevor die Standardisierung beendet ist. Natürlich auf JBoss. Herzlichen Glückwunsch! Wieviel Spring Anwendungen gibt es eigentlich, die live sind? Wie dem auch sei, auf jeden Fall ein schönes Wochende.
Wenn wir so Software entwickeln würden...Ein traditioneller Vergleich ist ja "Wenn wir so Häuser bauen würden, wie wir Software entwickeln, dann..." und anschließend kommen alle merkwürdigen Dinge, die man sich so beim Hausbau vorstellen kann. Dahinter steckt die Vermutung, dass physisch anfassbare Dinge niemals solche Fehler hätten, wie dies bei Software manchmal der Fall ist. Nun ja, nachdem ich vorgestern im Fernsehen eine Sendung über Probleme beim Hausbau gesehen habe, denke ich anders darüber. Auch beim Hausbau passieren offensichtliche Fehler. In der Sendung waren die Beispiele ein durch gepfuschte Isolierung extrem feuchtes Haus, ein Haus mit zerbröselnden Steinen (!) und ein Haus mit einem Dachstuhl, der nicht vernünftig zusammengesetzt war.
Vielleicht ist also doch so, dass Software sich nicht so sehr unterscheidet. Meiner Meinung nach ist die sinnvolle Parallele für Software-Entwicklung das Schreiben von Büchern. Auch dort geht es um etwas, was letzendlich nicht anfassbar ist und sogar auch aus Text besteht. Ein anderes Beispiel ist die Erstellung von Filmen. Dort wird kein Text geschrieben (zumindest nicht als Endprodukt), aber dafür sind es größere Teams. Und aus der Lean Software Development Schiene kommt der Vergleich zu normaler Produktentwicklung. Am Ende sind wir als Software-Entwickler nicht so etwas besonderes...
100. Eintrag!Dies ist der hunderste Eintrag in meinen Blog. Bis jetzt macht es recht viel Spaß, weil es eine einfache Möglichkeit ist, aktuelle Dinge ohne großen Aufwand niederzuschreiben und anderen die Möglichkeit zu geben, auch einen Blick drauf zu werfen. Einen Artikel zu schreiben ist immer eine etwas aufwändigere Sache. Von daher werde ich es auf jeden Fall weiter machen.
Arbeitskreis Objekttechnologie NorddeutschlandHeute abend spreche ich über mein Lieblingsthema (Spring) beim Arbeitskreis Objekttechnologie Norddeutschland. Mehr Infos gibt es
hier.
Beyond JavaBruce A. Tate hat gerade ein sehr interessantes Buch über "Beyond Java" herausgebracht. Dabei stellt er dar, dass seiner Meinung nach vor allem beim Web basierten Zugriff auf relationale Datenbanken andere Programmieransätze mehr versprechen. Außerdem wird Java generell in der Komplexität kritisiert. Es ist spannend: Es scheint ernsthaft in der Java Community zu rumoren. Im Java Magazin gab es ja auch die "Jenseits von Java" Serie. Vor allem beeindruckend ist, dass Bruce A. Tate aus dem Spring Bereich kommt und trotzdem außerhalb von Java mehr interessante Ansätze sieht. Unten ist der Link auf's Buch, meiner Meinung nach eine gute Lektüre für jeden Java Entwickler.
Ist EJB Denk-Legacy?
Ich bin gerade auf dem Rückweg vom MATHEMA Campus, wo ich einen Vortrag
über Spring gehalten. Das Feedback war ausgesprochen gut.
Dennoch habe ich ein mulmiges Gefühl von dort mitgenommen. Ich habe das
deutliche Gefühl, dass EJB in den Köpfen so tief verwurzelt ist, dass es
die Default-Technologie-Entscheidung ist. Auf der einen Seite ist dies
nicht überraschend, denn das Publikum dort ist eben EJB-minded. Aber auf
der anderen Seite ist es dann doch sehr erstaunlich, denn die Schwächen
von EJB sind seit langem bekannt. Es sind zahlreiche Artikel über dieses
Thema geschrieben worden und auch schon Vorträge darüber gehalten
worden. Ich selber habe mich mit diesem Thema 2003 beschäftigt und das
Buch "Bitter EJB" ist auch in dem Bereich erschinen. Jetzt ist es zwei
Jahre später und ich habe das Gefühl, wenn man die Frage stellt, warum
man EJB verwendet, wird man komisch angesehen. Es wird nicht mit
Nachdruck versucht, EJB als Technologie aus den Projekten zu
eliminieren, sondern es wird drumherum gebastelt.
Mich beunruhigt dies nicht wegen dem "Spring vs. EJB" Thema. Ich hoffe,
dass wir eines Tages einfach einen Stand erreichen, bei dem wir
unorthodox einfach die beste Technologie verwenden. Mich beunruhigt es,
weil es bedeutet, dass wir genau an dieser Stelle der "unorthodoxen
Sicht" nicht sind. Da Java zunehmend unter Druck von anderen
Technologien wie Ruby gerät, können wir als Java Programmierer uns
eigentlich nicht leisten, auch nur das kleinste bischen Produktivität
durch falsche Entscheidungen zu opfern. Wenn aber EJB schon so lange als
Problem bekannt ist, sollte doch das Ziel eines "mercy-less
Refactorings" die Eliminierung von EJB sein. Oder?
PS: Um es noch deutlich zu sagen: Die Rede ist in erster Linie von EJB
2.1, auf das sich ja auch die Kritik bezieht. Mit EJB 3 ist die
Technologie zwar einfacher, aber trotzdem sehe ich kaum zwingende Gründe
für den Einsatz von EJB 3.
Java's ZukunftIm Moment scheint das Thema Java's Zukunft ein recht spannendes zu sein. Ich selber habe im Java Magazin von einiger Zeit Johannes Links Artikel-Serie zum Thema "Über den Tellerand Schauen" mit diesem Thema eröffnet und es gab dort auch einen Beitrag über dynamisch typisierte Sprachen. In diesem
Artikel über RDT (das Ruby Plug-in für Eclipse) kann man lesen, dass alle coolen Leute jetzt Ruby nutzen.
Was bedeutet das? Meiner Meinung nach muss man einfach sehen, dass Ruby im Moment noch nicht so viel Support hat wie Java. Dadurch ergeben sich zum Beispiel Probleme in den Gebieten, in denen Java EE stark ist, also zum Beispiel Messaging Systeme oder Host Integration, aber auch sonst ist Javas Vorteil die extrem große Menge an Open Source Tools, die einem zur Verfügung stehen.
Aber meiner Meinung nach ist dieser Vergleich gar nicht so relevant. So gibt es für Python beispielsweise mit
Jython eine Implementierung für die JVM und mit
IronPyhton eine Implementierung für die .NET CLR. Ein
älterer Vergleich zeigt, dass sowohl IronPython als auch Jython dem Original in Performance überlegen sind. Ich habe das selber auch nochmal ausgemessen und die Ergebnisse bestätigt gefunden.
Was bedeutet das? JVM und CLR sind gute Umgebungen auf denen man auch Skripting Sprachen ausführen kann. In der Umsetzung sind hier Probleme, weil zumindest die JVM dynamisch typisierte Sprachen nicht wirklich unterstützt. Dazu habe ich auch schon mal gebloggt und das Thema wird auch angegangen werden. Da der echte Wert der Plattformen .NET und Java EE die Bibliotheken sind, sollte man also mal schauen, ob man Skripting Sprachen elegant damit verheiraten kann.
Auf jeden Fall sollte man in dieser Richtung offen sein. Das ist ja auch der Ansatz aus dem "Pragamtischen Programmierer": Andere Programmierparadigmen erweitern den Horizont. Und das dynamisch typisierte OO-Sprache gut sind, wissen wir spätestens seit Smalltalk. Darüber gibt es übrigens gerade einen Artikel in der iX - scheint also immer noch Leute zu interessieren...
Die Application Server Erde ist ein Scheibe!Endlich sagt einer von der JBoss Gruppe
was zu den Vorwürfen. Oder er denkt es zumindest. Auf mich macht der Interviewte den Eindruck, dass er nicht weiss, was passiert ist. Insbesondere habe ich nach dem Interview nicht verstanden, ob die Markenrechte in Europa nun bei Marc Fleury liegen oder bei JBoss Inc. Die Realität kann man online
hier sehen: Es ist Marc Fleury. Das ganze liegt daran, dass JBoss Venture Capital akquiriert hat und die Marke vorher eingetragen wurde. Aha. Alles klar.
Ich weiss nicht warum, aber ich muss in letzter Zeit immer öfter an
Bagdad Bob denken.
JSF oder Struts?Auf der Web Site des Java Magazin ist die aktuelle Umfrage: "Setzen Sie bei Ihren neuen Java-Webprojekten auf Struts oder JavaServer Faces (JSF)?" Ich finde diese Sache in so fern interessant, als das ich mich vor kurzem mit beiden Frameworks im Rahmen der Spring Integration beschäftigt habe. Ich bin natürlich vorbelastet, aber nach meinem Empfinden ist Struts ganz klar technologisch einfach veraltet. Vor allem das Paradigma, dass man seine Klasse von vorbereiteten Struts Klassen ableiten muss, ist einfach schlecht. JSF sieht hier besser aus. Dennoch verstehe ich nicht, warum JSF vor allem den Fokus auf die Unterstützung unterschiedlicher Front Ends legt, wo es doch sowieso ganz primär immer um Web Anwendungen geht. Auch der Fokus auf die Unterstützung von Web GUI Buildern löst zumindest bei nicht-trivialen Projekten nicht das zentrale Problem, nämlich das Design der Anwendung.
Eine interessante Sache ist auch die Unterstützung von Validierungen: Bei Struts muss man hier eine eigene Klasse implementieren, die von einer vorgebenen Oberklasse erbt. Bei JSF definiert man einfache Validierung an den GUI Elementen. Dies verstehe ich überhaupt nicht: Validierung ist Geschäftslogik. Zwar nicht sehr komplex, aber immer noch Geschäftslogik. Wieso soll man das direkt an die GUI Elemente hängen? Das ist ein ziemlich komisches Vorgehen.
Somit ist JSF sicher ein Fortschritt, weil man mehr mit POJOs machen kann. Aber ich persönlich halte Spring MVC eher für das zu Ende gedachte Struts (aber ich bin vielleicht auch voreingenommen). Validierungen sind hier komplett vom Web Framework unabhängig und können somit auch von Rich Clients eingesetzt werden. Und vor allem entkopellt es die Views komplett von den Controllern, so dass eine Integration mit Views wie JSP, XSLT aber auch PDF oder Excel problemlos ist und zwar ohne Änderungen an den Controllern.
Nur ist Spring MVC eben weder so früh auf dem Markt wie Struts noch wird es so gepusht wie JSF, was eben der offizielle Standard ist. Und deswegen taucht es in der Umfrage des Java Magazins auch gar nicht erst auf. Aber auch wenn man Struts oder JSF benutzt, kann man Spring immer noch sinnvoll nutzen, um die Anwendung zu strukturieren. Und die Integration ist bei beiden Optionen recht einfach. Spring zwingt einen eben nicht dazu, das Spring MVC Web Framework zu nutzen...
JBoss: Selber SchuldJetzt wissen wir es: Niemand wurde wegen Markenrechtsthemen verklagt. Es ist nur so, dass ein bestimmter deutscher Dienstleister einige Rechte verletzt hat. Alles ganz normal. So zu lesen im JBoss Blog und zwar
hier. Na, dann ist das ja wohl alles
Viel Lärm um nichts. Nur ist mir bei dieser Komödie nicht zum Lachen zu Mute.
Apple auf dem Weg zur Unterhaltungselektronik...Die Vorstellung des
iPod mit Video gestern sollte niemanden überrascht haben. Wesentlich spannender sind die neuen iMacs mit Fernbedinung und eingebauter Video-Kamera. Vor allem durch
FrontRow entsteht eine Art Windows Media Edition für den Mac mit Musik, Video, Photos und DVD. Muss man nur noch den Fernseher rauswerfen und stattdessen einen iMac ins Wohnzimmer stellen...
Dependency Injection in Java EE 5Es ist relativ spannend, dass mittlerweile Dependency Injection offensichtlich in Java EE 5 eine entscheidene Rolle spielt. Davon kann man im
Java EE 5 Entwurf lesen, aber auch im
Common Annotations JSR. Dies ist in sofern interessant, als das diese Thema mit EJB 3 begonnen hat, in Java EE einzug zu halten. Natürlich ist dieser Ansatz von Frameworks wie zum Beispiel Spring zuerst verwendet worden. Nun könnte man denken, dass dadurch nun zwei äquivalente Ansätze entstehen. Das ist leider nicht so.
Der wesentliche Unterschied ist, dass bei Java EE 5 nur einige ausgezeichnete Klassen (z.B. Servlets oder EJBs) Ziel einer Dependency Injection sein dürfen. Damit ist Java SE komplett ausgenommen. Außerdem - und das is schlimmer - sind in einer Java EE 5 Anwendung nur einige Klassen per DI konfigurierbar, während andere es nicht sind. Bei JNDI konnte man immerhin noch überall einen entsprechenden Lookup machen. JSR 250 sagt zwar, dass auch Java SE eines Tages in dieser Beziehung standardisiert sein soll, die Frage ist aber, wann das sein soll. Recht gut gelöst ist jedoch die Integration mit JNDI - es gibt eine eindeutige Abbildung und die Konfiguration aus dem Source Code kann durch Deployment Descriptoren überschrieben werden.
Also: Alles in Butter? Meiner Meinung nach ist Spring immer noch der elegantere Ansatz: Einige einfache Prinzipien erschlagen das Problem für alle Ressourcen in Java EE oder Java SE. Außerdem ist DI in Spring Basis für viele weitere coole Sachen. Was bedeutet das? Man sollte einfach den Ansatz wählen, mit dem man seine Probleme heute effektiv lösen kann. Ohne weitere Ideologien. Und dafür ist ein Ansatz wie der JBoss Server, den man in Tests oder Java SE Anwendungen einbetten kann, viel wichtiger als diese Standards. Obwohl auch er Spring meiner Meinung nach unterlegen ist...
Doch nicht so schlimm?Marc Fleury (JBoss)
hat gesagt, dass es doch OK sei, wenn jemand Training und Consulting für JBoss anbietet. Während dessen kann man im TheJBossIssueBlog lesen,
worum es ihnen geht. Schauen wir mal, was da noch passiert.
Professional Open SourceDie JBoss Geschichte ist mittlerweile im
Heise Newsticker und schlägt damit erhebliche Wellen. JBoss ist zuvor schon aufgefallen: Zum einen mit zahlreichen anonymen Postings in Foren, die JBoss loben und die Konkurrenz kritisieren und durch die starke Beeinflussung der EJB 3 Spezifikation, trotz des großen Interesses, die andere Middleware Hersteller in diesem Bereich auch haben sollten..
Was bedeutet TheJBossIssue nun? Eine Sache ist, dass Open Source nur eine Freiheit ist: Die Freiheit, an dem Produkt mitzuentwickeln. Es ist also im Falle von JBoss nicht die Freiheit, die Marke zu verwenden oder Dienstleitungen im Zusammenhang mit JBoss zu verkaufen. Und TheJBossIssue zeigt auch, dass es einen guten Grund dafür gibt, auch bei Open Source noch auf Standards zu setzen: Nur so hat man die Freiheit, das Produkt auch noch gegen ein anderes auszutauschen. Wer jBPM nutzt, kann eben nicht einfach auf eine andere Implementierung umsteigen. Und wer JBoss Produkte verwendet, wird wohl in Zukunft ein Problem haben, außerhalb von JBoss Inc. Services, Support und Training zu bekommen. Was letztendlich dann ein klassisches Vendor-Lock-In bedeutet.
Die andere Frage ist die Frage nach dem Open Source Geschäftsmodell. Ein positives Beispiel ist Linux: Linux definiert einen Marktplatz, auf dem zahlreiche Firmen im Wettbewerb um die beste Distribution und den besten Support stehen. Linux selbst gehört niemandem. Anders bei JBoss: Hier ist das Modell eher, die Software zu verschenken und den Markt im Bereich Services und Training zu monopolisieren. Das dadurch Entwickler abgeschreckt werden, ist wahrscheinlich nicht kritisch, da die wesentlichen Entwickler sowieso von JBoss Inc. bezahlt werden. Es geht gar nicht darum, dass irgendwelche Entwickler von außen partizipieren können oder sollen. Es geht nur darum, dass man für kostenlose Software exklusiv Services und Support leisten kann. Eine zuende gedachte Variante der zunehmenden Dominanz des Umsatzes von Services über den Umsatz mit Produkten: Produkte verschenken, Services monopolisieren und das ganze Open Source nennen.
Wie geht es weiter? Meiner Ansicht nach kann es gut sein, dass durch die jetzigen Geschehnisse FUD (Fear, Uncertainty and Doubt) erzeugt wird, was JBoss schaden kann. Wesentliches Element ist dabei nicht, dass Entwickler vom Mitmachen bei JBoss abgehalten werden, denn die wichtigen Entwickler werden sowieso von JBoss Inc bezahlt. Wichtig ist, dass klar wird, dass man sich mit JBoss auf einen Lock-In bei Services und Support einlässt und daher vorsichtig sein sollte. Das ist eine Argumentation, die auch auf Management Ebene wirken sollte. Das einzige Problem ist, dass sie Open Source ingesamt schaden kann, wenn sie das ganze Open Source Thema in Verruf bringt.
Die Konkurrenz steht in den Startlöchern und
hier kann man sehen, wer hinter dieser Konkurrenz steht. Und meinen Informationen zufolge werden wir bei Apache Geronimo in Zukunft noch einige weitere, interessante Entwicklungen sehen. Kann also gut sein, dass wir da in Zukunft eine Verschiebung sehen werden.
JBoss und OpenSource...Offensichtlich habe einige Leute inzwischen ein ernsthaftes Problem mit der Art und Weise, wie JBoss seine (oder vielmehr Marc Fleurys) Markenrecht durchsetzt. Die Story hat es bis auf
The ServerSide gebracht und wird von Rickard Ödberg unterstützt, den man als Mitentwickler von JBoss, XDoclet und AOP Guru kennt. Die Schlammschlacht ist allerdings
hier. Das lustige ist, dass es bei der Schlammschlacht auch mal wieder um Spring geht. Wann werden wir endliche wieder in Ruhe Java EE Applikationen entwickeln? Und warum kümmern wir uns um "JBoss vs. Spring" statt "Java EE vs. .NET"?
Die Fernsehsendung für den BeraterDie sehenswerte Sendung für den Berater ist
Super Nanny. Hier sieht man typisc Dinge in Aktion: Änderungen auf den Weg bringen und Dinge strukturieren. Die Parallelen sind erstaunlich...
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
