Java und Ruby: ein Vergleich. Heinz Serfas Hochschule für Technik Stuttgart 20. Oktober 2007

Transkript

1 Java und Ruby: ein Vergleich Heinz Serfas Hochschule für Technik Stuttgart 20. Oktober 2007

2 Inhaltsverzeichnis 1 Einleitung 1 2 Java Java Spracheigenschaften Java Sprachkonzepte Ruby Ruby Spracheigenschaften Ruby Sprachkonzepte Vergleich Spracheigenschaften Sprachkonzepte Schluss und Ausblick 9 I

3 1 Einleitung Viele Programmiersprachen haben feste Einsatzgebiete, in denen sie nicht wegzudenken sind. Einige von ihnen existieren nur um einen einzigen Zweck zu erfüllen. Andere heißen general purpose Sprachen, da sie für viele allgemeine Softwareentwicklung verwet werden. Java als general purpose Sprache hat sich in diesen Gebiet etabliert und ist aus kaum einer Softwarefirma wegzudenken. Für neue Sprachen ist es schwierig sich in Sgementen zu etablieren, die bereits von anderen Sprachen gehalten werden. Allerdings gibt es eine neuere Sprache die dies trotzdem schafft, die mittlerweile bereits häufig Verwung in Segmenten findet, die ehemals andere Sprachen inne hatten. Sie heisst Ruby. Nun stellt sich die Frage warum schafft Ruby andere bereits seit längerem etablierte Sprachen aus diesen Segmenten zu verdrängen. Welche Besonderheiten und Vorteile hat Ruby? Welche Neuerungen und Konstrukte sind derart einzigartig dass Entwickler von Ihnen gut bekannte Sprachen auf Ruby umsteigen? Hat Ruby letzlich evtl. sogar die Fähigkeit Java zu verdrängen? 2 Java 2.1 Java Spracheigenschaften JVM und ByteCode Java ist keine Programmiersprache die in lokalen Maschienencode kompiliert wird und dann dort sofort ausfürbar ist. Es ist vielmehr so, dass der traditionelle Java Kompiler Javacode in sogenannten Byte- Code kompiliert. Dieser Byte-Code wird in den aus Java Klassen generierte.class Dateien abgelegt. Byte-Code ist dabei eine Art Zwischencode, der nicht maschienenabhängig ist. Dies hat den Vorteil, dass der Byte-Code mit einem entsprechen Interpreter auf jeder Plattform lauffähig ist, auf der auch der Interpreter läuft. Dieser Interpreter übersetzt den Byte-Code zur Laufzeit in Maschienencode der dann zur Ausführung kommt. Der Maschienencode wird in keiner Datei gespeichert und ist nach der Beigung der JVM nicht mehr vorhanden. Für den Nutzer ist der tatsächliche Maschienencode also niemals sichtbar. [TJLS] Der Interpreter muss für jede Plattform geschrieben werden. Die Anwungsprogramm in Java allerdings nicht. Sie sind mittels dieses Konzeptes weitestgeh Plattformunabhängig. Der Java Interpreter wird im allgemeinen JVM (Java Virtuelle Maschiene) genannt. Die JVM bildet eine Laufzeitumgebung, die für jedes Programm gestartet wird, so hat jedes Java Programm das zur Ausführung gelangt, seine eigene JVM in der es weitestgeh unabhängig läuft. Insbesondere Nebenläufige Programme teilen sich nicht eine JVM, sondern laufen in gesonderten JVMs. Java vereinigt also die Konzepte der Kompilierung mit denen der interpretierten Sprachen. Programmierparadigmen Softwareentwicklung für Grossysteme ist eine komplexe Aufgabe. Es muss das Problem identifiziert, verstanden und dann über 1

