Seminararbeit. zum Hauptseminarvortrag Konzepte hinter Microsoft's.NET. Michael Voigt

Transkript

1 Seminararbeit zum Hauptseminarvortrag Konzepte hinter Microsoft's.NET Michael Voigt Abstract: Microsoft hat mit dem.net Framework eine neue Laufzeitumgebung veröffentlicht, die im Gegensatz zu der Java Virtual Machine nicht nur für eine bestimmte, sondern für viele Programmiersprachen ausgelegt wurde. Die Seminararbeit gibt einen Überblick über die wesentlichen Konzepte des.net Frameworks und erläutet, was sich überhaupt hinter Microsoft's.NET verbirgt. Neben der Darstellung zentraler Technologien des. NET Frameworks wird auch auf Anwendungsmöglichkeiten eingegangen, die OpenSource Implementierung Mono vorgestellt und ein Vergleich von.net mit Java durchgeführt. Außerdem wird im Speziellen das theoretische Threading Modell von.net vorgestellt und eine Implementierungsmöglichkeit angegeben.

2 Inhaltsverzeichnis 1. Einleitung: Was ist.net? 2. Das.NET Framework 2.1 Common Language Runtime (CLR) 2.2 Common Intermediate Language (CIL) 2.3 Common Type System (CTS) 2.4 Framework Class Libary (FCL) 2.5 Sprachen im.net Framework C# J# Visual C++.NET (möglicherweise unvollständige) Liste weiterer.net Sprachen 3. Threading unter.net 3.1 Konzept 3.2 Implementierung unter Windows XP/ Anwendungen 4.1 ASP.NET 4.2 WebServices 5. Plattformunabhängikeit 5.1 ECMA Standards 5.2 Mono 6. Java vs..net 6.1 Gemeinsamkeiten 6.2 Unterschiede

3 1. Einleitung: Was ist.net? Die wohl erste Frage, die sich einem stellt, wenn man sich mit dem Thema.NET befassen möchte, lautet: Was ist.net überhaupt?.net ist in erster Linie eine neue Technologie von Microsoft, das.net Framework. Ein wesentlicher Bestandteil des.net Frameworks ist die Common Language Runtime (CLR), eine Lauftzeitumgebung vergleichbar mit der Java Virtual Machine. Die CLR führt einen virtuellen Zwischencode aus, die Common Intermediate Language (vgl. Java Bytecode). Außerdem enthält das.net Framework eine Klassenbibliothek, die Framework Class Libary (FLC), die die Funktionalität des Betriebssystems in objektorientierte Klassen kapselt. Ähnlich wie die Java Runtime stellt das.net Framework also eine vom Betriebssystem abstrahierende Laufzeitumgebung zur Verfügung; im Gegensatz aber zum Java Bytecode wurde die CIL daraufhin ausgelegt, dass nicht nur eine bestimmte, sondern viele verschiedene Programmiersprachen in sie kompilieren können sollen. Abb C# VB.NET C# Compiler VB Compiler... Common Intermediate Language (CIL) führt aus Common Language Runtime (CLR) Betriebssystem Das.NET Framework 2.1. Common Language Runtime (CLR) Wie in der Einleitung schon erwähnt, ist die Common Language Runtime eine sprachübergreifende Laufzeitumgebung, die auf das Betriebssystem aufsetzt. Die CLR ist somit im Prinzip ein Programm des jeweiligen Betriebssystems, das CIL Code zur Ausführung bringt. Dies geschieht, indem sie immer wechselweise einen Abschnitt CIL Code in den jeweiligen nativen Prozessorcode kompiliert und diesen dann ausführt (Bereits kompilierter CIL Code, der ein weiteres Mal aufgerufen wird, wird natürlich nicht noch einmal neu übersetzt, sondern gleich ausgeführt). Man bezeichnet diese Art und Weise des Ausführens von virtuellen Code als Just in Time Compilation. Außerdem leistet die CLR eine automatische Speicherverwaltung inklusive Garbage Collection, sie überprüft bei jeder Operation, ob diese auf dem entsprechenden Objekt auch erlaubt ist und bietet ein einheitliches objektorientiertes Ausnahmenmodell, indem sie Fehler von verschiedenen Ebenen in.net Exceptions umwandelt. Des Weiteren kann man gewisse Sicherheitsanforderungen an.net Programme oder Programmbibliotheken stellen, deren Einhaltung die CLR gewährleistet Common Intermediate Language (CIL) Die Common Intermediate Language ist eine assemblerartige Zwischensprache für eine virtuelle Maschine, die Common Language Runtime. Eine.NET Sprache wird nicht in nativen Prozessorcode übersetzt, sondern in CIL. Erst zur Laufzeit wird dieser CIL Code dann Just In Time in den entsprechenden Maschinencode kompiliert und ausgeführt. Die CIL ist zwar assemblernäher als eine Hochsprache, aber durch die Anreicherung mit Metadaten kennt sie trotzdem objektorientierte Konstrukte wie zum Beispiel Klassen, Methoden, Objekte, Ausnahmen usw. So ermöglicht sie der CLR, oben genannte Punkte, wie z.b. Typsicherheit, gewährleisten zu können.

