Java und Microsofts .NET konkurrieren in einigen zentralen Bereichen um die Gunst der gleichen Zielgruppe. Aber trotz der enormen Marketing-Anstrengungen von Sun und Microsoft haben sich die Anwender bis jetzt noch nicht mehrheitlich für eine Plattform entschieden.

Einer der wesentlichen Unterschiede zwischen .NET und J2EE besteht darin, dass .NET ein Produkt einer einzelnen, zugegebenermaßen großen Firma ist, während J2EE lediglich die Spezifikation eines Standards darstellt. Microsoft hat zwar Teile der eigenen Plattform bei der ECMA zur Standardisierung eingereicht. Dazu zählen etwa die Sprache C# und Teile der Common Language Runtime (CLI). Die nur halbherzige Offenlegung der Technologien und das Vorauseilen von Microsofts Implementierung gegenüber dem Standard dürften alternative .NET-Realisierungen jedoch zu einem schwierigen Unterfangen machen. Deshalb bedeutet die Entscheidung für .NET faktisch eine Bindung an Microsoft.

Dagegen konkurrieren bei der Java 2 Enterprise Edition (J2EE) mehrere Anbieter mit ihren Implementierungen: IBM und Bea kommen zusammen auf einen Marktanteil von über 50 Prozent, so dass sich der J2EE-Erfinder Sun gelegentlich Sorgen machen muss, bei der weiteren Entwicklung der Technologie die Kontrolle an den Branchenriesen IBM zu verlieren.

Ein wesentliches Kriterium bei der Entscheidung zwischen den konkurrierenden Technologien besteht darin, ob eine Anwendung auf verschiedenen Betriebssystemen laufen muss. Das wäre ein triftiges Argument für eine J2EE-Lösung, denn produktiv einsetzbare .NET-Implementierungen außerhalb der Windows-Welt gibt es noch nicht. Außerdem hängt über ihnen das Damokles-Schwert potenzieller Patentklagen durch Microsoft.

Wenn kein anderes Betriebssystem als Windows unterstützt werden muss, dann bietet .NET eine größere Auswahl verfügbarer Programmiersprachen. Derzeit existiert auch von Drittanbietern eine Vielzahl von Compilern, die Microsofts Intermediate Language (IL) produzieren können.

Sicherheit spricht für Java

Selbst bei grafischen Oberflächen fällt die Entscheidung wider Erwarten nicht eindeutig für Microsoft aus. Immerhin kann der Desktop-Monopolist .NET für Windows optimieren. Java hingegen möchte über verschiedene Systeme hinweg konsistente Benutzer-Schnittstellen bieten. Erhebliche Verbesserungen der Performance, die mit den letzten zwei Releases erzielt wurden, sowie reichhaltige Bibliotheken wie "Swing" und "Java 2D" empfehlen Java auch für komplexe Desktop-Anwendungen.

In einem anderen Punkt dürften Anwender dem Java-Lager wohl mehr zutrauen als Microsoft: In einer global vernetzten Welt gewinnt das Thema Sicherheit immer mehr an Bedeutung. Auch wenn .NET hier mehr Einstellmöglichkeiten als J2EE bietet, so verfügen viele Anwender schon über umfangreiche Erfahrungen mit J2EE. Die neu implementierte virtuelle Maschine von .NET muss hingegen im "echten" Einsatz erst noch ihre Tauglichkeit beweisen. Obwohl die .NET-Umgebung von externen Prüfern genau unter die Lupe genommen wurde, könnte sich der von Microsoft als Web-Server empfohlene Internet Information Server (IIS) erneut als Schwachstelle entpuppen. Seine in den letzten Jahren entdeckten Sicherheitsmängel sind mittlerweile Legion.

Ein wesentliches Kriterium für die Plattformentscheidung ist die Verfügbarkeit von modernen und komfortablen Werkzeugen. Beide Welten können in dieser Hinsicht mit einem reichhaltigen Angebot aufwarten, wobei auch hier Java eine größere Zahl von Anbietern vorweisen kann.

Einige Entwicklungsumgebungen sind als freie Software verfügbar, darunter das bereits erwähnte und von IBM stammende Eclipse oder Suns "Netbeans". Darüber hinaus existieren zahlreiche quelloffene Tools und Frameworks, die bekanntesten davon stammen von Apaches "Jakarta"-Projekt. Zudem verfügen sowohl .NET als auch J2EE über gute und bewährte Unit-Testing Frameworks.

Naturgemäß ist es zurzeit einfacher, erfahrene Entwickler für die bewährte J2EE-Plattform zu finden als für die neue .NET-Umgebung. Dies wird sich aber mit deren zunehmender Verbreitung ändern. Benötigt man eine enge Integration mit Microsoft-Produkten, neigt sich die Waagschale zugunsten von .NET, will man vorhandene Java-Bibliotheken nutzen, wird man J2EE den Vorzug geben.

