sliver33
Big d00d
|
Oder sollte es heißen SUN vs. M$?
Postet mal eure Meinungen über JAVA und .NET und schreibt auch dazu was zukunft hat und was nicht?
|
Painter
.
|
hmm... weder noch.... das eine weil wenn dumm gecoded zu gefährlich und das andere weil von M$  lamp is lamp, bleibt lamp und wird niemals lamj
|
sliver33
Big d00d
|
Was meinst mit "dumm gecoded zu gefährlich"???
|
Painter
.
|
wemma mit an saudeppat gschriebenenen site an server zum stillstand bzw a database zum verrecken bringt .... dann stuf i des (fur an produktionsserver) als gefährlich ein.... d.h. wemma selbst weiss was die site anfordern soll, dies kontrolliert und erst dann die site freigibt ... dann is es ja ok nur wann so a halbhiafla mit ftp-zugang sein neuestes werk aufspielt und kane 5 minutn später es telefon klinglt.... dann hat entweda da admin ganz krass wals falsch gemacht... oder es war eben grad wie in 99% der fälle a superdau am werk... auf unsere produktionsserver hamma ned mal mehr jserv drauf *schande*... aba dafür hama für de denen perl zu langsam und php zu aufwendig is halt volle asp unterstützung unter unix
|
sliver33
Big d00d
|
stimmt schon aber web is nicht des einzige anwendungsgebiet von java
|
Painter
.
|
klar... inter-, intra-, extra- .... apps, ..... nur in java.... schön is plattformübergreifend.... für java-apps gibts ja viele gute beispiele... von office-suiten bis was weiss ich was.... nur was hat .net vorzuweisen aussa katastrophale lizenzpolitik?? also wennstas für apps verwenden willst... klar... nur da is .net ja ka konkurrent
|
orpheus
in a nutshell
|
.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.htmlhttp://www.agila.info/infos/j2ee-versus-dotnet.htmimho 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.
Bearbeitet von orpheus am 22.04.2003, 18:30
|
sliver33
Big d00d
|
du bringst es auf den punkt ... die frage is jetzt nur welche der beiden Technologien sich durchsetzen wird
Meiner Meinung nach hat .NET bei Apps die Nase vorne weil M$ bei Windows in Zukunft .NET gleich mitliefert. (JAVA muss man extra installieren, was einige anwender (DAUs) davon abhält)
JAVA ist auf jedenfall ausgereifter und sicherer als .NET aber ob das reicht wird die Zukunft zeigen. was haltet ihr davon?
|
that
Hoffnungsloser Optimist
|
vielleicht an schlechten Prozzi erwischt
Ist ADO.NET nicht brauchbar? bzw. warum? Ansonsten: tolle Liste. Ein bisher nicht angesprochener Nachteil von Java ist, dass es (offiziell) nur eine Programmiersprache gibt, während .NET mehrere hat... (böse Zungen behaupten, das ist alles C# in verschiedenen Maskierungen; teilweise haben sie vermutlich auch recht). Ich hab bisher noch keine Ahnung, was sich wirklich durchsetzen wird - Java, .NET, oder doch zurück zu Native Code?
|
sliver33
Big d00d
|
Ich glaube Native code ist für die applikationen bald ausgestorben, weil die computer immer schneller werden und auch die Programmiersprachen immer mächtiger (3D Funktionen, ...) Da fallt ma grad ein Vorteil für .NET ein (  ): 3D Spiele kann man dank directX nur in .NET programmieren ... sicher gibts für JAVA auch OpenGL APIs aber OpenGL is halt nicht mehr state-of-the-art.
|
that
Hoffnungsloser Optimist
|
So lange es für .NET bzw. die JVM keine Sprache gibt, die wirklich höher als C++ ist (oder zumindest mithalten kann), bleibe ich bei Native Code. Ich sehe einen Trend zu DSLs, Scriptsprachen (Javascript, Perl, PHP, ...) und XSLT. Und natürlich Java und C# bzw. VB.NET für die ganzen Nicht-Programmierer.
|
Jedi
PROGrAMmER
|
Da fallt ma grad ein Vorteil für .NET ein ( ): 3D Spiele kann man dank directX nur in .NET programmieren ... sicher gibts für JAVA auch OpenGL APIs aber OpenGL is halt nicht mehr state-of-the-art. OpenGL und nicht 'state-of-the-art'??? *würg*
|
AoD
aka AngelOfDeath
|
Ist ADO.NET nicht brauchbar? bzw. warum? ADO.NET ist der größte scheiß! ich schreib a mehrbenutzer applikation und es muss jeder benutzer die gleichen daten sehen. wenn also User1 die Daten ändert, sieht User2 sofort dies. ADO.NET ist aber verbindungslos, sprich ich bekomme keine änderungen mitgeteilt. Schön wäre es, wenn es eine option gebe, damit ich das abstellen kann, gibt es aber nicht. Einzige Alternativ ist die Verwendung des alten ADO. und zum .NET generell: In der Schule machen wir unser Maturaprojekt in C#. Schon mal wer mit DateTime + Guid sowie Datenbanken gearbeitet? Ein Objekt des Typs Guid darf nicht null sein. Möchte man aber NULL darstellen, so muss man die Konstante Guid.Empty benutzen. Speichert man nun Guid.Empty in die Datenbank, wird aber nicht null gespeicher, sondert eine Guid mit lauter Nullen, das heißt bei jeder Guid muss ich eine Umwandlung nach dem Lesen und vor dem Schreiben vornehmen. DateTime hat in .NET den Bereich von 01.01.0001 bis 31.12.9999 und kann ebenfalls nicht NULL sein. Wir dachten uns, speichern wir halt DateTime.MinValue um anzuzeigen, dass wir NULL wollen. Der SQLServer kann aber nur den Wertebereich von 1759 - 9999. Also mussten wir DateTime.MaxValue verwenden. Diese beiden Beispiele alleine zeigen, dass MS eigene Produkte inkompatibel zueinander sind. Sollte mal eine Entscheidung zwischen .NET und Java nötig sein: BITTE NEHMTS JAVA. MACHTS ES EUCH NICHT UNNÖTIG SCHWER. (von der unzureichenden Dokumentation und den Schwierigkeiten beim Konfigurieren eines SQLServers + IIS # Frontpage Server Extensions will ich mal gar nicht reden)
|
that
Hoffnungsloser Optimist
|
ich schreib a mehrbenutzer applikation und es muss jeder benutzer die gleichen daten sehen. wenn also User1 die Daten ändert, sieht User2 sofort dies. ADO.NET ist aber verbindungslos, sprich ich bekomme keine änderungen mitgeteilt. Schön wäre es, wenn es eine option gebe, damit ich das abstellen kann, gibt es aber nicht. Einzige Alternativ ist die Verwendung des alten ADO. Hm, ich kenn mich mit den MS Sachen zu wenig aus, aber woher weiß das alte ADO, dass sich am Datenbankserver die Daten geändert haben und dass sich die Liste auf allen Clients automatisch refreshen soll?
|
Yeahman
OC Addicted
|
ADO.NET ist der größte scheiß! ich schreib a mehrbenutzer applikation und es muss jeder benutzer die gleichen daten sehen. wenn also User1 die Daten ändert, sieht User2 sofort dies. ADO.NET ist aber verbindungslos, sprich ich bekomme keine änderungen mitgeteilt. Schön wäre es, wenn es eine option gebe, damit ich das abstellen kann, gibt es aber nicht. Einzige Alternativ ist die Verwendung des alten ADO.
und zum .NET generell: In der Schule machen wir unser Maturaprojekt in C#. Schon mal wer mit DateTime + Guid sowie Datenbanken gearbeitet? Ein Objekt des Typs Guid darf nicht null sein. Möchte man aber NULL darstellen, so muss man die Konstante Guid.Empty benutzen. Speichert man nun Guid.Empty in die Datenbank, wird aber nicht null gespeicher, sondert eine Guid mit lauter Nullen, das heißt bei jeder Guid muss ich eine Umwandlung nach dem Lesen und vor dem Schreiben vornehmen. DateTime hat in .NET den Bereich von 01.01.0001 bis 31.12.9999 und kann ebenfalls nicht NULL sein. Wir dachten uns, speichern wir halt DateTime.MinValue um anzuzeigen, dass wir NULL wollen. Der SQLServer kann aber nur den Wertebereich von 1759 - 9999. Also mussten wir DateTime.MaxValue verwenden.
Diese beiden Beispiele alleine zeigen, dass MS eigene Produkte inkompatibel zueinander sind.
Sollte mal eine Entscheidung zwischen .NET und Java nötig sein: BITTE NEHMTS JAVA. MACHTS ES EUCH NICHT UNNÖTIG SCHWER.
(von der unzureichenden Dokumentation und den Schwierigkeiten beim Konfigurieren eines SQLServers + IIS # Frontpage Server Extensions will ich mal gar nicht reden) Sorry aber ich bin nicht mal ansatzweise deiner Meinung. Ein DB Feld von Type uniqueidentifier darf sehr wohl Null sein (Ich hab 53 Tabellen, die alle Guids als PK haben, und eben auch dadurch einen Haufen FKs die NULL sind). Wenn du ein DB Feld Null setzt willst,verwend die SetXXXNull Funktion, und beim Zugriff verwendest die IsXXXNull Funktion um zu prüfen, obs funktioniert. Desweitern hat es durch aus Sinn ein Datenbank Connection nicht solange offenzulassen, bis sie der Programmierer schliesst (Sicherheit, Performance). Für das Multiuserproblem gibts ja schliesslich die optimistischen,pessimistischen,.. Zugriffsmethode. Und was du für Probleme mit der Config vom IIS oder SQL hast, weiss ich nicht, ich hab Produktivsysteme und Testsysteme ohne Probleme eingerichtet (ok ein WebDAV/Kerberos Problem hab ich gehabt, aber ich glaub nicht das du das berauchst) Ich hab sowohl in Java programmiert, also auch jetzt als Programmierer in einem SW-Haus .NET. Ich bin der Meinung Java nur dann zu verwenden wenn man plattformunabhängig sein will, sonst ist das .NET schneller, und eigentlich genauso einfach/schwer zu programmieren.
Bearbeitet von Yeahman am 23.04.2003, 08:10
|