4 2.3. Common Type System (CTS) Das Common Type System ist das Typsystem der CIL..NET Sprachen haben kein eigenes Typsystem, sondern setzten auf das CTS auf, d.h. sie verwenden Teile des CTS. Das CTS ist extrem weit gefächert und sehr flexibel, sodass Typen nahezu jeglicher heutiger Sprachen in ihm darstellbar sind. C# CTS Eine sehr kleine Untermenge des CTS ist die Common Language Specification (CLS). Sie stellt das Mindestmaß an Typen dar, die eine Sprache unterstützen muss, um unter.net laufen zu können. Die CLS kann quasi als die Schnitt und das CTS als die Vereinigungsmenge der Typsysteme aller.net Sprachen gesehen werden. Siehe dazu auch Abbilung Abb Fortran CLS J# Da alle.net Sprachen die CLS unterstützen, fungiert sie als eine Art Schnittstelle zwischen den verschiedenen Sprachen und ermöglicht somit Interoperabilität, wie zum Beispiel Vererbung, über Sprachgrenzen hinweg. Im Gegensatz zu Java ist im Common Type System jede Variable ein Objekt. Aber schon in einer Ebene der Vererbung tiefer wird, wie in Java, zwischen Wert und Referenztypen unterschieden. Diese Unterscheidung wird aus Geschwindigkeits und Effizienzgründen getroffen und beinhaltet eine unterschiedliche Behandlung der beiden Typen im Speicher. Der Inhalt von Werttypen wird direkt auf dem Stack abgelegt, während sich bei Refernztypen auf dem Stack selbstdef.: struct class vordef.: z.b. int z.b. String Abb Werttypen System.Object Referenztypen 'mensch' 'hund' nur eine Speicheradresse befindet, die angibt, wo der Inhalt des gesuchten Objekts auf dem Heap zu finden ist (siehe Abb ). Werttypen kann man durch das Schlüsselwort struct und Refernztypen durch das Schlüsselwort class selbst definieren. Ein typisches Beispiel für vordefinierte Werttypen ist das struct int, für Referenztypen ist dies die Klasse String. 'dino' Stack Stack Heap 2.4. Framework Class Libary (FCL) Der vierte wesentliche Bestandteil des. NET Frameworks ist dessen Standardklassenbibliothek, die Framework Class Libary. Diese kapselt die Funktionalität des Betriebssystems und bietet sie.net Programmen als Klassen bzw. Methoden zum Gebrauch an. Dadurch schirmt sie. NET Programme vom direkten Zugriff auf das Betriebssystem ab, abstrahiert auf diese Art und Weise vom Betriebssystem und trägt so zur Plattformunabhängikeit des.net Frameworks bei. Framework Class Libary System.Windows.Forms Dateizugriff typische Algorithmen Abb Threading WebServices...

