JAVA oder .NET?

Zitat von atrox

leider spielen bei der wahl der programmierplatform aber alzu oft keine ethischen oder technischen gründe, sondern wirtschaftliche und ´politische´ eine übergeordnete rolle. ;(

kann ich nur voll zustimmen!

Zitat von the.sh3ll

.Net Stärken:

• Schnelle Lernkurve für einfache bis mittelschwere Dinge.
• Ausgezeichnete Entwicklungsumgebung mit entsprechend guten Tools. (OK, Fehlerhafte Software gibt es überall, aber im Prinzip ist's sehr gut.)
• Extreme Bindung an nur einen Hersteller (Sicherheit, Stabilität, Kompatiblität).

.Net Schwächen:

• Erlaubt es perfekt, leichtere Applikationen zu entwickeln, die man dann immer mehr erweitert, bis ein völliges Durcheinander entstanden ist. Mag hart klingen, aber in der Praxis wird man wirklich sehr dazu verleitet.
• Versteckt viel vor dem Programmierer, der manchmal im Dunkeln tappt, was da eigentlich so wirklich am Server vor sich geht.
• Extreme Bindung an nur einen Hersteller (Fehler, Support).
• Unzureichendes Konzept für Zugriff auf Datenbank, bzw. einzig sinnvolle Möglichkeit für performanten Zugriff sind Stored Procedures, auf die direkt zugegriffen wird.

J2EE Stärken:

• Sehr gute Skalierbarkeit (wenn man's richtig macht:-)
• Umfangreiche Bibliotheken.
• Eignet sich hervorragend um neue Technologien und Konzepte im Serverbereich zu lernen, da vieles genau definiert und spezifiert ist.
• Sehr gute Tools für CASE-Softwareentwicklung oder Refactoring-Liebhaber (Eclipse etc.)
• Viele Gratis-Tools von sehr guter Qualität (Ant, JUnit).
• Erlaubt es viele Konzepte moderner Softwareentwicklung relativ einfach zu lernen (wenn man systematisch vorgeht), wie etwa Extreme Programming, Refactoring, Cluster-Techniken, Message-Services etc.
• Für den einzelnen Programmierer eine hervorragende Möglichkeit seine Fähigkeiten zu erweitern.
• Nicht nur teure Software steht zur Verfügung, auch sehr günstige (JBoss, Eclipse).
• Keine Bindung an einen Hersteller.
• Entity Beans für gewisse Applikationen.

J2EE Schwächen:

• So umfangreich und so viel zu lernen, daß viele Programmierer oft überfordert sind.
• Bessere Schulungsprogramme durch die Geschäftsleitung wären hier hilfreich.
• Noch relativ kompliziert, bessere Tools, die mehr können, wären praktisch. Das ist allerdings nicht nur ein Nachteil von J2EE, gilt für alle derartigen Serverapplikationen - Microsoft versteckt's nur besser.
• Entity Beans werden oft nicht sinnvoll eingesetzt

http://www.javaworld.com/javaworld/...-j2eevsnet.html
http://www.agila.info/infos/j2ee-versus-dotnet.htm

imho haben beide Technologien Stärken und Schwächen und schließlich hängt es vom Können des Entwicklers ab wie gut er diese umsetzt.

Was verstehst du unter Skalierbarkeit und warum sind .NET Apps nicht skalierbar ?

Das mit keine Bindung an den Hersteller ist Realitätsfremd bei Java. Ich hab mich schon einige Male mit einem wirklich guten Java-Entwickler über das Thema unterhalten und im Endeffekt ist die Plattformunbahängigkeit in der Praxis nicht mehr gegeben, da die Entwickler dann immer die Erweiterungen des Java Servers verwenden.


Bezüglich Bindung an den Hersteller und Support. Wo liegt das Problem bei Microsoft und Support ? Got MSDN ?

Zitat von AngelOfDeath

Ich bin deiner Meinung!! Was ich ankreiden wollte war, dass Guid und DateTime in .NET nicht null sein können. In der Datenbanken können Fremdschlüssel null sein, nur in .NET gibts für Guids kein null, sondern nur ein Guid.Empty.

Nur um Irrtümer auszuschliessen, ich halte alle meine DB Daten in Datasets, und dann kann ich eben genau so drauf zugreifen, wie beschrieben.

Zitat von AngelOfDeath

Auch da stimme ich zu. Bei Internetapplikationen muss man verbindungslos arbeiten. Das Problem ist, dass ich aber diese Eigenschaft nicht deaktivieren kann, sondern auf das alte ADO angewiesen bin.

Ich bin der Meinung das es auch in Win Programmen nicht wirklich Sinn macht. (mag persönliche Preferenz sein,..) Vielleicht versteh ich das Problem nicht richtig, aber auch hier kannst du die DataSet Funktionen (Refresh, Restore,...) verwenden.

Zitat von Jedi

OpenGL und nicht 'state-of-the-art'???
*würg*

Ich kenn mich jetzt auf dem gebiet nicht so gut aus aber was ich gelesen hat unterstützt OpenGL in der jetztigen Form keine Pixel und Vertex Shader. Um diese aber trotzdem zu benutzen muss man für jeden Chip einen eigenen Code schreiben (sog. Extensions).
Bei DirectX ist dies nicht der Fall ... darum arbeiten die meisten Herstell auch nur noch mit DirectX.

Zitat von spunz

spielzeug => directx

profi anwendungen => opengl

so würd ichs auch sehen