IDE Architecture

The Scala IDE for Eclipse uses JDT (Java Development Tools) weaving in order to inherit as much as possible of the existing Eclipse Java functionality. Aspect J and the weaving service of Eclipse (in fact, its OSGi container, called Equinox) allow us to intercept method calls in the JDT, and provide Scala-specific implementations for things like the source code editor or the indexer.

By hooking into the JDT, and providing specific implementations of JDT interfaces, Scala elements (classes, types, methods, etc) are seen by the JDT as Java elements, meaning:

• Java code completion “sees” Scala classes
• the Java presentation compiler “sees” errors when using Scala classes
• JDT tools, such as the JUnit runner, just ‘work’
• lots of UI elements can be reused (the Outline View, Package Explorer, etc)

Of course, Scala elements can not be faithfully represented in Java terms. Some Scala features will be therefore only partially supported when working in mixed Java-Scala projects (for instance, type members are represented as normal, value fields).

JDT Weaving and Java integration

All Scala aspect code is found in org.scala-ide.sdt.aspects. This module defines

• pointcuts and aspects to intercept JDT method calls
• Java interfaces and classes that are used by these aspects. The main IDE module, org.scala-ide.sdt.core implements or inherits these classes. This way, there is a clean separation between the hooks, and the actual implementations.

The other side of this coin is the actual Scala-specific implementation in sdt.core. Package scala.tools.eclipse.javaelements contains Scala subclasses of Java element classes, such as ScalaClassElement or ScalaDefElement.

Although the JDT defines interfaces for these elements, we inherit from their internal implementations. This makes our code prone to breakage in newer releases of the JDT, but gives us much more functionality. In some cases it is even impossible to do otherwise, as the JDT code itself casts such interfaces to their concrete, internal, implementations.

The Scala structure builder

The workhorse of Java-Scala integration is the ScalaStructureBuilder class. This class translates Scala abstract syntax trees to the JDT model elements (using the Scala specific subclasses, of course), and it is fully responsible for the way the Eclipse Java compiler (and related JDT tools or UI elements) sees Scala code.

Code completion/Hyperlinking

Although not intended to be extended with other languages, the JDT offers extension points for some functionality. Whenever possible, we prefer to use the regular, supported mechanism for extension, instead of weaving. This is the case for both code completion and hyperlinking.

The Scala Presentation Compiler

In order to provide semantic actions, the IDE needs to ‘understand’ the edited Scala code. That means parsing and type-checking. The Scala presentation compiler is described in its own page, and it is an asynchronous front-end compiler for Scala, part of the standard scala compiler.

Code formatting

Code formatting is delegated to Scalariform, a library for automated Scala formatting written by Matt Russell. Structured selection (ScalaStructureSelectEnclosingAction) and tokenising for syntax colouring (ScalaCodeScanner) are also backed by Scalariform.

Refactorings

Refactoring is delegated to the scala-refactoring library written by Mirko Stocker.