4 ein Design einen Lösungsansatz dafür enwickelt werden. Erst danach kann man zur konkreten Implementierung der Lösung, dem eigentlichen Programmieren schreiten. Auf diesem Wege verwet man eine Vielzahl von Modellen, die zur Vereinfachung dienen. Eines dieser Modelle ist die Prozedurale Sicht. Man beschreibt ein Programm indem man beschreibt welche Anweisungen es Ausführen muss. Diese Anweisungen werden zu sinnvollen Gruppen zusammengefasst, welche wiederkehre Aufgaben übernehmen. Eine weiteres Modell ist die Objektorientierung. Um dieses Modell im Detail zu Erklären reicht der Umfang dieser Arbeit nicht aus, deshalb im Folgem einige Grundsätze zur Objektorientierung. In Ihr sind Objekte die Basiselemente. Ein Programm wird als komplexes System von miteinander interagieren Objekten gesehen. Objekte haben Namen, kapseln Daten in Attributen und besitzen bestimmte Prozeduren. Ziel dieses Modelles ist es Objekte der realen Welt abzubilden. Klassen sind dabei eine Art Bauplan, nach denen Objekte aufgebaut werden. Klassen geben die Anzahl, Namen und Typen der Attribute sowie Prozeduren in Java Methoden genannt eines Objektes vor. Objekte besitzen immer mindestens einen Typ, d.h. eine Klasse nach deren Plan sie funktionieren. Allgmeine können von einer Klasse mehrere Objekte erschaffen werden. Es ist denkbar, dass Objekte mehrere Typen besitzen, also nach mehreren Klassen gebaut werden. Dieser Fall der Mehrfachvererbung ist in Java nur nur teilweise Möglich. Grundsätzlich erbt eine neue Klasse konkrete Implementierungen von genau einer anderen Klasse. Zusätzlich dazu kann eine Klasse in Java beliebg viele sogenannte Interfaces implementieren. Interfaces, sind rein formale Definitionen von Feldern und Methoden, und enthalten keinerlei Implementierung. Sie sind also so etwas wie ein Gerüst einer Klasse. Wenn eine konkrete Klasse eine solches Schnittstelle benutzt, man sagt implementiert, muss diese alle in der Schnittstelle formal deklarierten Methoden ausimplementieren. Ist dies nicht der Fall würde der Java Kompiler einen Fehler melden, und die entspreche Klasse nicht kompilieren.[tjsl] Java ist speziell im Hinblick auf Objektorientierung entwickelt worden. In Java kann ein Entwickler keine Methode schreiben, ohne explizit dessen Klasse zu schreiben. Deshalb ist es mit Java kaum sinnvoll möglich Programme im Paradiga der Prozeduralen Programmierung zu verwirklichen. Schreibt man eine Software in Java so sollte man auf das der Entwicklung zugrunde liege Paradigma der Objektorientierung zurückgreifen. 2.2 Java Sprachkonzepte primitive Datentypen und Objekte Wie bereits im vorherigen Kapitel beschrieben ist Java fast außschließlich für die Objektorientierte Programmierung entworfen worden. Anserst als andere reine Objektorientierte Sprachen besitzt Java jedoch primitiven Datentyp wie z.b: int. Gleichwohl ist jeder komplexere Datentyp ein Objekt in Java. Wie in anderen Sprachen gibt es auch in Java eine Superklasse aller Klassen, diese heisst Object. Jedes Objekt in Java ist also entweder direkt oder indirekt vom Typ Object.[TJLS] Nun sind Methoden des objektorientierten Konzepte wie z.b. Vererbung, 2