5 Die FCL bietet unter anderem Klassen und Methoden zur Erstellung graphischer Benutzeroberflächen (im Namensraum System.Windows.Forms), zur Unterstützung von Threading, zum Dateizugriff und zur Erstellung von WebServices an. Sie hält aber auch typische, oft gebrauchte Algorithmen wie Heapsort oder die FFT bereit Sprachen im.net Framework Mittlerweile gibt es für viele Sprachen Compiler, die in CIL übersetzten. Hier sollen drei wichtige Sprachen betrachtet werden, für die.net Compiler von Microsoft existieren. Im Anschluss daran wird eine (möglicherweise unvollständige) Liste von weiteren Sprachen angegeben, von denen bekannt ist, dass für sie CIL Compiler existieren C# C# ist eine neue objektorientierte Hochsprache, die extra von Microsoft für das.net Framework entwickelt worden ist und auf die Kompilation in CIL zugeschnitten wurde. Sie enthält keine eigenen Klassenbibliothek, sondern stützt sich nur auf das.net Framework und die dessen FCL. Im Prinzip ist C# sehr ähnlich zu Java, geht aber in einigen Punkten über Java hinaus (Möglichkeit zur Verwendung von Zeigern, Unterstützung von typisierten Funktionszeigern und Ereignissen). Warum hat Microsoft eine neue Sprache entwickelt, wenn sie doch sehr ähnlich zu Java ist? Eigentlich hatte Microsoft damit geliebäugelt, Java als eine der Hauptsprachen von.net zu verwenden und es nur ein bisschen zu erweitern. Zur Zeit der Entwicklung des.net Frameworks stand Microsoft aber im Rechtsstreit mit Sun. Aus diesem Grund wohl hat Microsoft eine neue Java ähnliche Programmiersprache erschaffen, deren Name aber bewusst nicht nach Java klingt J# Als Microsoft.NET auf der Professional Developer Conference 2000 vorgestellt hatte, wurde öfter die Frage gestellt, was denn nun mit Java sei. Die Antwort Microsoft's darauf war eher verhalten. Es werde Implementierungen von Java für.net geben, aber nicht von Microsoft. Kaum 12 Monate später, im Oktober 2001, war der Rechtsstreit mit Sun inzwischen beigelegt und Microsoft veröffentlichte nun doch eine eigene.net Implementierung von Java, genannt J#. J# ist kompatibel zum JDK und enthält seine gesamte Klassenbibliothek (außer JNI, RMI und Applets). Trotzdem ist J# vollkommen in die.net Welt integriert; ein J# Programm kompiliert in CIL und die FCL ist von J# genauso wie von jeder anderen.net Sprache aus nutzbar Visual C++.NET Visual C++.NET (=VC++ 7.0), Microsoft's C++ Implementierung für.net, nimmt eine Sonderstellung unter den.net Sprachen ein, denn es ist die einzige Sprache, die in der Standardeinstellung noch prozessorabhänigen Maschinencode erzeugt. VC ist hundertprozentig abwärtskompatibel zu VC++ 6.0; ein fehlerfreies VC Programm sollte also auch fehlerfrei mit dem Visual C++.NET Compiler übersetzt werden können. C# J# C# Compiler J# Compiler C++ Compiler Common Intermediate Language Die CLR erlaubt aber sogenannten unsicheren Code in der CIL. Das ist Code, in dem der Programmierer die Common Language Runtime Verwaltung des Speichers selbsttätig übernimmt. Man (CLR) kann einen Abschnitt in CIL Code als unsicher kennzeichnen und in diesem Abschnitt dann Speicher von Betriebssystem Hand allokieren, deallokieren und mit Zeigern auf diesem Speicher arbeiten. Der betreffende Speicherbereich muss Abb C++ Maschinencode

6 jedoch vorher durch den Programmierer explizit fixiert werden, dass er von der automatischen Speicherverwaltung unberührt bleibt. JIT Kompilierung und unsicherer Code machen es möglich, dass man unter VC++.NET durch eine veränderte Compilereinstellung auch sogenannte gemischte Module erzeugen kann. Das sind Programme (oder Bibliotheken), die sowohl CIL Code als auch Maschinencode in ein und derselben Datei enthalten. Der Compiler übersetzt dann all die Code Abschnitte, bei denen es möglich ist, in CIL, und die anderen, bei denen es nicht möglich ist (die beispielsweise Inline Assembler Befehle enthalten), weiterhin in nativen Prozessorcode. Durch sogenannte managed extensions, das sind in VC neu hinzugekommene Schlüsselwörter, ist es sogar möglich, auch absolut reinen.net Code in Visual C++.NET zu erzeugen, zum Beispiel Klassen zu definieren, deren Instanzen der Garbage Collection unterliegen (möglicherweise unvollständige) Liste weiterer.net Sprachen Ada APL AsmL CAML Cobol Delphi Forth Eiffel Fortran Haskell Lisp Lua Mercury Mixal ML Mondrian Nemerle Oberon Pascal Perl PHP Prolog Python RPG Ruby Ruby Scheme Smalltalk 3. Threading unter.net Ruft man unter Windows ein.net Programm auf, wird ein neuer Betriebssystem Prozess gestartet und dieser lädt die CLR, welche dann schließlich das aufgerufene Programm ausführt. Genauso geschieht es in einem anderen, neuen Prozess, ruft man ein weiteres.net Programm auf (oder auch das gleiche noch einmal). Will man nun innerhalb eines Programms weitere Betriebssystem Prozesse oder Threads starten, ist dies unter.net nicht möglich, da das.net Framework wiederum aus Gründen der Plattformunabhängigkeit sein eigenes, vom Betriebssystem unabhängiges AppDomain soft thread BS Prozess 1 Abb Threading Konzept verwendet. Dieses Konzept soll im Folgenden kurz vorgestellt und danach dessen derzeitige Implementierung unter Windows XP und Windows 2000 angegeben werden. CLR AppDomain soft thread CLR BS Prozess 2

7 3.1. Konzept Das Threading unter.net läuft auf der Ebene der CLR ab und wird auch von dieser verwaltet. Sie bietet dafür zwei unterschiedliche Konstrukte: Application Domains (oder kurz App Domains), diese entsprechen den Betriebssystem Prozessen, und soft threads, diese sind das Pendant zu den BS Threads. AppDomain 1 Abb soft thread 1.1 AppDomain 2 soft thread 2.3 soft thread 2.2 soft thread 2.1 CLR BS Prozess AppDomain 3 soft thread 3.2 soft thread 3.1 Normalerweise wird ein.net Programm vorerst in einer AppDomain mit einem soft thread gestartet. Der Programmierer kann nun weitere AppDomains und innerhalb einer AppDomain auch weitere soft threads erzeugen. Jeder soft thread gehört zu genau einer AppDomain, in einer AppDomain können hingegen mehrere soft threads laufen. Die AppDomains haben auf Variablenebene voneinander getrennte Adressräume, soft threads in der selben AppDomain können auf die selben Daten zugreifen. Verwenden beispielsweise soft thread 2.1 und soft thread 2.3 in Abbildung die Variable x, so ist das ein und dieselbe Variable, während, wenn soft thread 1.1 auch eine Variable mit dem Namen x verwendet, dies eine andere zu der ist, die soft thread 2.1 und soft thread 2.3 verwenden. Diese Illusion der getrennten Adressräume erlischt allerdings bei Verwendung von unsicherem Code, da der Adressraum der Speicheradressen nach wie vor der des Betriebssystem Prozesses ist. Das.NET Framework hält einige Möglichkeiten zur Thread Synchonisation bereit, darunter z.b. Monitore oder locks (das sind Sperren ähnlich wie die von Datenbanksystemen) Implementierung unter Windows XP/2000 Nun stellt sich die Frage, wie man das theoretische Threading Modell AppDomain 1 AppDomain 2 AppDomain 3 der CLR BS Thread 3 soft thread 2.3 unter einem bestimmten Betriebssystem implementiert, konkret: welche Abbildung von soft threads auf BS Threads man BS Thread 2 BS Thread 1 soft thread 1.1 soft thread 2.2 soft thread 2.1 CLR soft thread 3.2 soft thread 3.1 wählt. Die derzeitige BS Prozess Implementierung der Abb CLR unter Windows XP und Windows 2000 bildet jeden soft thread auf genau einen BS Thread ab, wobei einem BS Thread auch mehrere soft threads zugeordnet sein können, aber maximal einer pro AppDomain. Die BS Threads springen dann immer gescheduled von der CLR zwischen den AppDomains hin und her und sind dann immer der BS Thread Vertreter des soft threads der jeweiligen AppDomain. Siehe dazu auch Abbildung

