public interface Base {
    public void base();
    public void useBase();
}

public interface Foo extends Base {
    public void foo();
    public void useFoo();
}

public interface Bar extends Foo {
    public void bar();
    public void useBar();
}

public interface FooBar extends Foo, Bar {
    public void useFooAndBar();
}

Die useXYZ-Methoden können allgemein unter Rückgriff auf die anderen Methoden des Interfaces oder der Super-Interfaces implementiert werden, und sollten deshalb in abstrakte Klassen ausgelagert werden. Natürlich kann die abstrakte Klasse für FooBar nur von einer der beiden in Frage kommenden abstrakten Klassen erben, sagen wir von der zu Foo. Dann haben wir folgendes Szenario:

public abstract class BaseAbstract implements Base {
    public abstract void base();
    public void useBase() {
        System.out.println("using Base.base()");
        base();
    }
}

public abstract class FooAbstract extends BaseAbstract implements Foo {
    public abstract void foo();
    public void useFoo() {
        System.out.println("using Foo.foo() and Base.base()");
        foo();
        base();
    }
}

public abstract class BarAbstract extends BaseAbstract implements Bar {
    public abstract void bar();
    public void useBar() {
        System.out.println("using Bar.bar() and Base.base()");
        bar();
        base();
    }
}

public abstract class FooBarAbstract extends FooAbstract implements FooBar {
    public abstract void bar();
    //DUPLICATED
    public void useBar() {
        System.out.println("using Bar.bar() and Base.base()");
        bar();
        base();
    }
    public void useFooAndBar() {
        System.out.println("using everything");
        base();
        foo();
        bar();
    }
}

Wie man sieht, bleibt bei dieser Version nichts anderes übrig, als in FooBarAbstract den Inhalt von Bar zu wiederholen.