5 Kapselung, Überladen und Überschreiben nur für Objekte nicht aber für die primitiven Datentypen einsetzbar. Es stellte sich heraus, dass in einer vollständig Objektorientierten Sprache auch diese Grunddatentypen als Objekte zur Verfügung stehen sollten. Daher die sogenannenten Wrapper Klasse. Die Objekte dieser Klassen kapseln die primitiven Datentypen. Der Gund dafür ist u.a., dass ohne diese Wrapperklassen, keine Collections mit diesen primitiven Datentypen möglich wären. Collections sind dynamische Implemtierungen von Listen, Stacks, Maps, usw. die allerdings allesamt nur Objekte aufnehmen können. Der Weg um trotzdem Collections von primitiven Datentypen zu bekommen führt also über diese Wrapper Klassen. Die primitiven Datentypen werden in Objekte gekapselt die ihrerseits sehrwohl in einer Collection aufgenommen werden können. Ab Java Version 1.5 braucht sich der Entwickler selbst nicht mehr darum zu kümmern wie er primitve Datentypen in Objekte, und anderst herum verpackt. Der Java Kompiler besitz mit dem sogenannten autoboxing ein Feature welches ihm erlaubt automatisch selbst von primitivem Datentyp auf Objekte und anderst herum zu wechseln. statische Typisierung Wie im Kapitel Eigenschaften Java - Objektorientierung beschrieben hat jedes Objekt einen Typ. In Java hat des weiteren jede Variable oder Konstante einen Typ, der zur Kompilezeit feststeht. Genau diesen umstand nennt man statisch typisiert. [TJLS] text = "Hallo Welt"; // allein nicht zulssig String text = "Hallo Welt"; // allein zulssig Da der Typ einer Variablen zur Kompilezeit bekannt ist, sind dem Kompiler auch die Methoden und Attribut welches dieses Objekt besitzt bekannt. Versucht man eine Methode für ein Objekt zu rufen, welche für den Typ des Objektes nicht definiert ist wirft der Kompiler einen Fehler und übersetzt den Code nicht.deshalb ist es nicht möglich eine Methode für ein Objekt aufzurufen, das dessen deklarierter Typ nicht besitzt. Daraus resultiert eine bestimmte Typsicherheit, da derlei Fehler bereits zur Kompilezeit entdeckt werden. Dieses statische Typsystem hat den großen Vorteil, dass sogenannten IDEs (Integrated Development Environements) aufgerufen Methoden oder Attribute eines Objektes validieren können, und ggf. Fehler anzeigen. Ausserdem können sie den Entwickler sogar dabei unterstützen die richtige Methode oder das richtige Attribut zu finden, indem sie ihm alle Methoden und Attribute zeigen, die für den Typ des Objektes zur verfügung stehen.[tjls] Interfaceorientierung Da Java wie zuvor beschrieben Mehrfachvererbung nur bedingt unterstützt, wird objektorientierter Javacode Interfaceorientiert programmiert. Dies möchte ich an zwei Beispielen aus der konkreten Java API deutlich machen. Sehen wir uns dazu zuerst die zur Swing Bibliothek gehöre Klasse JComboBox an. Die meisten Swingkomponenten setzen das MVC (Model View Con- troller) Prinzip sehr durchgängig und ersichtlich ein, so auch JComboBox. Das MVC Prinzip basiert auf der Idee, dass ein sogenanntes Model die Daten 3