8 4. Anwendungen 4.1. ASP.NET ASP.NET ist eine neu konzipierte Fassung der Microsoft Active Server Pages und nun ein Bestandteil der Framework Class Libary. Es dient zur Erstellung dynamischer serverseitiger Websites. Client Abb HTML Browser ASP.NET.NET Programm HTML Server Die Idee von ASP.NET ist, dass ein Entwickler eine dynamische Website objektorientiert in.net wie eine Windows Anwendung programmieren kann (mit sogenannten WebForms), ohne je HTML oder Scriptsprachen bei der Erstellung gesehen zu haben. Die fertige Seite funktioniert auf Client Seite dann so, dass der Benutzer eine Anfrage in HTML die sein Browser erstellt, jenachdem, was er in dem HTML Formular klickt, anwählt oder ausgefüllt hat an den Server schickt und der Server dann eine, entsprechend der Anfrage dynamisch kreierte, HTML Seite an den Client zurückschickt. Die Brücke zwischen diesen beiden Welten stellt ASP.NET dar, dass einem die müßige Scriptprogrammierung in HTML Code abnehmen soll WebServices WebServices sind Server, die Methoden unter Einhaltung eines SOAP gewissen Standarts zum entfernten (kostenpflichtigen) Aufruf über das Internet via HTTP anbieten. Der WebService Standard Server Server besagt, dass das Ergebnisobjekt der Methode in XML Form zurückgeben werden und der Methodenaufruf über SOAP (eine XML XML Spezifikation eben genau für Methodenaufrufe von WebServices) Abb erfolgen muss. Dabei spielt die Implementierung des WebServices (ob nun mit Java,.NET, PHP oder ganz anders realisiert) keine Rolle, solange er sich an den Standard hält. Ein Paradebeispiel für die Verwendung von WebServices ist ein Online Reisebüro. Über das HTML Webinterface des Reisebüros kann der Anwender zum Beispiel herausfinden, ob noch Flüge zu einem bestimmten Datum und einem bestimmten Preis buchbar sind. Dazu stellt das Online Reisebüro Anfragen via SOAP an alle WebServices der Fluggesellschaften mit dem es in Vertrag steht und kann so dem User einen Überblick über die Flüge, die noch freie Plätze haben, geben und gegebenfalls auch einen davon buchen. Die FCL des.net Frameworks enthält Klassen zur Erstellung und Verwendung von WebServices, die es dem Programmierer ermöglichen, einerseits sehr einfach seine.net Methoden als WebServices anbieten und andererseits den Aufruf einer Methode eines WebServices wie einen lokalen.net Methoden Aufruf starten zu können. 5. Plattformunabhängigkeit 5.1. ECMA Standards Während der Entwicklung des.net Frameworks hat Microsoft im November 2000 Teile davon der ECMA zur Standardisierung vorgelegt. Nach einem intensiven Standardisierungsprozess, an dem unter anderem Firmen wie Microsoft, HP, Intel, IBM, Fujitsu, Sun, Netscape, Plum Hall und OpenWave beteiligt waren, wurden schließlich der Standard ECMA 334, der C# und einen C# Compiler beinhaltet, und der Standard ECMA 335, der die die CLR, die CIL und Teile der FCL charakterisiert, verabschiedet. Diese sind patentfrei und können von jedem, der es möchte, (kommerziell) implementiert werden.

