Features Download
From: Alex Blewitt <alex.blewitt-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
Subject: Scala modularisation withdrawl
Newsgroups: gmane.comp.lang.scala.internals
Date: Monday 19th October 2009 23:31:56 UTC (over 7 years ago)
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.

CD: 4ms