6 kapselt, welche durch den View genannten Teil angezeigt werden. Der Controller ist maßgeblich für die Änderung der Daten im Model verantwortlich. Bei unserem Beispielt spielt JComboBox die Rolle des Views. Das Model erhält man durch den einfachen Aufruf von.getmodel(). Diese Methode liefert ein Objekt zurück welches das Interface ComboBoxModel implementiert. Wie beschrieben spielt der eigentliche Typ des zurückgelieferten Objektes keine Rolle, da man die für ein ComboBoxModel wichtigen Methoden durch das implementieren des Interfaces automatisch implementiert hat. So kann auch jede vom Entwickler selbst geschriebene Klasse dieses Interface implementieren und danach als Model für eine JComboBox genutzt werden.[jjcb] Als weiteres Beispiel möchte ich das häufig benutzte RMI Framework benutzen. Java RMI ermöglicht es Methoden für Objekte von einem entfernten Rechner aus aufzurufen. Dazu benötigt der Client ein sog. Stub, also eine lokales Objekt welches das entfernte Objekt für das eine Methode gerufen werden soll repräsentiert. Diesen Stub bekommt der Client über die sog. Registry eine Art Verwalterinstanz, die eine Menge von solchen Stubs bereithält und auf anfrage zurückliefert. Registry registry = LocateRegistry.getRegistry("meinStub"); Remote stub = registry.lookup(name); Die Registry liefert ein Objekt zurück welches das Interface Remote implementiert. Dieses Interface garantiert nur das Methoden, welche für dieses Stub Objekt aufgerufen werden durch RMI für das tatsächliche Server Objekt gerufen werden. Als Entwickler einer RMI Applikation hat man nun die Aufgabe eine Schnittstelle welche Remote erweitert, sowie eine Klasse die genau diese Schnittstelle implementiert zu schreiben. Die Klasse wird als konkretes Server Objekt verwet. Der Stub, welchen man nun durch die lookup Methode von der Registry zurück bekommt wird auf das Interface gecastet. Somit kann man für den Stub genau die Methoden aufrufen, die für das Serverobjekt implementiert wurden. Die konkrete Klasse des Stubs interessiert hierbei überhaupt nicht. Die Klasse des Objektes welches die Registry zurückliefert ist sogar unbekannt, da der Entwickler selbst diese Klasse niemals geschrieben hat. Die konkrete Implementierung der Stub Klasse wird vom RMI Framework erzeugt. Die erstellte Klasse ist im Grunde nur für die übertragung der Methoden zum Server und das Zurückliefern des Rückgabewertes verantwortlich. Falls in Zukunft eine bessere oder schnellere Methode für die übertragung erscheint kann das RMI Framework durch seine Entwickler so angepasst werden, dass es eine solche Stubklasse erstellt, die genau diese Neuerung implementiert. kompiliert man nun seine alten RMI Projekte neu, so können diese ohne eigene Quelltextänderungen von diesen Neuerungen profitieren. [JRMI] Diese Beispiele zeigen, das es in Java Sinn macht gegen Interfaces zu implementieren. Weiter noch macht genau dieses Konzept des Programmierens gegen Interfaces die Flexibilität eines Java Programmes aus. Ein Interface ist eine Art Vertrag, der beschreibt was ein Objekt leistet, welche Methoden es bereitstellt. Die konkrete Implementierung hingegen sagt aus wie ein Objekt etwas tut. Dies ist abhängig von von verschiedenen Voraussetzungen die sich änder können. 4

7 Nachteil dieses Konzeptes sind allerdings häufige Casts. Casts sind vom Entwickler absichtlich herbeigeführte Typänderungen. Diese Typänderungen können allerdings oftmals erst zur Laufzeit verifiziert werden. Dadurch wird das eigentlich statische Typsystem von Java gebrochen und damit die Typsicherheit unterwandert. Trotz der durchgängige Benutzung von Interfaces kann es vorkommen, dass man die konkrete Implementierung eines Objektes benötigt. Hierbei ist der Java Entwickler gezwungen Casts zu verwen, die das Objekt auf einen anderen Typ als den des Interfaces casten. Der Entwickler muss vor der Ausführung, nämlich zur Kompilezeit, wissen welchen genauen Typ ein Objekt hat. 3 Ruby 3.1 Ruby Spracheigenschaften interpretierte Skriptsprache Ruby ist eine Skriptsprache. Dies ist darin begründet, dass bestimmte Merkmale erfüllt werden. Die folgen Merkmale sind also durchaus bei anderen Skriptsprachen ebenfalls anzutreffen. Rubycode wird nicht im herkömmlichen Stil kompiliert um später ausgeführt zu werden. Stattdessen wird der Rubycode direkt einem Interpreter zugeführt, der diesen in lauffähigen Maschienencode umwandelt und ausführt. Dies Ansatz gilt allgmein bei Skriptsprachen.[WSK] Auch bei diesem Konzept ist der tatsächliche Maschienencode für den Anwer nicht sichtbar. Programme in Skriptsprachen unterliegen aufgrund dieses Konzeptes ebenfalls keiner Plattformbeschränkung. So ist Ruby auf genau diesen Plattformen lauffähig, auf denen auch der Ruby Interpreter läuft. Weiterhin gilt, dass Variablen in Ruby nicht deklariert werden, d.h. ihr Typ muss nicht bekannt sein um dieser Variablen ein Objekt zuzuweisen. Ausserdem besitzt Ruby ein dynamisches Typsystem genannt duck typing dazu später mehr. Ein weiteres Merkmal ist die automatische Speicherverwaltung. Es ist in Ruby nicht nötig Objekte welche man allokiert, wieder frei zu geben. Sobald es keine Referenz auf ein Objekt mehr gibt kann dieses automatisch durch die Laufzeitumgebung beseitigt werden. Im Gegensatz zu vielen anderen Skriptsprachen kann in Ruby vollständig Objektorientiert programmiert werden. Programmierparadigmen Ruby ist ebenfalls im Hinblick auf Objektorientierung entwickelt worden, und auch in Ruby ist es sinnvoll Programme in diesem Paradigma zu schreiben. Als Beispiel eine Klasse Auto: class Auto attr_accessor:name #getter fuer name def initialize name = name 5