Mitsprache der Programmierer

Da in zunehmenden Maße vorhandene Komponenten eingesetzt werden, nimmt die Bedeutung der Integrierbarkeit von Lösungen weiter zu. Durch Nutzung offener Standards kann man dafür Sorge tragen, dass die entwickelte Software sich den wechselnden Anforderungen anpassen kann.

In Debatten über Pro und Kontra einer bestimmten Plattform werden solche technischen Aspekte häufig überschätzt. Eine mindestens genauso wichtige Rolle spielen individuelle Bedingungen der Beteiligten. Dazu gehört an vorderster Stelle die Situation des Entwicklerteams. Eine eingespielte Mannschaft kann über lange Zeit kontinuierlich hohe Leistungen erbringen, wenn sie in einer motivierenden Umgebung die Chance bekommt, kreativ tätig zu werden. Dazu gehört auch das Vertrauen der Chefetage in die technische Kompetenz der Programmierer, auch und gerade bei Entscheidungen über die einzusetzende Entwicklungsplattform.

Deshalb hat es wenig Sinn, ein erfolgreiches Java-Team auf .NET umzupolen oder umgekehrt. Auch wenn fähige Programmierer in beiden Umgebungen sehr gute Ergebnisse erbringen können, zieht die Umstellung zumindest vorübergehend einen Produktivitätsverlust nach sich.

Marktbeobachtungen belegen daher, dass sich immer mehr Unternehmen für eine "friedliche Koexistenz" von J2EE und .NET entscheiden. Die in der Vergangenheit oft leidenschaftlich geführte Diskussion um eine ausschließliche Entscheidung für J2EE oder .NET verliert immer mehr an Brisanz. Nicht nur an der Börse gilt die Devise, dass Diversifikation der Einsätze das Risiko vermindert.

Offene Standards beachten

Durch die konsequente Verwendung von Standards können die beiden Konkurrenten viel dazu beitragen, die Koexistenz der Systeme zu vereinfachen und Anwendern damit Kosten zu sparen. Eine zentrale Rolle bei der Kommunikation von Java- und .NET-Anwendungen spielen Web-Services. Über diese können Applikationen in einer von der Plattform und Programmiersprache unabhängigen Art und Weise auf angebotene Funktionen zugreifen. Diese plattformübergreifende Technologie stellt beispielsweise Lösungen in Aussicht, wo ein .NET-Client unter Windows einen mit J2EE und Oracle implementierten Web-Service nutzt.

Das Thema Integration ist aber nicht nur wichtig, wenn es um die transparente Kommunikation zwischen J2EE und .NET geht. Die aktuellen Bemühungen um konsolidierte Systeme benötigen auch im Backend die Fähigkeit, verschiedene Welten zu integrieren. Auch hier empfehlen sich Web-Services als ein bevorzugtes Integrationsmedium.

Fazit

Die Entwicklung hochwertiger Software ist eine schwere und kreative Arbeit. Dies wird sich auch in naher Zukunft nicht ändern. Wirklich gute Programmierer können auftauchende Klippen auf allen Plattformen umschiffen und sollten auch die Kompetenz haben, von Fall zu Fall bei der Entscheidung über einzusetzende Programmiersprachen, Plattformen, Produkte und Tools ein gewichtiges Wort mitzureden.

Neben den beiden großen kommerziellen Applikationsplattformen empfehlen sich für viele Probleme Skriptsprachen wie Perl, Python oder Ruby als nützliche Werkzeuge. Sie spielen auch in vielen Großprojekten eine wichtige Rolle.

Hohe Produktivität und Effizienz im eigenen Unternehmen ist insgesamt wichtiger, als vermeintlich auf Nummer Sicher zu gehen, indem man das einsetzt, was auch die Konkurrenz benutzt. Wer weiß schon, wie lange es die Konkurrenz noch gibt? (ws)

*Claus Jandausch ist Senior Systemberater System-Plattform bei der Oracle Deutschland GmbH.

Kein "Entweder - oder"

Die anfangs häufig emotional geführte Debatte über die richtige Anwendungsplattform weicht zunehmend einer pragmatischen Haltung. Die meisten größeren Unternehmen werden sowohl Java als auch .NET verwenden. Die Entscheidung für eine Technologie sollten Unternehmen von einer Reihe weicher Faktoren abhängig machen. Dazu zählen unter anderem der vorhandene Know-how der Entwickler sowie die spezifischen Anforderungen eines Projekts.

Abb: Anwender wollen sich nicht festlegen

Die meisten größeren Firmen dürften sich auch in Zukunft nicht für eine der beiden Plattformen entscheiden. Quelle: Giga Information Group, 2001