Mein Vorschlag, das Problem zu lösen, verletzt so einige OO-Prinzipien und wird dadurch unflexibel gegenüber nachträglichen Änderungen. Ich würde ihn nur empfehlen, wenn die Hierarchie wirklich feststeht und man sich damit erhebliche Code-Duplizierungen erspart (also wenn Anzahl und Umfang der useFoo()- und useBar()-Methoden recht groß ist. Der Trick beruht darauf, die Implementierung von useBar() schon in BaseAbstract zu erledigen. Dazu wird eine Hilfsmethode _bar() benötigt, die dort wo vorhanden (also in Bar und FooBar) einfach zum „echten“ bar(), das ja vom Nutzer der abstrakten Klasse bereitgestellt werden muss, weiterleitet:

public abstract class BaseAbstract implements Base {
    public abstract void base();

    public void useBase() {
        System.out.println("using Base.base()");
        base();
    }
    
    //Ersatz-Methode für bar()
    protected void _bar() {
       throw new UnsupportedOperationException(); 
    }
    
    //Code, der eigentlich in BarAbstract gehört
    public void useBar() {
        System.out.println("using Bar.bar() and Base.base()");
        _bar(); //benutzt die Ersatz-Methode
        base();
    }
}

public abstract class FooAbstract extends BaseAbstract implements Foo {
    public abstract void foo();
    public void useFoo() {
        System.out.println("using Foo.foo() and Base.base()");
        foo();
        base();
    }
}

public abstract class BarAbstract extends BaseAbstract implements Bar {
    public abstract void bar();

    //Delegation, sonst funktioniert useBar() nicht
    @Override protected void _bar() { bar(); }
}

public abstract class FooBarAbstract extends FooAbstract implements FooBar {
    public abstract void bar();

    //Delegation, sonst funktioniert useBar() nicht
    @Override protected void _bar() { bar(); }
    
    public void useFooAndBar() {
        System.out.println("using everything");
        base();
        foo();
        bar();
    }
}

Wie so oft wird mein Code keinen Schönheitspreis gewinnen, weil er mit den Beschränkungen von Java kämpft. Es ist ein Kompromiss, der zur Wahrung des DRY-Prinzips andere Konventionen verletzt. Man sollte sich sehr genau überlegen, ob diese Technik an einer bestimmten Stelle wirklich sinnvoll ist, aber wenn sie es ist, kann sie einige Arbeit sparen.

Wie immer bin ich natürlich neugierig, ob jemand eine bessere Idee hat.

Wie sieht die Haskell-Lösung aus?

class Summable a where
  total :: a -> Int

instance Summable Int where
  total = id  

instance Summable x => Summable [x] where
  total = sum . map total  

total ([[[1,2,3],[4,5]],[[6],[7,8,9,10]]] :: [[[Int]]])
--55

Aha, Typklassen! Wir definieren eine Typklasse „Summable“, die eine Funktion „total“ zum Aufsummieren enthält. Die Instanz für Int ist trivial: Wir geben einfach die Zahl selbst zurück (man hätte dafür auch total x = x schreiben können). Interessanter ist die Instanz für Listen, die eine sogenannte Context-Bound enthält: Wenn a in der Klasse Summable ist, dann ist auch eine Liste von a in der Klasse – genau die Art von „Rekursivität“, die wir brauchen. Deshalb darf man in der Definition von total auch die Funktion total auf die Elemente anwenden, da man ja weiß, dass sie auch Summable sind. In der letzten Zeile wird die Funktion ausprobiert (dass man u.U. die Typangabe :: [[[Int]]] braucht, hat nichts mit unseren Typklassen zu tun, sondern ist der „Monomorphismus-Restriktion“ geschuldet, und wäre bei nicht-numerischen Typen nicht notwendig).

Wie setzt man das nun in Scala um? Ich habe mich zuerst mit einer typklassenartigen Implementierung versucht, bin aber nicht so recht weitergekommen. Am Ende hat dann eine etwas direktere Vorgehensweise zum Ziel geführt:

object nestedTest {
  
  case class Summable(total:Int)
   
  implicit def intSummable(i:Int) = Summable(i)
  
  implicit def listSummable[T <% Summable](list:List[T]) = Summable(list.map(_.total).sum)
  
  def total[T <% Summable](t:T) = t.total
  
  def main(args: Array[String]) {
    println(total(1))
    println(total(List(1,2,3)))
    println(total(List(List(1),List(2,3))))
    //println(total(List(List("a"),List("b","c")))) 
    //--> error: No implicit view available from List[List[java.lang.String]] => nestedTest.Summable.
  }
}

Summable ist jetzt keine Typklasse, sondern einfach ein Wrapper um Int. Dann definiere ich entsprechende Konvertierungen. Wieder ist die Umwandlung von Int nicht besonders spannend, dafür die Definition der List-Variante. Der entscheidende Trick ist die Verwendung einer View-Bound T <% Summable. Das heißt, dass T in ein Summable "umwandelbar" sein muss, und genau das ist der Trick, um Scala die gewünschte "Rekursivität" beizubringen. Durch die Garantie der View-Bound ist es erlaubt, map(_.total) zu schreiben, denn wir wissen ja, dass T in ein Summable konvertiert werden kann, und Summable hat ein Feld namens total. Für die Bequemlichkeit definieren wir noch eine Top-Level-Funktion für total, um dem Anwender das Hantieren mit Summable zu ersparen. In der main-Methode werden nun verschiedene Varianten ausprobiert. Ein Aufruf mit einem unpassenden Argument scheitert, und das sogar mit einer recht verständlichen Fehlermeldung.

Ich hoffe, dass das Beispiel gezeigt hat, dass Scalas Typsystem dem von Java auch bei recht praktischen Aufgabestellungen überlegen ist, auch wenn man manchmal etwas frickeln muss. Haskell glänzt hier mit einer sehr einfachen Variante, aber es gibt auch Konstrukte, die sich besser mit Scala implementieren lassen (z.B. alles mit variabler Anzahl Argumente).

Ich fasse schon einmal den guten Vorsatz, das Blog nächstes Jahr nicht ganz so stiefmütterlich zu behandeln. An spannenden Themen soll es nicht mangeln: Da wäre das gerade frisch releaste Ceylon (allerdings mit noch enttäuschenden Funktionsumfang), Bauarbeiten an Scala und Java, die tolle Sprache Frege, die langsam erwachsen wird und ihr Vorbild Haskell, bei dem auch interessante Neuerungen anstehen, wenn man Simon Peyton Jones glaubt.

Dann wünsche ich allen ein Frohes Fest, einen Guten Rutsch und ein erfolgreiches 2012!

object IndexOf {
   def unapply[T](pair:(Seq[T],T)):Option[Int] = {
     val index = pair._1.indexOf(pair._2)  
     if (index == -1) None else Some(index)
   }
}

object ReverseIndexOf {
   def unapply[T](pair:(Seq[T],T)):Option[Int] = {
     val index = pair._1.indexOf(pair._2)  
     if (index == -1) None else Some(pair._1.size - index - 1)
   }
} 

Nun kann man ein paar aus einer Sequenz und einem Element matchen:

def testIndexOf(n:Int) = (List(1,2,3,4,5,6,7),n) match {
  case IndexOf(0) => println("first")
  case IndexOf(1) => println("second")
  case ReverseIndexOf(1) => println("second to last")  
  case ReverseIndexOf(0) => println("last")  
  case IndexOf(x) => println("indexOf==" + x)
  case _ => println("not found")  
}

(1 to 8).foreach(testIndexOf(_))
//--> first
//--> second
//--> indexOf==2
//--> indexOf==3
//--> indexOf==4
//--> second to last
//--> last
//--> not found

In der vorliegenden Form ist das vielleicht noch nicht sooo furchtbar nützlich, aber das Prinzip lässt sich gut verallgemeinern. Ich finde es jedenfalls interessant, selbst Extraktoren zu schreiben, statt mich mit vorgefertigten oder durch Fallklassen autogenerierte Extraktoren zu begnügen.

Neuerdings wollte ich bei einem Scala-Projekt ScalaTest in Maven zum Laufen bringen, konnte aber kaum brauchbare Informationen darüber finden.

So stößt man beim googlen nach „maven scalatest plugin“ hauptsächlich auf Diskussionen, die darauf hinauslaufen, dass man eine @RunWith – Annotation an die ScalaTest-Suites anhängen und weiterhin mit JUnitRunner leben soll, etwa so:

import org.scalatest.junit.JUnitRunner
import org.junit.runner.RunWith
import org.scalatest.Spec
import org.scalatest.matchers.ShouldMatchers
 
@RunWith(classOf[JUnitRunner])
class MySpec extends Spec {
    // ScalaTest spec code here
}

Das ganze wird dann einfach vom maven-surefire-plugin aufgegriffen, und als ein klassischer JUnit-Test ausgeführt. Das funktioniert zwar einigermaßen, aber es liefert nicht wirklich die erhoffte übersichliche Liste mit Testergebnissen wie hier angepriesen. Daraus ergibt sich die Frage: Wie bringt man Maven dazu, den org.scalatest.tools.Runner für die Scala-Suites und Specs zu verwenden?

Die Antwort lautet: Das maven-scalatest-plugin statt maven-surefire-plugin nutzen. Dies ist ein erst vor kurzem von Jon-Anders Teigen entwickeltes Maven-Plugin, und kann (noch) nicht aus den maven-repositories heruntergeladen werden: Man muss es stattdessen direkt von Teigens Seite herunterladen und installieren. Dies bewerkstelligt man, indem man den Installationsanweisungen auf der Projektseite folgt, also:

1. Man stelle sicher, dass man über eine funktionsfähige Version von git verfügt
2. Man klone das angegebene Repository. Teigen selbst empfiehlt Sean Griffins Repository. Ich habe es mit Teigens Version riskiert, und es scheint zu funktionieren.
3. Man installiere das Plugin, wie in der Anleitung beschrieben (ebenfalls nur ein kurzer Maven Befehl)

Wie verwendet man es nun in dem eigenen Projekt? Ich will es direkt an einem kleinen Beispielprojekt demonstrieren. Dazu lassen wir uns zuerst ein Archetyp-Projekt von maven erzeugen:

> mvn archetype:generate
[...fürchterlich lange liste mit allen möglichen Archetypen, sorgt dafür dass eure Konsole die letzten paar Tausend Zeilen anzeigen kann...]
Choose a number: 139: 446
Choose version:
1: 1.0
2: 1.1
3: 1.2
4: 1.3
Choose a number: 4:
Define value for property 'groupId': : blog.escalation
Define value for property 'artifactId': : example
Define value for property 'version':  1.0-SNAPSHOT: :
Define value for property 'package':  blog.escalation: :
Confirm properties configuration:
groupId: blog.escalation
artifactId: example
version: 1.0-SNAPSHOT
package: blog.escalation
 Y: : Y

Nun erstellen wir ein paar Source-Dateien, eine primitive Applikation im main-Ordner, und eine ScalaTest-Suite im test-Ordner:

So sollte die Struktur des Projektes aussehen:

--example
  |--.gitignore
  |--pom.xml
  `--src
     |--main
     |  `--scala
     |     `--blog
     |        `--escalation
     |           `--App.scala
     `--test
        `--scala
           `--mytestpackage
              `--MyAppSuite.scala

Die ersten beiden Dateien wurden von archetype erzeugt, der src-Ordner wurde ebenfalls automatisch angelegt. Den mytestpackage-Ordner muss man extra erzeugen: Das soll nur zeigen, dass man seine Tests so ordnen kann, wie man will.

So könnten die beiden Scala-Dateien aussehen:

package blog.escalation

object App {
  
  def foo(x : Array[String]) = x.foldLeft("")((a,b) => a + b)
  
  def main(args : Array[String]) {
    println("Hello World!")
    println("concat arguments = " + foo(args))
  }
}

package mytestpackage

import org.scalatest.FunSuite
import org.scalatest.matchers.ShouldMatchers
import blog.escalation.App._

class MyAppSuite extends FunSuite with ShouldMatchers{
  
  test("concatenate words"){
    foo(Array("hello", "world")) should equal ("helloworld")
  }
  
  test("reverse hello world"){
    "dlrow olleh".reverse should equal ("hello world")
  }
  
  test("relativity theory test"){
    val E = 90
	val m = 10
    val c = 3
	E should equal (m * c * c)
  }
  
  test("string theory test")(pending)
}

Nun der wichtigste Schritt: pom.xml anpassen. Bevor wir ins Detail gehen, hier die gesamte POM:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>blog.escalation</groupId>
  <artifactId>example</artifactId>
  <version>1.0-SNAPSHOT</version>
  <name>${project.artifactId}</name>
  <description>My wonderfull scala app</description>
  <inceptionYear>2010</inceptionYear>
  <licenses>
    <license>
      <name>My License</name>
      <url>http://....</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <properties>
    <maven.compiler.source>1.5</maven.compiler.source>
    <maven.compiler.target>1.5</maven.compiler.target>
    <encoding>UTF-8</encoding>
    <scala.version>2.9.0</scala.version>
  </properties>

  <repositories>
    <repository>
      <id>scala-tools.org</id>
      <name>Scala-Tools Maven2 Repository</name>
      <url>http://scala-tools.org/repo-releases</url>
    </repository>
  </repositories>

  <pluginRepositories>
    <pluginRepository>
      <id>scala-tools.org</id>
      <name>Scala-Tools Maven2 Repository</name>
      <url>http://scala-tools.org/repo-releases</url>
    </pluginRepository>
  </pluginRepositories>

  <dependencies>
  
    <!-- necessary for compilation of scala code -->
    <dependency>
      <groupId>org.scala-lang</groupId>
      <artifactId>scala-library</artifactId>
      <version>${scala.version}</version>
    </dependency>

    <!-- IMPORTANT: add dependencies that are necessary for testing -->  
    <dependency>
      <groupId>org.scalatest</groupId>
      <artifactId>scalatest_2.9.0</artifactId>
      <version>1.6.1</version>
      <scope>test</scope>
    </dependency>
	
	<!-- if you don't need junit, you can leave this dependency out, but maven will download it anyway
	<dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.8.1</version>
      <scope>test</scope>
    </dependency>
    -->
	
  </dependencies>

  <build>
    <sourceDirectory>src/main/scala</sourceDirectory>
    <testSourceDirectory>src/test/scala</testSourceDirectory>
    
	<!-- IMPORTANT: add this pluginManagement-tag to your POM -->
	<pluginManagement>
	  <plugins>
	    <plugin>
	      <groupId>com.jteigen</groupId>
	      <artifactId>maven-scalatest-plugin</artifactId>
	      <version>1.1-SNAPSHOT</version>
	    </plugin>
	  </plugins>
	</pluginManagement>
	      
	<plugins>
      <plugin>
        <groupId>org.scala-tools</groupId>
        <artifactId>maven-scala-plugin</artifactId>
        <version>2.15.0</version>
        <executions>
          <execution>
            <goals>
              <goal>compile</goal>
              <goal>testCompile</goal>
            </goals>
            <configuration>
              <args>
                <arg>-make:transitive</arg>
                <arg>-dependencyfile</arg>
                <arg>${project.build.directory}/.scala_dependencies</arg>
				<arg>-deprecation</arg>
              </args>
            </configuration>
          </execution>
        </executions>
      </plugin>
	  
	  <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.6</version>
        <configuration>
          <useFile>true</useFile>
          <disableXmlReport>true</disableXmlReport>
          <includes>
            <include>**/*Test.*</include>
            <include>**/*Suite.*</include>
			<include>**/*Spec.*</include>
          </includes>
		  <!-- IMPORTANT: if you want to deactivate tests run by surefire-plugin, add this tag: -->
		  <skipTests>true</skipTests>
        </configuration>
      </plugin>
	  
	  <!-- IMPORTANT: this is the plugin we want to use -->
      <plugin>
	    <groupId>com.jteigen</groupId>
	    <artifactId>maven-scalatest-plugin</artifactId>
	    <version>1.1-SNAPSHOT</version>
		<executions>
          <execution>
            <goals>
              <goal>test</goal>
            </goals>
          </execution>
        </executions>
		<!-- this is the standard way to configure maven-plugins: by adding "configuration"-tag -->
        <configuration>
		  
		  <!-- tell the plugin where your classes are -->
		  <runpath>target/test-classes,target/classes</runpath>
		  
		  <!-- this just finds all Suites in mytestpackage-package of your test-classes -->
		  <wildcards>mytestpackage</wildcards>
		  
		  <!-- "W" means "Without color", it removes the ANSI-color-chars from the output -->
		  <stdout>WD</stdout>
		  
        </configuration>		
	  </plugin>
    </plugins>
  </build>
  
  
  <reporting>
    <!-- This is necessary for creating scaladoc -->
    <plugins>
      <plugin>
        <groupId>org.scala-tools</groupId>
        <artifactId>maven-scala-plugin</artifactId>
		<version>2.15.0</version>
      </plugin>
    </plugins>
  </reporting>
</project>

Diese pom.xml unterscheidet sich von der ursprünglichen an vielen Stellen, hier die wichtigsten Punkte:

1. scala.version ist auf 2.9.0 hochgesetzt
2. scalatest-dependencies sind hinzugefügt
3. pluginmanagement-Tag im build-Tag hinzugefügt
4. maven-surefire-plugin mit dem skipTests-Tag deaktiviert.
5. maven-scalatest-plugin hinzugefügt und konfiguriert.

An dieser Stelle einige Worte zur Konfiguration des Plugins. Leider scheint noch keine Beschreibung zu existieren, aber man kann alles nötige aus dem Source-Code herleiten. Beachte dazu folgendes:

1. Die Konfiguration des maven-scalatest-plugins sieht komplett anders aus, als die Konfiguration des Surefire-Plugins, copy-paste ist zwecklos.
2. Letztendlich leitet das Plugin alle Parameter an org.scalatest.tools.Runner weiter, deshalb ist es empfehlenswert, sich die Dokumentation anzusehen, damit man weiß, was man alles überhaupt konfigurieren kann.
3. Alle child-Tags des configuration-Tags werden wie hier beschrieben 1:1 auf Member-Variablen des Plugins gemappt.
4. Informationen über die relevanten Member-Variablen kann man meiner Meinung nach am besten direkt aus dem Source-Code des Plugins ablesen.

Einige Beispiele:
1) runpath

<runpath>target/test-classes,target/classes</runpath>

2) stdout

<stdout>WD</stdout>

3) wildcards und members

<suites>mytestpackage.MyAppSuite</suites>
<members>mytestpackage</members>
<wildcards>mytestpackage,otherpackage.with.subpackage</wildcards>

Damit kann man auswählen, wo nach Suites gesucht werden soll. Mit suites kann man eine kommagetrennte Liste von ganz konkreten Suites angeben, was besonders nützlich ist, wenn man die Suites so gruppiert. Mit dem members-Tag kann man eine kommagetrennte Liste von Packages angeben, in der nach Suites gesucht wird. Das wildcards-Tag ist ähnlich, durchsucht aber auch Subpackages, mehr dazu unter Specifying „members-only“ and „wildcard“ Suite paths.

Jetzt, wo die POM fertig ist, können wir beispielsweise alles compilieren und testen:

>mvn test

Run starting. Expected test count is: 4
DiscoverySuite:
MyAppSuite:
- concatenate words (14 milliseconds)
- reverse hello world (2 milliseconds)
- relativity theory test (1 millisecond)
- string theory test (pending)
Run completed in 364 milliseconds.
Total number of tests run: 3
Suites: completed 2, aborted 0
Tests: succeeded 3, failed 0, ignored 0, pending 1
All tests passed.

Wer möchte, kann auch gleich alles verpacken:

>mvn package

>mvn scala:doc

Ich bin jetzt mit dem Zusammenspiel von Scala und Maven vorerst zufrieden, und hoffe, dass dieser Beitrag sich für jemanden als hilfreich erweist.

Grüße, 0x7F800000

Hier nach das Beispielprojekt zum Download, das jar kann mit

jar -xf example.jar

Der Autor weist noch darauf hin, dass es wahrscheinlich schon bald (vielleicht in ein paar Wochen) bessere Lösungen geben wird. Ich möchte mich für die Erlaubnis bedanken, diesen Artikel hier veröffentlichen zu dürfen. Wie immer sind Kritik und Verbesserungsvorschläge jederzeit willkommen.

class MatchAll[S](scrutinee : =>S) {
  def matchAll[R](patterns : PartialFunction[S,R]*) : Seq[R] = {
    val evald : S = scrutinee
    patterns.flatMap(_.lift(evald))
  }
}

implicit def anyToMatchAll[S](scrut : =>S) : MatchAll[S] = new MatchAll[S](scrut)

Und die Anwendung:

(2,4) matchAll (
  { case (2,_) => "starts with two" },
  { case (3,_) => "starts with three" },
  { case (_,4) => "ends with four" },
  { case (a,b) if a + b == 6 => "adds up to six" }
)

//--> ArrayBuffer(starts with two, ends with four, adds up to six)

Ich denke, dass man mit der im Vergleich zu match leicht veränderten Syntax gut leben kann, und fände es gut, wenn dieses Konstrukt auch in die Scala-Bibliotheken aufgenommen würde.

Die Sprache Frege lehnt sich stark an Haskell an, nutzt aber nach Möglichkeit die Gegebenheiten der JVM aus. Interessanterweise folgt Frege nicht dem üblichen Ansatz, direkt zu Bytecode zu compilieren, es erstellt stattdessen erst Java-Klassen (die allerdings weniger zur Abendlektüre geeignet sind) und ruft für diese den Java-Compiler auf.

Die auffälligsten Unterschiede zu Haskell sind die Übernahme des Package-Prinzips und von Private-Modifiern (statt Exportlisten) sowie die Nutzung nativer Strings und Primitive. Einige syntaktische Seltsamkeiten von Haskell wurden gestrichen, aber insgesamt fallen die Unterschiede gering aus.

Die Auswahl an Bibliotheken ist überschaubar und auch das Prelude (das Analogon zum Package java.lang) weist noch einige Lücken auf. Trotzdem macht das Vorhandene einen recht soliden Eindruck, es ist genug Dokumentation zum Loslegen vorhanden und es macht Spaß, ein wenig mit Frege herumzuspielen. Wenn die Kernsprache erst einmal stabil ist, sollte es kein Problem sein, geeignete Haskell-Bibliotheken mit geringen Anpassungen zu übernehmen. Außerdem ist auch der Zugriff auf Java-Bibliotheken ebenfalls recht unkompliziert möglich.

Die vorhandenen Ansätze lassen einen umsichtigen Umgang mit Typklassen erkennen (z.B. werden Funktionen wie null oder length verallgemeinert, so dass sie nicht nur auf Listen arbeiten). Das lässt darauf hoffen, dass bei künftigen Erweiterungen der Typklassen-Hierarchie einige von Haskells Fehlern vermieden werden.

Frege ist eine interessante Alternative zu den anderen JVM-Sprachen, deshalb hoffe ich sehr, dass dieses ambitionierte Projekt vorankommt und sich eine Community herausbildet.

Scala für Android mit Eclipse leicht gemacht

Man kann mit Scala auf Android entwickeln, und es ist nicht besonders schwierig. Trotzdem habe ich ein paar Tage gebraucht um alle relevanten Informationen zu sammeln, und eine Konfiguration zum Laufen zu bringen. Ich denke, dass euch das interessieren könnte, insbesondere weil man nicht einmal 15 Minuten braucht, um eine Umgebung aufzusetzen.

Ich bin der Ansicht, dass man als Entwickler die Möglichkeit haben sollte, so oft compilieren und testen zu können wie nötig. Alles, was einen ausbremst, wie zusätzliche Schritte im Build-Prozess (Treeshaker, ProGuard mit einem Ant-Build), sollte vermieden werden. Ich gehe davon aus, dass während des Entwicklungsprozesses vorwiegend das Android Virtual Device anstatt das tatsächlichen Gerätes verwendet wird. Weiterhin setze ich voraus, dass du kein Ant verwenden willst, sondern wie ich den integrierten Eclipse-Buildprozess.

Wenn Android neu für dich ist (wie es für mich war), kann es nicht schaden, ein paar Grundlagen zu kennen (für Android SDK 12):

• Eine Eclipse-Umgebung für Android aufzusetzen ist nicht schwer. Das ADT-Plugin ist einfach zu installieren und zu benutzen.
• Wahrscheinlich möchtest du wenigstens ein Android Virtual Device (AVD) aufsetzen, um dein Programm testen zu können (wenn du auf einem echten Gerät testen willst, gilt dieser Tipp nicht für dich)
• Eine Android-Anwendung ist eine einzelne .apk-Datei, und diese kann keine Bibliotheken außer denen von Android verwenden. Das heißt, dass die Anwendung alle Bibliotheken enthalten muss, die man verwenden will. Oder man kann das Gerät so manipulieren, dass es zusätzliche Bibliotheken lädt, aber das ist natürlich keine Lösung für Anwendungen, die verteilt werden sollen.
• Man verwendet Java/Scala zur Entwicklung, aber Android benutzt eine eigene, spezielle VM (Dalvik), und der Code muss von .class-Dateien zu Plattform-Code compiliert werden. Das wird vom dx-Compiler erledigt (man kann ihn direkt in den SDK-Tools aufrufen, aber das ist normalerweise unnötig), der eine classes.dex-Datei erzeugt. Diese Datei enthält alle Klassen der Applikation, ähnlich wie ein Jar. Das dx-Tool und die Dalvik-Plattform akzeptieren nicht alles: Einige Klassen compilieren mit dx, werden aber nicht korrekt von Dalvik geladen, und das dx-Tool ist ziemlich beschränkt bezüglich der Menge an Code, mit der es zurechtkommt. Man verwendet Werkzeuge, um den Code und die Bibliotheken auf das absolute Minimum abzuspecken (Treeshaker, ProGuard.). Insbesondere kann dx nicht die vollständige Scala-Bibliothek verarbeiten (zu groß), und Dalvik kommt nicht mit Version 2.9.0 zurecht (es scheitert beim Laden).
• Das SDK enthält einige nützliche Werkzeuge, besonders adb, womit man bestimmte Befehle an ein laufendes virtuelles Gerät senden kann (und wahrscheinlich auch an ein echtes, aber das habe ich nicht probiert). Insbesondere kann man mit dem „adb shell“-Kommando einige eingeschränkte Unix-Befehle senden. Die Details sind im SDK beschrieben. Aber vermutlich wirst du damit nicht allzuviell zu tun haben.

Demnach ist das Problem, was wir mit Scala haben, dass wir alles von uns benötigte aus der Scala-Bibliothek in die Android-Anwendung packen müssen, aber das funktioniert nicht, weil das Ergebnis zu groß für dx ist. Die normale Lösung ist, dem Build einen Schritt zum Zurechtstutzen des Codes hinzuzufügen, aber das erfordert die Verwendung einen eigenen Ant-Builds. Das beim ADT mitgelieferte ProGuard läuft nur, wenn man tatsächlich die Applikation auf ein Gerät exportiert, um sie dort auszuführen, aber nicht bei normalen Durchläufen, und selbst wenn das möglich wäre, würde natürlich der Schrumpf-Schritt jedesmal ausgeführt werden, wenn man speichert und neu compiliert. Das wollen wir nicht.

Stattdessen muss die Umgebung, die wir haben wollen, die Scala-Bibliotheken innerhalb des virtuellen Gerätes bereitstellen (so dass dem Build-Prozess entgehen). Dazu bedienen wir uns Tipps von folgenden Seiten:

• (A) Tweaking the Android Emulator
• (B) Exploring Android

Die erste Seite verlinkt eine Liste vorcompilierter Ramdisks für Android. Ich nehme api_10, aber du kannst auch andere verwenden. Die zweite Seite verweist auf einige vorcompilierte Jars für Android. Dazu später mehr.

Selbstverständlich wollen wir die aktuellsten verfügbaren Werkzeuge:

• Eclipse 3.7 (Indigo)
• Android SDK release 12
• ADT Plugin
• Scala 2.9.0; allerdings sind wir hier aufgeschmissen, weil diese Version von Scala nach dem Compilieren für Android nicht richtig lädt (es gibt ein Problem in den Collections-Packages), deshalb verwenden wir Scala 2.8.1, das funktioniert. Und da wir ein Plugin benötigen, das unter Eclipse 3.7 arbeitet, werden wir das experimentelle 2.8.2 Release verwenden (Update-Seite)

Nun zum Kern der Sache:

• Lade Eclipse Indigo (3.7) herunter und installiere es
• Lade das Android SDK 12 herunter und installiere es
• Installiere das Android ADT Plugin
• Setze den SDK-Pfad in Einstellungen => Android
• Lade das Android Ramdisk Image von (A) für die von dir gewünschte(n) Version(en) herunter
• Suche darin die für dich passende ramdisk.img-Datei und kopiere sie ins Verzeichnis {android-sdk}/platforms/android-XX/images (du solltest vorher eine Kopie der ursprünglichen ramdisk.img-Datei sichern)
• Erstelle ein virtuelles Gerät entsprechen der gerade von dir geänderten Verion. Du kannst dazu den AVD-Manager verwenden, der in Eclipse integriert ist, nacdem das ADT-Plugin installiert wurde.
• Starte das virtuelle Gerät. Das wird etwas dauern. Nutze die Zeit für die folgenden drei Schritte.
• Installiere das Scala-Plugin für Version 2.8.2
• Lade von (B) die vorbereiteten Scala-Bibliotheken mit Version 2.8.1 herunter (nciht vergessen, 2.9.0 lädt nicht korrekt in Android!)
• Entpacke sie und öffne eine Shell (cmd unter Windows), und gehe dann in das Verzeichnis, in das du die 5 Scala Jars entpackt hast.
• Nachdem das virtuelle Gerät bereit ist, sende die folgenden Befehle in der Shell:
  • {android-sdk}/platform-tools/adb shell mkdir -p /data/framework (wenn das nicht klappt, hast du etwas in einem der vorherigen Schritte vergessen)
  • {android-sdk}/platform-tools/adb push scala-library.jar /data/framework
  • {android-sdk}/platform-tools/adb push scala-collection.jar /data/framework
  • {android-sdk}/platform-tools/adb push scala-immutable.jar /data/framework
  • {android-sdk}/platform-tools/adb push scala-mutable.jar /data/framework
  • {android-sdk}/platform-tools/adb push scala-actors.jar /data/framework
  • {android-sdk}/platform-tools/adb shell sync
• Schließe das virtuelle Geräte und starte es neu (ich bin nicht sicher, ob das erforderlich ist)
• Erstelle ein neues Android-Projekt in Eclipse
• Füge irgendwo eine Scala-Datei hinzu, und rechts-klicke dann auf das Projekt: Konfiguration => Scala Natur hinzufügen

Fertig! Du kannst nun sowohl in Java wie auch in Scala entwickeln. Ich würde dringend davon abraten die Android Activity-Klasse zu „scalafizieren“, die für dich erstellt wurde. Speichern und Kompilieren ist so schnell wie man es sich wünscht. Der Programmablauf ist nur durch die Art des Emulators beschränkt, nicht durch die Verwendung von Scala.

Ich überlasse euch selbst den letzten, ultimativen Schritt der Verteilung der Anwendung auf ein Gerät. Wenn ihr das Projekt korrekt konfiguert habt, denke ich aber, dass das ProGuard (der dann und nur dann verwendet wird, wenn die Anwendung wirklich exportiert wird) problemlos erledigen wird.

Yves

Ich hatte dazumal folgendes Codebeispiel gebracht, um zu zeigen, wie man die restlichen Elemente einer Collection beim Pattern Matching erfolgreich ignorieren kann:

def test(list: List[String]) = list match {
  case List("1","2", _*) => "one, two ..."
  case _ => "dunno"
}

Jetzt fragt man sich natürlich, wie man vorgehen muss, wenn man den Rest eben nicht ignorieren will, sondern auch diesen an eine Variable gebunden haben möchte. Die „naive“ Lösung mit etwas wie rest* funktioniert jedenfalls schon einmal nicht. Aber es geht trotzdem, und zwar dank Klammeraffen:

def test(list: List[String]) = list match {
  case List("1","2", rest @ _*) => "one, two with rest " + rest
  case _ => "dunno"
}

test(List("1","2","3","4"))
//--> java.lang.String = one, two with rest List(3, 4)

Achtung, der Rest kann natürlich auch eine leere Liste sein. Für Listen ist dieser Trick eigentlich unnötig, denn hier hat man ja schon den Extraktor ::, aber das Ganze funktioniert natürlich auch für andere Extraktoren mit variabler Argumentanzahl, wie z.B. Seq.

So, dann wünsche ich fröhliches Extrahieren, vor allem meinen Erstlesern bei codekicker.de.

Ich finde das traurig. Richtig, es heißt „Konkurrenz belebt das Geschäft“, aber diese drei Sprachen sind unnötig wie ein Kropf. Es stimmt, Scala kann kompliziert sein und hat auch einige weniger schöne Stellen. Auf der anderen Seite ist es einsteigerfreundlich, innovativ und mächtig, aber vor allem ist es da. Es hat lange gebraucht, um wirklich Bewegung in die Sache zu bringen, eine Community aufzubauen, Tool-Support zu organisieren, ja überhaupt wahrgenommen zu werden. Was inzwischen fast wie ein Selbstläufer aussieht, ist das Ergebnis langer, harter Arbeit. Ich denke, die neuen Sprachschöpfer unterschätzen diesen Aspekt einer Sprache ganz gewaltig.

Viel eigene Innovation ist bei keinem der Kandidaten zu sehen. Aber was mich wirklich stört, ist der Versuch, sich nur die Rosinen aus dem Kuchen zu picken. Das ist nämlich die Art von Geisteshaltung, die Java’s Stillstand erst verursacht hat. Eine gute Sprache ist offen für neue Entwicklungen, und lenkt diese in geordnete Bahnen. Gerade diese Offenheit macht Scala so attraktiv. Doch die Strategie der neuen Sprachen ist die gleiche wie Java: Wasch mich, aber mach mich nicht nass! Features, die „zu kompliziert“ sind oder eventuell missbraucht werden können, werden abgelehnt. In Java waren das etwa Operator-Überladungen, Closures oder Konzepte zur Erweiterung von Interfaces (wie Extensionsmethoden oder Mixins). Jetzt werden aus den gleichen fadenscheinigen Gründen Dinge wie implizite Umwandlungen, abstrakte Typ-Member oder Typpolymorphismus höherer Ordnung abgelehnt – obwohl diese Ideen längst den Praxistest bestanden haben. Was immer wieder übersehen wird ist, dass viele Features, die für die tägliche Arbeit unnötig scheinen, in Bibliotheken und Frameworks essentiell sein können: Jeder, der in Scala eine Liste mapped, verwendet dabei Typpolymorphismus höherer Ordnung – aber er muss dazu nicht einmal wissen, was das ist.

Ich denke dass für viele Detail-Lösungen der neuen Sprachen auch Platz in Scala gewesen wäre, wenn die Macher auf Kooperation gesetzt hätten. Aber jetzt wird viel Arbeit und Gehirnschmalz in Dinge investiert, die es zum größten Teil schon gibt, und Projekte gestartet, die keinen Erfolg haben können. Ein Blick in die Geschichte zeigt, was mit gut gemeinten, aber zu konservativen Ansätzen passiert: Nice hatte viele gute Ideen und nette Details, aber nicht genug, um die Java-Community wirklich zu begeistern, und neue Perspektiven zu eröffnen.

Ich will kein aufgehübschtes Java, und auch kein weichgespültes Scala. Sicher ist es nett, wenn hier und da eine Syntax-Kante geglättet wird. Aber wenn mir am Ende die Ausdrucksstärke fehlt, um meine Gedanken in Code umzusetzen, nützt mir das alles nichts. Ich will keine Sprache zwischen Java und Scala – wenn überhaupt, dann zwischen Scala und Haskell, mit mehr Abstraktionsmöglichkeiten, nicht weniger. Scala ist sicher nicht der Endpunkt der Entwicklung, aber es schwimmt in die richtige Richtung. Nass, aber sauber.

Update

Hier noch ein interessanter Blog-Post, der in die gleiche Richtung und dabei etwas mehr ins Detail geht: Scala, Kotlin, Ceylon… let’s start by being honest.