Neue Play-Roadmap: Was uns in Play 2.1 und Play 2.2 erwartet

Hartmut Schlosser

Play war lange Zeit das nette, kleine Web-Framework von nebenan, das man aber nicht so richtig ernst genommen hatte – bis es in den offiziellen Scala-Stack des Unternehmens Typesafe aufgenommen wurde. Im Typesafe-Stack bildet Play nun eine prominente Scharnierstelle im Zusammenspiel mit der Sprache Scala, dem Middleware-Framework Akka sowie diversen Tools wie der Scala IDE für Eclipse. Deshalb interessiert es, in welche Richtung Play zukünftig weiterentwickelt wird – mehr in Richtung Scala (in Play 2.0 wurde der Framework-Kern komplett neu in Scala geschrieben) oder weiterhin auch über Java APIs zugänglich? Hinweise darauf gibt eine neue Play-Roadmap, die als Google Doc aktuell die Runde macht.

Mit Play lassen sich Realtime Web-Anwendungen mit Scala und Java APIs bauen. Inspiriert ist Play von Produktivitätsframeworks wie Ruby-on-Rails und Django, abgezielt wird auf die Entwicklung von hochskalierbaren Enterprise-Anwendungen. Produktivitätsgewinne werden u.a. dadurch erzielt, da mit Play Codeveränderungen an einer Anwendung direkt, ohne das Anstoßen des umständlichen Build-Deploy-Prozesses sichtbar werden – sogenanntes „Hot Code Reloading“ (in Play 1.x wurde hierfür der Eclipse-Java-Compiler verwendet, in Play 2.x kommt das Scala-Build-Tool sbt zum Einsatz).

Aktuell liegt Play in der Version 2.0.4 vor. Die veröffentlichte Roadmap betrifft die bevorstehende Version 2.1 und gibt Ideen für die folgende 2.2 vor.

Play 2.1 wird zunächst einmal mit Scala 2.10, Akka 2.1 und sbt 0.12 integriert laufen. Insgesamt sollen über 100 gefixte Bugs für eine bessere Stabilität sorgen. Desweiteren stehen Support für OpenID in Java, für SSL und injectable Controller, überarbeitete Test APIs sowie Verbesserungen der CSRF Protection, des Scala JSON APIs und des Java Async APIs auf dem Programm. Tests sollen auch auf einer geforkten JVM ausgeführt werden können.

Außerdem auf der Liste:

  • API improvements to iterateeIO library
  • Support for route files in sub-projects
  • improved error reporting for external DSLs on play console (routes, templates)
  • Play Promise Scala API was replaced by the new scala.concurrent.Future library (SIP-14)
  • Introduced „Project templates“ hosted on git (a la giter8) and „Scaffolding“.
  • Simplify configuration for thread pools and ExecutionContext
  • Improved modularization (break the main play artifact into several smaller optional ones).
  • Compilation speed improvements (scalac 2.10, sbt 0.12.1, router optimizations)
  • Upgraded dependency libraries
  • introduced new ExternalAssetController (useful only in Dev Mode)
  • Incremental asset compilation
  • Improved asset dependency resolution (RequireJS support)

Die Version Play 2.2 sieht dann die Unterstützung für Java 8 vor. Außerdem sollen mögliche neue Backends ausprobiert werden: Servlets 3.1 oder auch Spray (spray.io). Allerdings sollen neue Backend-Technologien nur dann offizielle Unterstützung finden, wenn alle existierenden Play-Features genutzt werden können. Ein weiterer wichtiger Punkt ist die Modularisierung. Die laufenden Bemühungen auf diesem Gebiet sollen fortgesetzt werden und etwa durch die Auslagerung von JavaScript, CoffeeScript oder Google Clojure aus dem Play Core weitergeführt werden. Auf der Support-Liste neuer Technologien steht interessanterweise auch TypeScript, die JavaScript-Variante, die jüngst von Microsoft ins Spiel gebracht wurde.

Natürlich ist diese Wunschliste zunächst noch mit Vorsicht zu genießen – welche Features es tatsächlich in die 2.2 schaffen werden, wird noch von vielen Umständen abhängen. Eins zeigt die Roadmap aber doch deutlich: Vom grundsätzlichen Weg, Play für Scala- und für Java-Entwickler interessant zu halten, rückt man nicht ab.

Bleibt eigentlich nur noch der Hinweis darauf, wann wir mir Play 2.1 oder gar mit Play 2.2 rechnen können. Doch ausgerechnet in diesem Punkt schweigt sich die Roadmap aus. Weiß jemand von Ihnen Genaueres?

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.