006
10.02.2003, 19:04 Uhr
Bruder Leif
dances with systems
(Operator)
|
Moin moin!
The Empire strikes back 
Allerdings kannst du alten JDK1.1.8-Code noch mit der J2SE 1.4.1 kompilieren, und eine JRE 1.1.8 kann Bytecode, der mit einer 1.4.1-er Umgebung kompiliert wurde, ausführen.
Das schon, aber ich bekomme andauernd "deprecated"-Meldungen, nach denen das Programm in der nächsten Java-Version nicht mehr laufen wird. Altlasten abzuwerfen ist ja gut und schön, aber wenn mein Programm schon veraltet ist, bevor ich es fertig habe... können eigentlich wie bei .NET mehrere VM-Versionen nebeneinander koexistieren, und das Programm sucht sich automatisch die Version der Klassenbibliothek aus, die am besten zu ihm paßt? Dann ziehe ich das Argument zurück ;-)
Die GUI-Elemente in Java stecken in der Klassenbibliothek. Sie sind native [...]
Moment. Entweder sie sind native, also in der VM integriert, oder sie sind Teil der Klassenbibliothek. Das AWT ist soweit ich weiß ein Teil der VM, aber mit einem derartigen Subset von Komponenten kann man doch kein vernünftiges Programm schreiben! Die Swing-Klassen sind Java, und sie sind langsam. Deshalb dachte ich bis vor kurzem auch, Java sei generell lahm, aber das scheint nur auf Swing-Programme zuzutreffen. Eine vernünftige Alternative wären die SWT (s. C'T 3/2003), aber die sind nicht offiziell Teil der VM...
Der großte Vorteil ist, dass Java damit plattformunabhängig ist, was bei .NET nur für Konsolenprogramme gilt
Einspruch! ;-) .NET ist genauso plattformunabhängig wie Java. Schau Dir mal auf www.go-mono.com die Screenshots an, das sind ganz normale Windows.Forms-Programme, die problemlos mit Gtk# unter Linux laufen. In Sachen Plattformunabhängigkeit gilt für .NET genau dasselbe wie für Java: Es läuft auf jedem System, für das es eine VM gibt. Nur daß Java eben knapp zehn Jahre Vorsprung und damit mehr VMs anzubieten hat.
[...] der JVM auch sagen, dass sie sich beim Betriebssystem bedienen soll, so dass Java-Programme sich nahtlos ins System einfügen.
Das würde mich interessieren! Wie mach ich das? Kein Scherz, das interessiert mich jetzt wirklich!
Was mehrere Sprachen angeht, so ist das unter .NET mehr eine Alibi-Geschichte. Damit die Sprachen zusammenarbeiten können, mussten sie jeweils so verwässert werden, dass du im Grunde immer in derselben Sprache, nur mit anderen Schlüsselwörtern schreibst.
Wie kommst Du denn darauf? C# mußte gar nicht verwässert werden, das wurde komplett neu entwickelt. Visual C++ wurde sogar noch weiter in Richtung ANSI angepaßt, nur mit den optionalen Erweiterungen zum Ansprechen von .NET-Klassen. Und Visual Basic ist eh keine Programmiersprache... nein, im Ernst: Visual Basic hatte zwar halbherzige OO-Ansätze, aber für .NET wurde eben eine echte OO-Sprache draus. Wenn Du eine Verbesserung als "Verwässern" bezeichnen willst, OK...
Außerdem: Wenn Du's so genau nimmst, sind C, PASCAL, FORTRAN, COBOL und so weiter auch ein und dieselbe Sprache, nur mit anderer Syntax, anderer Klassenbibliothek, anderen Konzepten usw.
Das Speichermanagement ist keine Application-Level-Sache - aber das hat MS ja nie begriffen.
Millionen andere Programmierer auf dieser Welt auch nicht. Oder warum sind C und C++ nach wie vor so beliebt, obwohl man den Speicher selbst allokieren und wieder freigeben muß? WIE der Speicher jetzt allokiert wird, sollte eh Sache des Betriebssystems sein, und nicht der VM. Außerdem kann es für manche Programme sehr hilfreich sein, eine eigene GC zu verwenden, die auf die speziellen Bedürfnisse optimiert ist und noch ein Quentchen mehr Leistung rausholt...
Achja, mit "JIT-freundlich" meine ich nicht, daß JITting überhaupt möglich ist, sondern, daß der Native Code, der beim Compilieren rauskommt, besser an das jeweilige System angepaßt ist.
Java unterstützt Delegaten und inline-Klassen. C# hat das von Java geklaut. Unter Java kannst du auch für ein Event mehrere Adapterklassen anhängen.
Java kann Delegaten? Hups, dann nehm ich das zurück. Ich kenn nur die Version, wo ich mir für einen einfachen Event eine eigene inline-Klasse schreiben muß. In .NET schreib ich z.B.
| C++: |
textBox1.TextChanged += new EventHandler(Funktionsname);
|
und fertig. Weiß nicht mehr, wie die Zeile jetzt genau in Java aussehen würde, aber sie wäre wesentlich komplexer... Was eine solche Befehlskette jetzt bedeutet, erschließt sich aus dem Quelltext dann nur sehr schwer. Und das mit dem Klauen... Linux hat von Unix geklaut, OS/2 hat von Mac OS geklaut, die NASA hat von der ESA geklaut... entscheidend ist, was mit der "übernommenen" Idee gemacht wird.
Arrays sind in java schon seit Java 1 Klassen.
Hups, das war mir nicht bewußt. Erinnere mich nur an eine Diskussion in der Uni, in der es hieß, Arrays wären "simple Typen"...
Es gibt tausende vernünftiger IDEs für Java _umsont_. Nimm zum Beispiel JCreator.
Mit dem JCreator hab ich auch schon gearbeitet. Mir kommt es bei einer IDE aber nicht nur auf ein bißchen Code Completion, Parameterhinweise und Syntaxhervorhebung an, ich will einen ordentlichen GUI-Designer! Und die paar, die ich bisher ausprobiert hab (s.o.) sind hinsichtlich Ressourcenverbrauch, Geschwindigkeit und vor allem Stabilität unter aller Sau.
Die MessageBox-Geschichte klingt wie aus der J/Direct-Hilfe abgeschrieben. Meine Güte, nach dem Ptinzip write once, run anywhere - schreib dir eine und benutz sie wieder.
Das mit der JDirect-Hilfe kann ich nicht beurteilen, da hab ich noch nie was mit gemacht. OK, es ist ein wenig spitzfindig. Aber mir geht es nicht nur um MessageBoxes. Ich bin bei meinen ersten Versuchen, mit Java warm zu werden, immer wieder auf Klassen bzw. Methoden gestoßen, die ein vernünftiges Framework bieten sollte ("wenn ich mir die grundlegendsten Sachen erst selbst schreiben muß, kann ich mir auch gleich das gesamte Framework selbst schreiben"). Gut, das meiste hat Sun in den neuen Versionen inzwischen nachgezogen, aber es hinterläßt trotzdem den Eindruck, naja, dann pflastern wir hier halt auch noch schnell was dazu...
Net wird nie so plattformunabhängig sein wie Java[...]
Das sieht man schon daran, dass du C# ständig irgendwelche DllImport-Statements hast[...]
[...]dass .NET im .exe-Format kommt[...]
Siehe oben. Wenn erst mal genug VMs für andere Systeme existieren, laufen .NET-Programme auch dort. Es ist zwar möglich, über PInvoke auf plattformspezifisches zuzugreifen, aber nicht notwendig. Ist doch legitim, in der Übergangsphase per Wrapper-Klasse ein paar ActiveX-Komponenten einzusetzen, und im endgültigen Release mal eben auf ein reines .NET-System umzustellen. Mich würde übrigens interessieren, wo in C# ständig DllImports vorkommen. Im C++-Teil von .NET gibt es die schon, aber da bedeuten sie genau dasselbe wie die import-Statements in Java: Eine Assembly ("Package") soll eingebunden werden. Und die Programme und Assemblies heißen bei .NET eben ".EXE" und ".DLL". Mit dem ursprünglichen PE-Format von Windows haben die deshalb aber nicht viel gemeinsam, nur ein paar Stubs und fertig. Ich nehme an, die haben die Erweiterungen einfach aus Gewohnheitsgründen übernommen, nach dem Motto, achja, das kenn ich doch.
@virtual: Die sprachunabhängige Vererbung läuft über einzelne Assemblies. Du faßt z.B. mehrere Klassen, die zu einem Namespace gehören, in einer "Assembly" zusammen. Das Ergebnis ist eine EXE oder DLL, wohlgemerkt nur dem Namen nach. Wenn Du jetzt von einer Klasse in dieser "DLL" ableitest, kommt es auf die Sprache nicht mehr an, da alle .NET-Sprachen in die "MS Intermediate Language" MSIL übersetzt werden (ähnlich dem Java-Bytecode). Und die Datentypen werden als "Common Type System" zusammengefaßt. Insofern ist es schon ein alter Hut, die Windows-VM von .NET ist ja auch auf COM+ aufgebaut. Mono geht hier ganz ähnliche Wege, nur eben "the Linux way" ;-)
Stell Dir vor, Du hast einen Compiler, der C# in eine Art OO-Assembler (MSIL) übersetzt, einen entsprechenden Compiler für VB.NET, einen für C++ und so weiter. Und um das Name Mangling und die vTables kümmert sich dann der IL-Assembler. Das praktische daran ist, daß Du Dich nicht mehr mit COM-Kram rumplagen mußt, Du sagst einfach, OK, in dieser Datei steckt eine Klasse, und von der will ich jetzt ableiten...
Hey, das fängt an, Spaß zu machen *g*
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook. |