9 5.2. Mono Mono ist ein Projekt, das sich zum Ziel gesetzt hat, eine OpenSource Implementierung der ECMA Standards, aber auch weiteren Teilen des.net Frameworks unter Linux, MacOS und Windows zu realisieren. Nach über zweijähriger Entwicklung ist nun im Juni 2004 Mono 1.0 erschienen. Es enthält eine CLR Version, einen Compiler für C# 1.0, einen Java CIL Compiler, Klassen zur Erstellung von WebServices und sogar die Alpha Version einer Entwicklungsumgebung, Monodevelop. Jedoch bestehen auch noch große Mängel. Zum Beispiel läuft ein einfaches GUI Tool, das mit Visual Studio.NET erstellt wurde, unter Mono noch nicht, da Mono 1.0 keine Unterstützung des Namensraums Abb System.Windows.Forms bietet. Diese wird aber für Mitte 2005 versprochen. Dafür enthält Mono 1.0 bereits die Klassenbibliothek Gtk#, die es ermöglicht, von.net Programmen aus auf die Gtk GUI Steuerelemente der GNOME Bibliothek zuzugreifen. Die Bibliothek Gtk# wurde auch auf Windows und den Macintosh portiert. Ein groß angelegtes Ziel des Mono Projektes ist es, im zweiten Quartal von 2006 Mono 2.0 herauszubringen, das eine komplette Implementation der Funktionen des.net Frameworks 2.0 enthält, welches 2005 erscheinen soll. Abbildung zeigt einen Screenshot von SkyNET unter Linux, ein Programm, dass einem beim Auffinden und Klassifizieren von Sternbildern am Himmel hilft. Es wurde mit C# und Gtk# unter Mono entwickelt. Auf Abbildung erkennt man die Entwicklungsumgebung Monodevelop unter MacOS. Abb In dem Magazin von ist 2004 ein Artikel namens Völcker Informatik AG. Success Story erschienen, der beschreibt, dass die Stadt München mehr als 350 seiner Server im Bindungsbereich auf Linux umgestellt hat. München sei langjähriger Kunde der Firma Völcker Informatik AG und habe diese gebeten, Ihre Software für sie so umzuschreiben, dass sie nicht mehr nur ausschließlich unter Windows, sondern auch auf Linux Systemen läuft. Um dies zu realisieren, habe Völcker Informatik Mono verwendet. Matthias Bauer, der Chefentwickler dieses Projekts, sagt in dem Artikel über Mono: We found Mono to be very stable and easy to learn. It s a commercial grade development platform that really works. [...] Using Mono was the only way for us to leverage our existing software and give our customers what they need on Linux.

