By Scala IDE team on Jul 07 2014
contents of this blog post have been superseded by the most
recent nightly. Go there
for the latest documentation.
We are thinking of uniting the development of the Scala IDE to
just a scala 2.11 branch, while still supporting 2.10
projects. For that, we need rock-solid support for 2.10, and
you can make a difference. This blog post is here to give you
news about the development — up to the latest nightly — and
enlist your contributions in reporting possible problems or
errors. More details on how to contribute below.
Developments in multi-version support
As you may have heard, the
latest milestone of the Scala IDE comes with the ability to
interpret both 2.10 and 2.11 projects. In the
it’s now much better.
The executive summary is this: the IDE still comes built on and
embedded with a single version of the Scala compiler (the latest
2.11). It runs it to access your code for all interactive
functions (typechecking, etc). But that presentation compiler
now has the ability to run in “2.10 compatibility” mode,
interpreting your types and terms with the logic that was valid
in the legacy version of Scala.
For non-interactive functions (i.e. building), the compiler will
send your code to a regular, unmodified 2.10 compiler that we
ship along the IDE.
So, when using the IDE, your 2.10 projects shouldn’t change. In
should be that of a regular 2.10 project — that is, they should
have the 2.10 scala-library on classpath. So goes for other jars
and libraries you might use, whether 2.10 projects like play or
other compiler-associated jars, like scala-swing.
Projects created with the Scala IDE, or with
sbteclipse, set the
path to the scala-library using a classpath container, an
abstraction designed to help with managing machine-scpecific
paths towards a set of jars. These classpath containers (one
for the lirbary, one for the compiler), in particular, represent
the technical notion behind what Eclipse calls
These containers, in the latest milestone, always pointed to the
default version of Scala (2.11). To use an IDE-created project
with Scala 2.10, you had to get rid of the classpath container,
and replace it with your own jars in the Java Build Path
menu. Or you could use sbteclipse with the
withBundledScalaContainers := false option to generate an
Eclipse project which would explicitly link to sbt-provided scala
latest nightly (as
of July 4th), you now have the freedom of configuring the content
of the Scala classpath containers.
The first user-visible change is that the switch between the 2.10
and 2.11 modes is now a clearer, more visible toggle at the
project-specific compiler options level.
A dialog will still pop up if your classpath suggests your
project may be configured to run on 2.10, and it has the
same effect as setting the toggle to 2.10 above.
The default for the whole workspace-wide IDE plug-in is still to
run on 2.11 so that you will for now have to make this setting
If you now head to the workspace-wide preferences (Window →
Preferences on Windows/Linux, or Eclipse → Preferences on
OSX), you can see under the Scala heading an Installed Scalas
window which lists the Scala versions you can use.
Those translate directly to your classpath containers, that is
setting the source level toggle selects the corresponding scala
installation for your project.
To witness that, you can have a look at your project’s classpath
(Java Build Path in your project’s Properties). Or you can
unfold your project’s details in the Package Explorer. You’ll
see this for a 2.10 project:
You also have the option of editing that container (right-click
→ Properties in the Package explorer, double-click or Edit
in the Java Build Path window). You can the choose amongst the
installed Scala versions
Beware, that edition does not affect your source-level flag
in and of itself, though consistency checks may pop up a dialog
suggesting you to set the source level according to what you just
put in the container.
We are evaluating the possibility of
dropping 2.10 builds of the Scala IDE,
which would save us the time and effort spent maintaining them,
as well as let us enjoy the gains brought by the
latest scala version. We’d
be able to deliver IDE features much faster ! But this can only
be done if this multi-version support is reliable. For this, we
need testing. Have any 2.10 projects you want to work on ?
Install the latest nightly, use the 2.10 support, and
tell us about any
problems you encounter !
The source level toggle in compiler settings does not give
immediate feedback on the “Additional parameters” line of
compiler options, even if it adds
-Ymacro-expand:none to it. If you save, close the compiler
options dialog and reopen it, you should see those compiler
options added explicitly.
There is currently no option to define a custom scala
installation, and use it to configure the classpath container of
your projects. We are actively working on this.
of the multiple-scala-version support still apply.