8 def fahren puts "brum brum" def bremsen puts "quietsch" Jedoch ist es auch möglich das Prozedurale Paradigma anzuwen. ähnlich wie in Java stehen alle Methoden in einer Klasse, jedoch wird der Entwickler nicht gezwungen seine Prozeduren explizit in Klassen zu schreiben. Dies eröffnet ihm die Möglichkeit komplett auf Objektorientierung zu verzichten und rein Prozedural vorzugehen. Nichts desto trotz steht in Ruby jede Methode die nicht explizit in einer anderen Klasse steht automatisch in der main Klasse. Ausserdem gibt es in Ruby globale Variablen die dieses Konzept erheblich unterstützen.[rlo] 3.2 Ruby Sprachkonzepte alles ist ein Objekt Ruby ist, wenn der Entwickler das will, vollständig Objektorientiert, dies bedeutet das jedes Element in Ruby wie ein Objekt behandelt werden kann. Sogar einfache Zahlen wie 5 sind in Ruby bereits Objekte, denn man kann füer sie Methoden aufrufen: puts 5.next Gibt zum Beispiel die Zahl 6 aus, da 5 ein Integerobjekt ist und bei ganzen Zahlen auf 5 die 6 folgt. dynamische Typisierung - Duck Typing Anderst als in anderen Sprachen und typisch für Scriptsprachen verwet Ruby sogenannte dynamische Typisierung. Variablen werden nicht deklariert und damit an einen Typ gebunden, sondern einfach verwet. Dies bedeutet, das nicht der Compiler zur Kompilezeit entscheidet, ob eine Methode für ein Objekt unterstützt wird oder nicht, sondern der Interpreter zur Laufzeit: text = "mein Name" text.getcount wird zur Laufzeit einen Fehler werfen, da die Methode getcount für String, den Typ des Objektes unter dem Namen text nicht zur verfügung steht. Das in Ruby verwete Typsystem wird Duck Typing gennant. Dieser Begriff geht auf eine Zeile eines Gedichtes von Whitcomb Riley zurück. Zitat When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck. [JVSR] 6