10 6. Java vs..net Es soll nun ein Vergleich von.net mit Java (bzw. der Java 2 Enterprise Edition) angestellt werden. Dazu wird zuerst auf die Gemeinsamkeiten der beiden Systeme, dann auf ihre Unterschiede eingegangen Gemeinsamkeiten Sowohl Java als auch.net Programme basieren auf einem (prinzipiell) plattformunabhängigen virtuellen Zwischencode, der von einer Laufzeitumgebung ausgeführt wird. Die Java Virtual Machine unterstützt, genauso wie die CLR, Objektorientierung, leistet automatische Speicherverwaltung (Garbage Collection) und gewährt Typsicherheit. Mit der Java 2 Enterprise Edition ist es, wie auch mit dem.net Framework, möglich, WebServices zu erstellen und zu verwenden und dynamische Websites zu kreieren. Java (JVM).NET virtueller Zwischencode/VM JA JA Objektorientierung JA JA Garbage Collection JA JA Typsicherheit JA JA WebServices JA JA Dynamische Webpages JSP ASP.NET Abb Unterschiede Eine Java Runtime existiert für sehr viele Systeme und obwohl es in einigen Java Versionen betriebssystemspezifische Features gibt, so ist es in der Regel doch recht unkompliziert, ein Java Programm auf einer andere Plattform zu portieren. In vielen Fällen kann man sogar exakt den gleichen Java Bytecode auf sehr vielen Systemen ausführen. Will man ein plattformübergreifendes.net Programm haben, so muss es bewusst auf die Plattformunabhängigkeit hin entwickelt worden Java (JVM).NET Plattformunabhängigkeit Realität bedingt Sprachunabhängigkeit th. möglich Realität Performance < Bytecode/CIL Größe < Betriebssystemintegration schwach mittel unsicherer Code NEIN JA imperative Prog. Sprachen NEIN/schlecht JA Kompilierung Interpreter, JIT JIT Abb sein (z.b. mit Mono). Unter Visual Studio.NET erzeugter Code, lässt sich in vielen Fällen heutzutage noch sehr schlecht auf andere Plattformen wie Linux, FreeBSD oder Mac Systeme übertragen. Allerdings hat Microsoft das.net Compact Framework publiziert, das es möglich macht,.net Programme auf Pocket PCs mit WindowsCE auszuführen. Unter Punkt kann man erkennen, dass die Sprachpluralität von.net bereits Realität geworden ist. Compiler anderer Sprachen als Java, die auf Java Bytecode und die Java Virtual Machine und abzielen, gibt es nur wenige, es ist aber natürlich theoretisch möglich, nicht nur für Java Compiler zu entwicklen, die in Java Bytecode kompilieren. Jeremy Singer von der University of Cambridge hat jedoch eine Studie unter dem Namen JVM versus CLR: A comparative Study veröffentlicht, in der er ein CIL Backend für den GNU C Compiler entwickelt und dieses mit dem bereits existierenden Java Bytecode Backend egcs jvm von Trent Waddigton verglichen hat. Als Singer nun verschiedene einfache C Programme mit den beiden Compilern übersetzt hatte, war der von egcs jvm erzeugte Java Bytecode leider nicht (fehlerfrei) ausführbar, während sein Compiler immer funktionierende und sogar sehr performante Programme lieferte. Dies zeigt, dass die CLR durch die Unterstützung von unsicherem Codes gegenüber der JVM für die Implementierung imperativer Programmiersprachen klar im Vorteil ist. Die Studie hat aber auch noch die Geschwindigkeit und die Zwischencode Größen der beiden Systeme bei Kompilierung und Ausführung gleicher Programme verglichen und ist zu dem Ergebnis gekommen, dass der CIL Code des gleichen Programms durchschnittlich etwas größer ist als der entsprechende Java Bytecode, dass er im Schnitt dafür aber etwas schneller ausgeführt wird. Die Unterschiede hier sind aber derart gering, dass sie leicht zu vernachlässigen sind.

11 Quellen [1] Ralph Wesphal:.NET kompakt. Spektrum Akademischer Verlag, 2002 [2] Don Box with Chris Sells: Essential.NET. Volume 1. The Common Language Runtime. Addison Wesley, 2002 [3] Jeffrey Richter: Applied.NET Framework Programming, chapter 1. Microsoft Press, 2002 [4] Peter Drayton, Ben Albahri & Ted Neward: C# in a nutshell, Deutsche Übersetzung, insbes. Kapitel 1. O'Reilly Verlag GmbH & Co. KG, 2003 [5] Betrand Meyer:.NET Is Coming. In: Software Technologies, August 2001 [6] Jeremy Singer: JVM versus CLR: A Comperative Study. University of Cambrigde Computer Laboratory, 2003 [7] Chad Vawter and Ed Roman: J2EE vs. Microsoft.NET. A comparison of building XML based web services. Middleware Company, 2001 [8] White Paper: Microsoft.NET or Java Enterprise Edition: Is it just a question of platforms and languages? CGI Group Inc., 2004 [9] project.com [10] Kein Autor angegeben: Völcker Informatik AG. Succes Story. In: Zeitschrift von