Thomas Darimont's Blog

Kaum hatte ich meinen letzten Blogpost abgesetzt kam Norbert schon entsprechend gecontert

Thomas hat in seinem Beitrag Neuer Fokus: Java & .NET kund getan, warum in seinen Augen Java .NET vorzuziehen ist bzw. warum er das persönlich tut. Ich kann dem in einigen Punkte nicht ganz zustimmen.

Das war nur eine kleine Liste

@2: Die .NET Community selbst ist mittlerweile sehr groß und wächst und wächst. Daher würde ich die Community-Größe nicht als Vorteil werten, denn in der .NET Community ist für jedes Problem eine Lösung zu finden.

Ich denke die Größe und vor allem die Erfahrung der Community spielt sehr wohl eine Rolle um den aktuellen "Marktdurchdringungsstatus" (Randerscheinung oder schon Commodity) einer Technologie zu beurteilen.
Außerdem hab ich ja nicht gesagt das es in der .Net Community keine guten Lösungen für Probleme gäbe

@4: Diesen Punkt kann ich so nicht teilen. Ich arbeite täglich mit Visual Studio 2005 in Kombination mit VSS und einer Solution mit über 100 Projekten. Dabei konnte ich keinerlei Probleme registrieren. Ausgangssystem: Dell Inspiron 9400, Intel T2400 @ 1.83 GHz, 2 GB RAM.

Auch bei uns gibt’s rund 50 Teilprojekte in einer Solution. Was bei VS IMHO sehr langsam ist, ist der XML Schema Editor (bei mehrere tausend Zeilen XML Schema wartet man schon mal ein Weilchen, sogar dann wenn man sich nur den Code anschauen möchte). Weiterhin sind die grafischen Designer zuweilen recht Träge (wobei man fairer Weise auch sagen muss das da auch teilweise einige Thirdparty Komponenten Schuld sind die dazu geladen werden -> Infragistics). Außerdem bekomme ich merkliche Geschwindigkeitseinbußen sobald ich mehr als 20-30 .cs Files im Editor offen habe. Da macht Eclipse deutlich mehr mit ohne zu mucken.

Du hast damit recht, dass es viele Projekte zu den unterschiedlichsten Bereichen gibt. Was du allerdings wieder vergisst ist, dass es Bereiche gibt, in denen .NET Java einiges voraus hat: In vielen Bereichen muss bei Java auf 3rd Party Produkte (ob kommerziell oder OpenSource ist hier nebensächlich) zurückgegriffen werden. WPF, WCF, CardSpace, WF etc. sind hier Stichwörter, wo Java nicht einmal ansatzweise etwas mitbringt. DAS ist für mich ein wesentlicher Nachteil. Ganz klar, diese Dinge sind bei .NET noch nicht so ausgereift, wie sie sein sollten (da sehr neu), aber damit ist man definitiv einen wesentlichen Schritt weiter.

Dem stimme ich (natürlich ) nur zum Teil zu. Ich empfinde es überhaupt nicht als Nachteil wenn ich Thrid-Party Komponenten benutze. Ich bin sogar sehr froh drum das ich ich Java die Auswahl habe und nicht immer auf eine Implementierung festgenagelt bin. Das Problem bei vielen verschiedenen Third-Party Bibliotheken ist es oft diese vernünftig zusammenzubringen / zu integrieren. Hier helfen natürlich solche Integrationsframeworks wie das Springframework welches schon entsprechende Unterstützung für zahlreiche Third-Party Bibliotheken / Frameworks bietet. Die Frage, ob ich nun für einen Webservice AXIS oder XFire verwenden will ist dann fast gar kein Problem mehr...

.Net: WCF -> Java: RMI-JRMP, RMI-IIOP,JAX-RPC, bzw. neuerdings JAX-WS sind Java Standards für Remoting die du auch out-of-the Box nutzen kannst insbesondere in Java 6 ist alles Integriert um kleine Webservices zu schreiben. Die Fremdprodukte wie AXIS, XFire, Hessian, Burlap, Spring HTTP Invoker bieten hier nur mehr Komfort und ein wenig mehr Funktionalität

WPF ist ja eigentlich "nur" neues ein grafisches Subsystem zur Erstellung von Benutzeroberflächen ( auch XML basiert über XAML) mit Support für Animationen / 2D- / 3D-Grafik etc.
Die bekannten Benutzeroberflächen-Frameworks die von Haus aus bei Java dabei sind AWT und Swing. Wobei das AWT (AFAIK) nicht mehr großartig weiterentwickelt wird womit wir bei Swing wären. Vergleicht man die heutigen Möglichkeiten von Swing mit denen von WPF muss man ganz klar sagen, dass WPF an dieser Stelle um einiges mächtiger ist, zumindest im Bereich Databinding, und XML basierte UI.
Nimmt man jedoch die von zahlreichen OpenSource Projekten angebotene Funktionalität in Anspruch steht man WPF in Sachen Funktionalität in nichts nach.
Da gibts dann XML UI-Frameworks, DataBinding Frameworks, Animation Frameworks, 3D Support (Direct3D, OpenGL), Support für Vektorgrafik etc., Auch die Interoperabilität via ActiveX / OLE ist heute für Java kein Problem.

