Java vs. .Net - nicht schon wieder?

Wieder einmal finde ich in einer Newsgroup Diskussion "Java vs. .Net". oder umgekehrt. Dabei ist natürlich nicht die Programmiersprache gemeint (bei .Net macht das ja auch wenig Sinn), sondern das damit jeweils verbundene Umfeld. Und wieder finden wir die üblichen Spiele zwischen den jeweiligen Favoriten der Fangruppe. Allzu leichtfertig gehen Argumente wie "plattformübergreifende Technologie" und ähnliches von der Hand. Ich zitiere mal ein paar Sätze, die man inzwischen allzugut kennt.

• "man sollte sich nicht von den Zukunftsaussichten einer Technologie leiten lassen"
• "Zukunftssicherheit ist bei beiden gleich groß."
• "Sollten die Programme irgendwann auch mal auf anderen Systemen laufen, dann bevorzugt sich Java, das es auf sehr vielen Platformen verfügbar "

Wie immer gibt es dann Einschätzungen, welche Technologie die kürzere Erstellungszeit, die geringeren Wartungskosten oder das bessere Laufzeitverhalten hat. Daraufhin folgt der ratlose Ratschlag, die Technologie zu verwenden, von denen man oder die Herstellerfirma am meisten Ahnung hat. Diesen finde ich abstrus und wäre die Menschheit danach gegangen, würden wir heute noch mit Steinwerkzeugen arbeiten, denn damit kannte sich die Menschheit von Anfang an am besten aus. Weiterentwicklungen können parallel stattfinden und eine andere Technologie kann soweit auf der Überholspur sein, dass sich der Invest eines Neulernens und Umsteigens durchaus lohnen kann.

Persönlich bin ich vor etwa zwei Jahren von Java auf .Net umgestiegen, weil ich die Stagnation und das langsame Vorankommen in dem Umfeld der mit Java verbundenen Technologie zu langweilig empfunden habe. Schaue ich mir aktuell XUL und XAML im Vergleich an, dann weiß ich wieder warum. Und was das Umlernen betrifft? Nun, ich habe es innerhalb von einem halben Jahr von einem Java Experten zu einem .Net WPF Experten geschafft und ich zweifel nicht daran, dass das jedem gelingen kann, der sich ambitioniert mit einer aufregenden und spannenden Technologie auseinander setzen will.

Und ist das nun eine Empfehlung für .Net als Technologie?

Nein, absolut nicht. Es ist nur die Empfehlung, die ganzen uralten altbackenen Argumente und die persönlichen Vorlieben der Entwickler zu ignorieren, sondern für das Hier und Jetzt eine Entscheidung zu treffen, auf Basis der reinen Leistungsfähigkeit der Technologie für die bekannte Zielplattform und die gewünschte Anwendung bei geringen Laufzeitkosten.

Persönlich favorisiere ich in vielen Fällen einen Rich Internet Client oder Smart Internet Client, der auf Basis von .Net konstruiert ist und seine Laufzeitdaten von einem Dienst erhält. Ob dieser Dienst auf einem Server, auf dem gleichen Client implementiert ist, ist mir genauso egal wie die Sprache oder Technologie, in der dieser Dienst konstruiert wurde.

Warum ich das bevorzuge?

Weil die Entscheidung einen Dienst zu konstruieren völlig unabhängig von der Präsentation auf dem Client geschehen kann. Hier kann erneut geprüft werden, welche Technologie für die gewählte Plattform die besten Leistungen bei den gerinsten Kosten erbringt. Durch die Entkopplung erreiche ich Unabhängigkeit und kann die Releasezyklen auch den Plattformen anpassen (bekanntermaßen dreht sich das Rad bei Servern etwas langsamer).

Warum ich das hier schreibe?

Nunja, etwas Frustbewältigung über die erschreckend immer wieder gleiche Diskussion ist schon dabei