9 Der Ruby Interpreter verlässt sich nicht auf den Typ eines Objektes, also von welcher Klasse es ist. Anhand derer er Methoden oder Attribute identifizieren und validieren kann. Vielmehr kann der Interpreter die tatsächlichen Methoden eines Objektes herausfinden und diese Aufrufen. Wenn für ein Objekt eine Methode size gerufen werden soll und dieses Objekt diese Methode bestitzt, spielt es keine Rolle von welchem Typ dieses Objekt ist. Die Methode ist vorhanden und kann gerufen werden, genau das geschiet dann auch. include class car string1 = ein Text zahl2 = 56 auto3 = Auto.new(BMW) string1.size zahl2.size auto3.size In den 3 Typen, String, Fixnum sowie Auto ist jeweils die Methode size implementiert und kann aus diesem Grund auch gerufen werden. Ist diese Methode andererseits im genannten Objekt nicht vorhanden hat der Interpreter keine Wahl und muss einen Fehler produzieren. Module und Mixins Auch in Ruby gibt es keine traditionelle Mehrfachvererbung, jedoch gibt es auch in dieser Sprache ein mächtiges Konstrukt welches über ähnliche Fähigkeiten verfügt. In Ruby können Codeteile in sogenannten Modulen stehen. Module werden ähnlich wie Klassen definiert können jedoch nicht instantiert werden. Klassen können beliebig viele dieser Module inkludieren, dadurch wird das inkludierte Modul zu einem mixed in der Klasse. Statische Modulmethoden, welche auf keine Instanzvariablen oder Instanzmethoden können wie statische Klassenmethoden aufgerufen werden. Ausserdem können in diesen Mixins auf Instanzvaribalen und -methoden zugegriffen werden, welche erst im konkreten Objekt vorhanden sind. Im Beispiel unten wird die Methode add des Modules direkt als statische Klassenmethode vom Modul gerufen. Die Methode substract wird vom Modul an die konkrete Klasse weitergegeben mixed in. Dabei ist es wichtig, dass die eigentliche Klasse die besitzt. Mixins verhalten sich ähnlich wie Oberklassen, und sind demnach ein ebenfalls eine Möglichkeit Mehrfachvererbung zu simulieren. [JVSR] module Math def Math.add(number_one, number_two) number_one + number_two def substract(number_two) 7

10 @value + number_two class MyClass def = val include Math # statische Methode von Math puts Math.add(2,6) # mixtin Instanzmethode add my = MyClass.new(47) puts my.substract(11) 4 Vergleich 4.1 Spracheigenschaften In Java sind im Gegensatz zu Java zwei Schritte vom Code zur Ausführung nötig. Dies hat füer Java den Vorteil, dass es den Code entsprech optimieren kann, also die Ausführung nach der Kompilierung schneller von statten geht. Ruby wiederum hat den Vorteil sehr flexibel zu sein und schnell Änderungen am Code zuzulassen. Ruby ist als Skriptsprache so entwickelt worden, dass der Entwickler entscheiden kann welches Paradigma füer seine Entwicklung zum Einsatz kommt. In Java hingegen wird der Entwickler quasi zum Einsatz von Objektorientierung gezwungen. Dies hat den Nachteil, das kleinere Tools also kleine (Hilfs- )Programme schwieriger in das Konzept der Sprache passen. Kleiner Tools sind allerdings eine Domäne für Skriptsprachen. Große Projekte sind nach aktuellem Stand eine Domäne für objektorientierte Programmiersprachen und im speziellen das bei weitem wichtigste Einsatzgebit der kompilierten Sprachen. Java ist genau in diesem Umfeld angesiedelt und spielt hier ein große Rolle. Ruby steht diesen Sprachen in beziehung auf Objektorientierung in nichts nach. 4.2 Sprachkonzepte Ruby vertritt den Ansatz, dass wenn Objektorientierung verwet wird auch alles als Objekt aufgefasst werden kann. In Java hingegen existieren neben den Objekten auch noch die primitiven Datentypen. Diese können allerdings über 8

