Warum Scala kein kreatives Spielwiesenprojekt mehr ist

Hartmut Schlosser

Scalas Versionierungspolitik steht im Fokus einiger jüngst erschienenen Blogposts, in denen das Problem aufgeworfen wird, dass die häufigen Brüche der Binärkompatibilität bei neuen Scala-Versionen eine Hürde für die Verbreitung von Scala in Enterprise-Szenarien darstellt. Tiefe Einsichten in diese Problematik gibt nun David Pollak („Scala’s version fragility make the Enterprise argument near impossible„), der Begründer des Scala-Frameworks Lift. Seine Kernaussage trifft unsere Analyse in früheren JAXenter-Beiträgen:

Hatte man Scala als Community- und Forschungsprojekt gewisse Freiräume bzgl. Entwicklungsprozesse, Stabilität und Tooling-Einbindung eingeräumt, so hat sich das Bild mit den aktuellen Bestrebungen der Professionalisierung von Scala – vor allem vorangetrieben durch Martin Oderskys Unternehmen Typesafe – geändert.

Scala ist kein kreatives Spielwiesenprojekt mehr, in dem Kompatibilitäten zu früheren Versionen dem kreativen Output der Sprachdesigner weichen müssen. Scala muss sich auch in den Entwicklungsprozessen professionalisieren, will es tatsächlich Fuß in Enterprise-Projekten fassen.

„It’s pain and it’s pain that could go away“

Lift-Designer Pollak beschreibt das aktuelle Problem der Generierung von „fragilem Byte-Code“ durch den Scala-Compiler. Quellcode in einem JAR oder WAR müsse derzeit mit den identischen Versionen von Bibliotheken und Kompilern übersetzt werden. Verwendet man beispielsweise Scala 2.9.1 in seinem Projekt, muss gegen eine Version von Lift kompiliert werden, die selbst gegen Scala 2.9.1 kompiliert wurde. Alle Lift-Abhängigkeiten müssen ebenfalls gegen Scala 2.9.1 kompiliert werden.

Als Folge dieses Problems sei es nicht möglich, Lift bzw. Lift-basierte Anwendungen mit den neuesten Scala-Entwicklungsversionen zu testen.

  1. All dependencies must be compiled against the exact same version of Scala and every referenced Scala library which makes in-house builds when there are multiple teams amazingly complex or time-consuming
  2. External libraries (like Lift) cannot have multiple layers of dependencies because you need to match the exact version of every library and Scala version all the way down
  3. David Pollak

Als wünschenswert stellt Pollak deshalb die Reaktivierung des Projektes „Scala Fresh“ vor, ein Ort für die kontinuierliche Integration aller Libraries und Frameworks im Scala-Ökosystem.

Basically, the idea was to have continuous integration of the major libraries in Scala-land and weekly milestones so that the community and the ecosystem could give better feedback on new versions of Scala. David Pollak

Rettung in Sicht?

Die Rettung naht – das verspricht jedenfalls Typesafe-Entwickler Josh Suereth in seiner Antwort auf Pollak („Scala Fresh is alive„). Tatsächlich sei das angesprochene Versionierungsproblem nicht trivial, da neue Scala-Sprachfeatures tatsächlich und notwendigerweise die Binärkompatibilität des Bytecodes brechen.

Das Dilemma ist ein altbekanntes: Will man eine Technologie dynamisch weiterentwickeln, ist es nötig, alte Zöpfe abzuschneiden. Gleichzeitig handelt man sich aber Einbußen bei der Rückwärtskompatibilität und Stabilität ein – was beispielsweise in den letzten Jahren immer wieder als Argument gegen eine Modernisierung von Java ins Feld geführt wurde.

Suereth beschreibt die aktuelle Praxis bei Scala, dass alle Versionen der Scala 2.9.x-Entwicklungslinie binärkompatibel gehalten werden. Genauso sollen alle zukünftigen 2.10.x-Versionen Binärkompatibilität aufweisen. Mittels des Tools Migration Manager ist es laut Suereth möglich, auch die Bibliotheken in den jeweiligen Entwicklungszügen unverändert weiter zu nutzen.

Suereth kündigt außerdem die Wiederbelebung des Scala-Fresh-Projekts – quasi Scala Fresh 2.0 – an: Ein Ort, an dem Community-Bibliotheken gegen die neuesten Versionen von Scala entwickelt und deployed werden können. Ziel des Projektes ist es explizit auch, sicherzustellen, dass zukünftige Scala-Versionen nicht inkompatibel zu Community Libraries werden. Außerdem soll gewährleistet werden, dass die Scala Core Libraries für jede Major-Version von Scala verfügbar sind.

I, and others, are working hard to ensure the ecosystem for every major Scala release is easy to use and stable. Migrating major Scala versions should be as difficult as finding deprecation warnings and removing them. Josh Suereth

Suereth betont aber auch, dass Binärkompatibilität nur durch eine gemeinsamen Community-Anstrengung gelöst werden kann. Die Antwort auf Pollaks Klagen lautet deshalb:

So while David’s post highlights an issue, my response is: Help us (the Scala community) out! We’re going there, we’re doing that. Josh Suereth

Scala Feature-itis?

Eine spannende Phase für Scala, in der Erfolg oder Misserfolg von Projekten, wie von Josh Suereth beschrieben, ausschlaggebend für die Akzeptanz von Scala werden kann – womöglich mehr, als die Integration neuer Bleeding Edge Features in Scala 2.10.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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