Alex Blewitt | 20 Oct 01:31 2009
Picon

Scala modularisation withdrawl

The Scala modularisation proposal was put forward in the hope of avoiding some of Java's mistakes in the past, most notably the failure to split up the runtime into more modular components. In order to modularise, it's necessary for there to be binary backward compatibility between modules as otherwise this defeats the point of modularisation, since you just end up with a fragmented set of JARs that are coupled tightly together through their binary interactions.

In addition, it was hoped to avoid Java's mistake of using a constant 1.x version number, regardless of what happened with the underlying implementation. In part, the fault for this lay with the marketeers who coined the Java 2 moniker, which essentially prevented the existence of a Java 2.x release ever in the future. Learning from others mistakes, and in particular, the difference between the version of a package/module and a marketing release, is something that would be well heeded here.

Sadly, we are not in the position today to move Scala's modularisation forward. There is a lot of fragility in the binary output of the Scala compiler, and although it would be possible to encode modular constraints between the compiler and the runtime, the leaking of implementation details of both traits and implicits has been shown to be problematic (such as the Java5/Java6 builds being spun off at the moment for the same release). The last straw of this is the choice of version number for the next release of Scala, which not only causes backward compatibility breaks but also changes (and in some cases, completely removes) deprecated code.

Pretty much any other project, with the possible exception of Java itself, would recognise this as a fairly big hit to backward compatibility and bump it up to a 3.0 release. Instead, we're left with a stream of 2.x releases, each more incompatible than the last; and with each time a corporation gets burnt in the 2.x to 2.x+1 migration (whereby the have to recompile everything just to make sure it works) it will be one more reason not to trust Scala in the future. 

What is far more telling, however, is the reasons against doing this. "too much has been said and printed about Scala 2.8" and "My personal quality standards for a '3' are a lot higher than for a '2.8'" are essentially the only arguments being put forward. When one basis policy on gut feelings and mentions on webpages (http://www.scala-lang.org/node/1564) rather than commonly accepted semantics for version numbers, it should not be a surprise when the release engineering process for Scala is called into question.

In any case, I have no further input of value on the modularisation work; I'll leave the requirements distilled at http://wiki.github.com/alblue/scala/scalamodularisation in case someone wants to clone them before I drop the repository at the end of the month.

Alex

Gmane