11 Wrapperklassen ebenfalls als Objekte dargestellt werden. Somit ist dieses Konzept mit etwas mehr Aufwand auch in Java realisierbar. Auch die Typisierung der beiden Sprachen sind vollkommen unterschiedlich. Ruby hat hier den Vorteil, dass man weitaus effektiver Code schreiben kann, da der Rubyentwickler Variablen nicht deklariert und somit Zeit sparen kann. Andererseits muss der Rubyentwickler wissen welchen Typ eine Variable haben kann und welchen Typ z.b. eine bestimmte Methode zurückliefert. Dies ist bei großen Projekten mit mehreren Entwicklern eine schwierige Aufgabe. Ausserdem werden Änderungen an solcherlei Typen nicht sofort auffallen sondern erst zur Laufzeit im konkreten Fall einen Fehler produzieren. Java geht sehr viel restriktiver vor und bei einem geänderten und inkompatibel Rückgabetyp die entspreche Klasse nicht mehr kompilieren. Java hat damit also den Vorteil Fehler zu erkennen noch bevor sie auftreten. Genau dies ist auch ein Vorteil der Programmierung gegen Interfaces, sie fordern, dass bestimmte Methoden vorhanden sind. Es spielt keine Rolle wie sie implementiert sind. Zusätzlich kann ein Entwickler allein an den implementierten Interfaces erkennen welchen Zweck eine Klasse erfüellen soll, dies fördert das Verständniss des Programmes allgemein. In Ruby steht dem Konzept der Interfaces das Konzept der Mixins gegenüber. Dieses hat jedoch den Unterschied, dass die Methoden bereits ausimplementiert sind. Vorteil, man braucht Code nicht mehrfach zu schreiben. Nachteil ist das hier nicht der Vertrag, also was ein Objekt kann im Vordergrund steht sondern wie es das macht. Allerdings kann man auch in Java über sogenannte casts aus dem statischen Typsystem fallen, dies hat ähnliche Auswirkungen wie das dynamische Typsystem, da 5 Schluss und Ausblick Durch ihre Flexibilität und ihr nicht statisches Typsystem ist Ruby bestens für kleine Projekte geeignet. Kleine Programme füer die sich keine große Architektur lohnt sind sicherlich schneller in Ruby geschrieben als in Java. Allein der Umstand, dass prozedurale Ansätze in Java fast nie zu übersichtlichem Code führen zeigt, dass dies keine Domäne für Java ist. In großen Frameworks und bei großen Projekten jedoch birgt allein das dynamische Typsystem von Ruby eine riesige Fülle von potentziellen Fehlern in sich. Dies bedingt, dass der Entwickler zu jeder Zeit genau weiss welchen Typ ein Objekt haben kann. Das wiederum ist bei sehr groß angelegten Projekten mit vielen Entwicklern nur unter größtem Aufwand, z.b. in Form von Dokumentationen zu verwirklichen. In diesen Segmenten wird Ruby voraussichtlich keine Alternative zu Java darstellen können, da der damit verbundene Aufwand einfach zu hoch ist. Somit kann man abschließ feststellen, dass Ruby Java nicht ersetzen können wird, da sich die Konzepte zu stark unterscheiden. 9

12 Aber ein Entwicklungspacket zu welchem beide Sprachen gehören, würde einen viel größeres Einsatzgebiet abdecken als die Sprachen allein. Eine solche Verbindung von Ruby und Java stellt JRuby dar. Dies ist ein Ruby Interpreter der es erlaubt Java Objekte in Ruby und Ruby Objekte in Java zu verwen. Dieses Projekt kann dazu führen, dass Ruby und Java als System genutzt werden könnten was die Vorteile beider Sprachen vereint. Man könnte die mächtigen Java Klassen und Ihre Vorteile in den einfachen prozeduralen Kontext von Ruby nutzen. Man könnte Prototypen welche Javaframework benutzen schneller in Ruby verwirklichen. Und zusätzlich ausgewählte Teile im Javacode wiederverwen. Eine solch flexible Lösung hätte die Möglichkeit viele andere Sprachen gleichermaßen zu ersetzen. 10

13 Literatur [TJLS] Sun, The Java Language Specification, Third Edition Sprachdefinition Java aktuelle Version Abgerufen am [J2RR] RRZN Hannover, Java 2 Grundlagen und Einführung April 2005, 4., unveränderte Auflage [JJCB] Sun, JComboBox (Java 2 Plattform SE 5.0) API Dokumentation der Klasse JComboBox Abgerufen am [JL] Sun, List Java 2 Plattform SE 5.0 API Dokumentation des Interfaces List Abgerufen am [JRMI] [WSK] Sun, The Java Tutorials RMI Implementing a Remote Interface Abgerufen am Wikipediaartikel Skriptsprachen Abgerufen am [JVSR] Peter Arpad Wesel, Java versus Ruby Dezember 2003 Anwbarkeit des objektorientierten Paradigmas Abgerufen am [RLO] Die Programmiersprache Ruby Abgerufen am