PDF 285K

Komponentenorientierte Softwareentwicklung
‚eclipse’ und Komponenten
von
Christian “bossk” Holle
( [email protected] )
http://www.bossk.de
und
Markus Breitländer (7044001)
( [email protected] )
[Geschichte]
Im April 1999 fingen OTI und IBM an gemeinsam an Eclipse zu entwickeln, das
ursprüngliche Ziel war eine kommerzielle IDE auf den Markt zu bringen.
Am 5. November 2001 wurde das Eclipse-Projekt von IBM der Open-SourceGemeinde geschenkt. Bis zu dem Zeitpunkt hatte IBM 40 mio. Dollar in die
Entwicklung von Eclipse investiert. Dies geschah aber nicht uneigennützig, den IBM
hat sich mit Eclipse ein ehrgeiziges Ziel gesetzt.
Eclipse soll eine Software-Entwicklungsumgebung werden, die Entwickler im Laufe
der Zeit soweit anpassen können, dass sie damit jegliche Software entwickeln können.
Es soll möglich sein alle Tools, die für die Entwicklung notwendig sind in Eclipse zu
nutzen um somit produktiver und effektiver arbeiten zu können. Zudem sollte ein
Konkurrenzprodukt zu etablierten IDE's, wie NetBeans und Microsofts Visual Studio
entstehen.
Um dieses Ziel zu erreichen übergab IBM Eclipse zunächst einem unabhängigem
Konsortium dem einige namhafte Unternehmen, wie Borland, Rational Software, Red
Hat, SuSE TogetherSoft, Oracle, HP, Fujitsu und einige weiter angehörten. Anfangs
standen einige Entwickler dem Konsortium skeptisch gegenüber. Diese Skepzis, wich
da sich das Konsortium verpflichtete die CPL-Lizens des Kerns von Eclipse zu
bewahren.
Das Eclipse-Konsortium wurde am 2. Februar dieses Jahres in eine „non-for-profit
corporation“ umgewandelt. Durch diese Umwandlung soll ein Eclipse Management
entstehen, welches unter anderem Professionelle Entwickler einstellt, Kooperationen
mit akademische- und Forschungsinstitute eingeht und Open Source-Projekte
koordiniert. Eclipse wird aber weiterhin als Open Source-Projekt weiter entwickelt.
[Plug-Ins]
Im Gegensatz zu anderen Entwicklungsumgebungen / IDEs ist Eclipse keine
monolithische Anwendung, sondern sie baut auf einigen Kern-Klassen auf, die dafür
zuständig sind beim Start von Eclipse weitere Plug-Ins zu laden.
Eclipse basiert somit auf einem „Plug-In Loader“, der beim Start der IDE die weiteren
Plug-Ins lädt. In dem kompletten SDK Release, das man für seine jeweilige Plattform
unter www.eclipse.org downloaden kann, sind schon etliche Plug-Ins integriert, die die
Grundfunktionalität der IDE liefern.
Darüber hinaus gibt es allerdings inzwischen eine große Menge weiterer Plug-Ins, mit
deren Hilfe sich Eclipse in eine wirklich universelle Entwicklungsumgebung modular
erweitern lässt. Dieses Prinzip der modularen Erweiterbarkeit durch Plug-Ins, und die
dadurch
erreichbare
Integration
in
eine
Entwicklungsumgebung
machen
die
Mächtigkeit von Eclipse aus.
Besonders die freie Verfügbarkeit und der hohe Entwicklungsstand des Frameworks
lässt immer mehr Programmierer auf Eclipse umsteigen. Durch die freie API zum PlugIns selber entwickeln (PDE), begründet sich auch das enorme Potenzial, welches
durch die Open-Source-Gemeinde hinter den Plug-Ins steht.
Die Installation eines neuen Plug-Ins ist in der Regel sehr einfach. Die Plug-Ins werden
auf den Seiten der Autoren meist als *.zip- oder *.jar-Archive angeboten. Diese muss
man dann einfach nur in sein \eclipse\plugins\ Verzeichnis entpacken, und Eclipse
daraufhin neustarten. Nach dem Neustart sollte das Plug-In dann bereits eingebunden
sein. Details über die installierten Plug-ins findet man unter dem Menüpunkt „Help“„plug-in details“ – hier kann man noch mal kontrollieren ob das Plug-In korrekt geladen
wurde.
Eine große Auswahl an Plug-Ins für Eclipse findet man unter der url www.eclipseplugins.info. Hier kann man geordnet nach Kategorien nach Plug-Ins suchen, und sich
einen Überblick verschaffen, wie groß die Vielfalt der vorwiegend freien Plug-Ins ist. So
gut wie täglich steigt die Zahl der auf dieser Seite eingetragenen Plug-Ins!
[Omondo UML]
Mit diesem Plug-In lassen sich in Eclipse UML Diagramme zeichnen. Zu den
erstellten Diagrammen generiert Omondo im Hintergrund den Code der
modellierten Klassen. Die Beziehung zwischen Quellcode und Diagramme wird
jeweils konsistent gehalten, das bedeutet, Änderungen im Quelltext werden
auch in die Diagramme übernommen und umgekehrt.
Omondo UML ist für Eclipse 2.1.3 als freies Plug-In zu bekommen.
Leider ist die neue Version, die dann auch mit Eclipse 3.0 zusammenarbeitet ab
jetzt kostenpflichtig.
[Clay Azzurris Database Modelling]
Dieses Tool ermöglicht die Modellierung eines Entity-Relationship Diagramms und
hiervon die Generierung des DDL-Skripts zur Erstellung der Datenbank. Außerdem
kann man aus einer vorhandenen Datenbank des ER-Diagramm erstellen lassen
(Reverse Engineering).
[JFaceDBC / SQL Explorer]
JFaceDBC ist ein visueller Datenbank Browser und SQL-Editor für alle gängigen
Datenbanken. Nach der Installation muss man, wenn noch nicht vorhanden, den
JDBC Treiber für das gewünschte Datenbanksystem bekannt machen und eine
Verbindung zur gewünschten Datenbank einstellen. In der JFaceDBC
Perspektive muss man sich dazu ein neues Alias erstellen, in der der
verwendete JDBC Treiber sowie die URL und Benutzerdaten eingetragen
werden. Über dieses Alias kann dann eine Verbindung zur Datenbank aufgebaut
werden.
Zu erwähnen ist noch, das JFaceDBC zur Zeit keine freie Version der Plug-Ins
für die Eclipse 3.0 Version anbietet. Im Zuge meine Recherchen bin ich auf das
Projekt SQL Explorer gestoßen, dies ist ein Seitenprojekt von JFaceDBC, und
wird von einigen Entwicklern aufrecht gehalten, um die Open-Source Lösung
weiterhin aufrecht zu halten. Hierbei handelt es sich um eine gepatchte Version
von JFaceDBC, welche auch unter der neuen Eclipse 3.0 Version läuft.
[SWT]
[Was ist SWT oder die Geschichte von SWT?]
SWT, das Standard Widget Toolkit, wurde von IBM vor längerer Zeit entwickelt und ist
als Antwort auf SWING entwickelt worden.
Die Entwicklung von SWT reicht bis zu den Ursprüngen von AWT zurück. Als Sun
AWT veröffentlichte, war dies noch sehr fehlerhaft und die Funktionen waren sehr
begrenzt. Die Entwickler gaben daraufhin dem unterschiedlichen Verhalten der
Betriebssysteme die Schuld für die Fehler in AWT. Fakt ist aber, dass Sun AWT zu
früh herausgab. Um diese und andere Missstände zu beseitigen stellte Sun eine neue
Entwicklergruppe aus der Smalltalk-Szene ein. Diese Versprach Sun eine schnelle und
einfache Lösung. SWING entstand und baute, gegen den Willen der Entwickler,
dennoch auf AWT auf.
Die Entwickler von IBM konnten SWING von Anfang nicht leiden. Es war zu
aufgebläht, fehleranfällig und hatte nicht das Look&Fell des Betriebssystems. IBM's
Programme, wie VisualAGe for Java, wurden zu dem Zeitpunkt in Smalltalk, welches
ein natives Widget-Set einsetzt, geschrieben. Trotzdem beschloss das IBM
Management im Zug der weiteren Verbreitung Java das WebSphere Studio auf Java
zu migrieren.
Doch die User und auch die Entwickler waren mit dem Ergebnis nicht zufrieden. Aus
diesem Grunde wurde ein Projekt gegründet, welches die nativen Widgets von
Smalltalk in Java überführen sollte. Diese Aufgabe übernahm die OTI (Object
Technology International). Sie entwickelte SWT, welches keine Abhängigkeiten zu
AWT/SWING hat.
SWT baut auf die native API des Betriebssystems auf. Dies ist meist in C geschrieben
und mit Hilfe von JNI wird darauf zugegriffen. Die Wrapper-Bibliothek von SWT ist sehr
klein und tut - im Gegensatz zu derjenigen von AWT - nichts anderes, als die C/C++
Funktionen in Java abzubilden - SWT selbst ist komplett in Java programmiert.
Durch das Verwenden der nativen Widgets ist ein SWT-Programm nicht von einem
nativen zu unterscheiden - etwas, was Swing trotz der verschiedenen Look&Feels nie
gelang. Zudem ist die Oberfläche eines SWT-Programms schnell und verbraucht recht
wenig Ressourcen, allerdings ist ein SWT-Programm immer noch ein Java-Programm,
weshalb der Arbeitsspeicherverbrauch, genau wie bei Swing auch, recht hoch ist - es
sei denn man erstellt native Programme.
Eine SWT-Applikation läuft ohne Änderungen am Quellcode unter Windows, Mac OS
X, Linux(GTK+2, Motif). Weitere sind in der Entwicklung. Es muss lediglich eine
Änderung von SWT vorgenommen werden. Was heisst das Windows eine andere
SWT-Bibliothek als Linux nutzt.
Ein grosser Vorteil von SWT ist unter anderem, dass es unter der IBM Common Public
License lizensiert ist und somit freie Software ist.
Nachteile sind allerdings,
•
SWT ist etwas aufwändiger zu programmieren ist als SWING
•
SWT unterstützt den Garbage Collector nicht
•
in SWT fehlen Parameterlose Konstruktoren
•
mit SWT ist es nicht möglich ohne weiteres von beliebigen Klasse eigene
Klassen abzuleiten (Ableiten ist nur von Canvas und Composite vorgesehen,
dies gibt den SWT-Entwicklern mehr Spielraum für Änderungen am Toolkit)
Trotz dieser Nachteile ist SWT „im Kommen“. Den die Vorteile überwiegen die
Nachteile. Bester Beweis ist Eclipse!
[Quellen]
Homepage des Eclipse-Projektes
http://www.eclipse.org
Instantiations SWT-Designer
http://www.swt-designer.com
Eclipse - Anwendungen und Plug-Ins mit Java entwickeln
von Sherry Shavor / Dan Kehn / Scott Fairbrother / Jim D'Anjou / John
Kellerman / Pat McCarthy
erschienen Februar 2004 im Addison-Wesley Verlag
ISBN: 3-8273-2125-5