Wer jetzt glaubt das das sooo viele Frameworks sind... teilweise sind die verschiedenen Frameworks schon zusammengeschmolzen und werden nun als ein Paket angeboten (bzw. werden sogar in Swing eingebaut, beispielsweise so geschehen mit JDIC (Java Desktop Integration Components)).

Des weiteren gibt es ja noch Alternative Windowing Toolkits wie beispielsweise das SWT (Standard Widget Toolkit) auf dem das Eclipse UI basiert die mit dem JFace Aufsatz (+ die ein oder andere Zusatzbibliothek) so ziemlich alles bietet was WPF auch kann, btw. die neueste SWT Version unterstützt übrigens auch WPF

.Net: WF - Java : http://java-source.net/open-source/workflow-engines
Aber hier stimme ich dir wieder zu, im Java Standard gibt es keine Workflow Engine. Dafür gibt es aber ausreichend viele freie Open Source Workflow Engines / Rule Engines die man ohne Probleme in eigene Produkte integrieren kann.

.Net: CardSpace - Java: ****?
Also wenn man CardSpace als IdentityManagement / SSO Lösung sieht so gibt’s auch dafür in Java entsprechende Unterstützung in Form von Open Source Projekten siehe:
http://blog.doubleslash.de/2007/02/27/shiny-identity-management-projects-in-opensource-universe/

Des weiteren ist hervorzuheben, dass .NET das wesentlich neuere Framework ist, daher auch einige Punkte besser umgesetzt sind (da eben aus den Erfahrungen mit Java gelernt). Fehlende Dinge, wie beispielsweise Checked Exceptions, wurden absichtlich nicht implementiert, da es derzeit keinen Weg gibt, eine wirklich saubere Implementierung durchzuführen. Java bietet hier eine Implementierung, allerdings keine gute.

Also es ist ja nicht so, dass Java stehen geblieben wäre Genauso wie sich das .Net Framework von 1.0/1.1 über 2.0 nun zu 3.0 weiterentwickelt gibts nun ja auch schon Java 6 . Dafür das viel von Java gelernt wurde spricht u.a. auch dass der C# Spracherfinder Anders Hejlsberg vorher auch u.a. für J++ (das Java Derivat von Microsoft) verantwortlich war http://www.it-visions.de/glossar/dotnet/282/Anders%20Hejlsberg.aspx
Außerdem wurden viele Sachen in erster Linie "by Design" anders Implementiert. Ob das nun wirklich besser war muss jeder selber sehen.
Bestes Beispiel hierfür sind die Generics. In .Net sind Generics eher starr und zur Laufzeit verfügbar (es wird für jeden generischen Typ bei bedarf ein entsprechend "fest" getypedter Typ erzeugt, somit stehen die Typ-Informationen dann eben auch im IL-Code drinnen). In Java werden Generics über type-ereasure Implementiert. D.h. dass sie eigentlich nur für den Java Compiler sichtbar sind. Zur Laufzeit sind keinerlei (bzw. kaum) Informationen über generische Typen vorhanden. Diese Generics Implementierung hat jedoch den Vorteil, das man hier auch mit Wildcards arbeiten und so sehr flexibel Typisieren kann (was das ganze aber auch beliebig kompliziert werden lässt).

Dann sag doch mal bitte wo hier die Nachteile der Checked-Exception Implementierung in Java liegen

Was mir an den Checked Exceptions in java nicht gefällt hat weniger mit ihrer Implementierung als vielmehr mit mit ihrer Verwendung zu tun... so werden im Standard API beispielsweise Checked Exceptions auch dann geworfen, wenn der API Verwender nichts "vernünftiges" damit anfangen kann. Hätte man in diesen Fällen auch entsprechende Unchecked (RuntimeExceptions) gesetzt, so würden sich da schon weniger Leute drüber aufregen . Zum Thema Checked / Unchecked Exceptions gibts hier und hier ein wenig mehr "Zündstoff".

Zusammenfassend:
Man muss bestimmte Dinge aus unterschiedlichen Blickwickeln betrachten. Thomas favorisierst ganz klar Java. Gut, akzeptiere ich. Aber dann sollten keine Punkte aufgeführt werden, die so nicht ganz stimmen bzw. die nicht vollständig sind.

Okay, sehe ich ein. Aber ich hab ja auch ganz klar gesagt das ich da in folgenden Posts etwas Detaillierter rauf eingehen werden (wie jetzt schon zum Teil passiert)
Brauchte eben selbst so was wie ne kleine Initialzündung für mögliche Blog-Themen

Alles in allem sollte das ganze auch nicht heißen Java vs. .NET sondern Java UND .Net Selbst die beiden großen Microsoft und Sun haben mittlerweile eingesehen, dass die große Ziel nicht Alleinherrschaft sondern Integration bzw. Interoperabilität heißt. Also bitte das ganze nicht als ein gegen- sondern als ein friedliches und vor allem konstruktives miteinander sehen