JavaSpektrum April/Mäi 2005 [antikvár]

I ''""" T Editorial In Java veritas ^ Schon bei der Identifikation mit ih-^rem eigenen Fachgebiet neigen Informatiker zu einer ausgeprägten Persönlichkeitsspaltung. Lässt sich ihre Arbeit nun als Kunst, Handwerk, Wissenschaft oder Ingenieurstechnik betrachten? Aber auch im Arbeitsalltag stehen Softwareentwickler nicht gerade auf sicherem Fundament. Fast kein anderes Gebiet ist von solch emotionsgeladenem und geradezu religiösem Eifer durchsetzt. Welche Technologie ist nun die beste, welche Plattform die effektivste, welche Architektur die richtige, welches Paradigma das zukunftsträchtigste oder welche Programmiersprache die eleganteste? Leider ist auch Java keine Insel der Glückseligkeit. Wer durch die verschiedenen Fachmagazine blättert, gelegentlich Konferenzen besucht, mit Fachkollegen kommuniziert oder die von unendlicher Weisheit geprägten Aussagen mancher Marktanalysten recherchiert, mit denen sich Manager dann oft gezielt zu bewaffnen pflegen, dürfte schon bald bemerken, welch unterschiedliche Perspektiven existieren. Nach dem Prinzip „steter Tropfen höhlt den Stein" mutieren Halb- und Unwahrheiten bisweilen zu vermeintlichen Wahrheiten, die sich erst durch kontinuierliche Wiederholung persistent als Fakten in unser Weltbild verankern. Mancher Paradigmenwechsel kommt erst dadurch zu Stande, dass sich die vermeintlichen Wahrheiten in ihrer wahren Gestalt offenbaren. Um diesen Aussagen mehr Nachdruck zu verleihen, möchte ich an dieser Stelle ein paar symptomatische Beispiele aus der Welt rund um generelle Softwareentwicklung und Java aufzählen: ˇ Aussage 1: „Java/EJB/Swing/ ist zu langsam". Bei Statements dieser Art ist erhöhte Wachsamkeit angebracht. Von wem stammt die Aussage, wie kann er sie verifizieren und welchen konkreten Kontext setzt sie implizit voraus? Leider halten sich derartige Behauptungen oft jahrelang hartnäckig, auch wenn ihnen längst jede Basis fehlt. Eine gesteigerte Form davon stellen Performanz-messungen dar, weil sie den Anschein der wissenschaftlichen Analyse vermitteln. Benchmarks verhalten sich oft zur Wahrheit in gleicher Weise wie statistische Umfragen. Wer die richtigen Fragen stellt, erhält auch die gewünschten Antworten. Aus meiner Erfahrimg als Softwarearchitekt lassen sich solche Aussagen fast nie verifizieren, sondern stattdessen auf völlig andere Ursachen zurückführen. Speziell zwei Fallstricke sind häufig zu beobachten. Fallstrick 1: Das Problem liegt in der zugrunde liegenden Architektur, aber die verantwortlichen Entwickler geben den verwendeten Technologien die Schuld. Fallstrick 2: Entwickler nutzen Technologien in einem dafür gar nicht vorgesehenen Kontext. Oder würden Sie einen Schraubenzieher verwenden, um einen Nagel in die Wand zu schlagen? ˇ Aussage 2: „Mit modellgetriebenen Ansätzen wie MDA lässt sich in Zukunft eine komplette Automatisierung der Softwareentwicklung erreichen". Im Grunde genommen handelt es sich hier um ein in variierender Verkleidung verbreitetes Versprechen. Erinnern Sie sich noch daran, dass bereits andere Ansätze, wie zum Beispiel Frameworks, uns ähnliche Zukunftsszenarien prophezeit haben. Tatsache aber bleibt, dass die Komplexität der meisten Domänen es geradezu unmöglich macht, eine komplette Abdeckung durch eine domänenspezifische Sprache zu erzielen. Außerdem gibt es bei der Erstellung lind der Umsetzung einer Softwarearchitektur stets mehrere Domänen, die orthogonal ineinander greifen oder miteinander in Beziehimg stehen. Die Komplexität der Softwareentwicklung verlagert sich durch modellgetriebene Ansätze zwar von systemnahen Ebenen zu höheren domänenspezifischen Abstraktionsebenen, verschwindet aber nicht. Nichtsdestotrotz fungieren Technologien wie modellgetriebene Ansätze, Aspektorientierung, Frameworks und Entwurfsmuster als essentielle und unverzichtbare Bausteine, um Komplexität beherrschbar zu machen. Apropos: Habe ich Ihnen bereits vom Gödel'schen Unvollständigkeitssatz erzählt? ˇ Aussage 3: „Die Softwareentwicklung ist in ihrem Reifegrad von anderen industriellen Gebieten hoffnungslos entfernt. Ein Beispiel ist die systematische Wiederverwendung und Komposition von Standardbausteinen, etwa ICs, zur Steigerung von Qualität und Produktivität". Diese Aussage finden Sie in unterschiedlicher Form regelmäßig in Keynotes und Fachartikeln. Mit solchen Kommentaren lässt sich meistens schnell Zustimmung beim Publikum erheischen. Leider erfolgt hier ein Vergleich von Äpfeln mit Birnen. Softwarebausteine basieren auf nicht messbaren Konzepten, während die Entwicklung etwa von ICs auf Basis physikalischer Größen erfolgt. Im Gegensatz zu ihren Pendants stehen Softwarekomponenten einer wesentlich größeren Zahl nicht-funktionaler Eigenschaften gegenüber, die sie zu erfüllen haben. Und zu guter Letzt unterliegt der Anwendungskontext eines Softwarebausteins einer um Größenordnungen höheren Flexibilität und Variabilität. Bei genauerer Betrachtimg hinkt der Vergleich also erheblich. Das sind wohlgemerkt nur wenige exemplarische Aussagen, sozusagen ein pars pro toto. Warum ich Ihnen all das erzähle? Jahrelang galt das Vorurteil, die Java-Plattform würde sich nicht für Endgeräte mit beschränkten Ressourcen oder hohen operativen Anforderungen eignen. Viele Produkte wie zum Beispiel Handys, Navigationssysteme oder das Mars-Ro-ver-Projekt der NASA haben mittlerweile die Einsatzfähigkeit von Java auf mobilen und embedded Plattformen bewiesen. Trotzdem behaupten einige Zeitgenossen immer noch unverzagt das Gegenteil. Ihr Michael Stal