Die Plugin-Download-Seite von Spamihilator bedarf einer umfassenden Überarbeitung. Ich möchte diese Gelegenheit nutzen, um mich ein wenig mehr mit Scala zu beschäftigen. Um die Praxistauglichkeit zu testen, möchte ich Scala auch in Verbindung mit Lift, Spring und Hibernate benutzen. Das ganze soll zudem als Applikation unter OSGi laufen. Als IDE kommt Eclipse mit dem Scala-Plugin zum Einsatz. In den nächsten Wochen werde ich hier über meine Erfahrungen berichten.
Ich habe mich nach einiger Prüfung für den Einsatz der aktuellen Version Scala 2.8.0 Beta 1 entschieden, da die neue Sprachdefinition einige Vorteile gegenüber 2.7 besitzt (wie zum Beispiel die überarbeitete Collection-API oder Default-Arguments, die ich aus C++ gewohnt bin).
Erzeugen eines neuen OSGI-Bundles mit Scala-Nature
Zunächst muss die Scala IDE für Eclipse installiert werden. Danach kann man Scala-Programme mit Eclipse schreiben, ausführen und sogar debuggen. Das Plugin ist gut benutzbar, jedoch noch lange nicht so ausgereift wie die Java-Unterstützung von Eclipse. Hier und da stößt man noch auf kleinere Bugs. Zum Beispiel werden manchmal Fehlermeldungen im eigentlich korrekten Quellcode angezeigt, die sich nur dadurch entfernen lassen, dass man “Project/Clean…” benutzt und alles neu kompiliert. Dies passiert jedoch erfreulicherweise relativ selten.
Um ein OSGi-Bundle mit Scala-Nature zu erzeugen, muss man in Eclipse zunächst ein ganz normales Plugin-Projekt erzeugen. Danach muss man die Scala-Nature hinzufügen, damit der Scala-Quellcode kompiliert werden kann. Dazu klickt man mit der rechten Maustaste im Navigator oder Package Explorer auf das neue Projekt und wählt “Scala/Add Scala Nature”. Dadurch werden folgende Einträge in die Datei .project eingefügt:
1 2 3 4 5 | <buildCommand> <name>ch.epfl.lamp.sdt.core.scalabuilder</name> <arguments> </arguments> </buildCommand> |
1 | <nature>ch.epfl.lamp.sdt.core.scalanature</nature> |
Damit die Scala Library genutzt werden kann, muss man in der META-INF/MANIFEST.MF das Bundle “scala.library” als “Required Bundle” angeben:
1 | Require-Bundle: scala.library;bundle-version="2.8.0" |
In einigen Fällen muss man zusätzlich die Scala-Library zum Classpath hinzufügen. Dazu kann man die Datei .classpath manuell anpassen:
1 | <classpathentry kind="con" path="ch.epfl.lamp.sdt.launching.SCALA_CONTAINER" /> |
Falls es danach immer noch nicht möglich ist, Scala-Klassen zu kompilieren, kann es daran liegen, dass sie nach wie vor als Java-Quellcode interpretiert werden. In diesem Fall muss man den Java-Builder in den Projekt-Eigenschaften deaktivieren. Dadurch kann man innerhalb eines Projekts natürlich keine Scala- und Java-Klassen mehr mischen. Zwischen unterschiedlichen OSGi-Bundles funktioniert es jedoch problemlos. Es ist anzunehmen, dass dies ein Fehler der aktuellen Beta-Version der Scala IDE ist, denn laut Dokumentation sollte dieses Feature eigentlich funktionieren.
Bewertung
Der Scala-Compiler erstellt normalen Java-Bytecode sodass eine vollständige Integration mit Java und OSGi sichergestellt ist. Etwas störend ist die unvollständige Unterstützung von OSGi-Package-Imports der Scala IDE. Wenn man einmal ein Package aus einem Bundle per Import-Package importiert hat, kann man danach auch Klassen aus allen anderen Packages dieses Bundles im Scala-Quellcode importieren. Die IDE zeigt dabei keine Fehler an. Zur Laufzeit kommt es jedoch korrekterweise zu ClassNotFoundExceptions. Man hat somit zwei Möglichkeiten:
- Auf
Require-BundlestattImport-Packageumsteigen, was jedoch nicht empfohlen ist. - Nach dem Auftreten der Laufzeitfehler die Packages manuell importieren (erfahrende OSGi-Entwickler kennen diese Vorgehensweise sowieso) und auf eine neue Version der Scala IDE warten.
Hinzufügen zu: