Scala and Play 2.0 Plugins Update 0.22.302 is Available

Today the new versions of Scala and Play 2.0 plugins for IntelliJ IDEA 12.1 have been released and are available for download. The build process of Scala and Play plugins since today is similar, so Play plugin has the same build number as Scala plugin.

The new features in the release include:

  • Rearranger for Scala (for IDEA 13 only)
  • New extractors support for Scala 2.11
  • Rename and find usages for scala setters


  • SCL-5778 Rename of scala members and classes from java code
  • SCL-5779 Renaming usages of scala objects in java code
  • SCL-4336 in-place rename of back-ticked references
  • SCL-3926 Option for not renaming companion class or object
  • SCL-5579 Class with backticks now resolved from anywher
  • SCL-6010 Fixed call by name parameters in Java
  • SCL-5973 Override and implement method actions does not use procedure syntax

This is the last feature release for IntelliJ IDEA 12 (only bugfixes releases are expected). There will no nightly builds for IntelliJ IDEA 12 anymore. We start nighlty builds for IntelliJ IDEA 13 (Cardea).

Please note that if you are running IntelliJ IDEA 13 EAP you should use 0.24.50 (or higher) version of Scala and Play plugins. They are compatible with the latest EAP (132.425 or higher).


Posted in Uncategorized | 7 Comments

Scala and Play 2.0 Plugins 0.19.297 Update is Available

Today the new versions of Scala and Play 2.0 plugins for IntelliJ IDEA 12.1 have been released and are available for download. In case if you have the plugins already installed just press Update Plugin. From now the build process of Scala and Play 2.0 plugins is common, so Play 2.0 plugin has the same build number.

Please note that if you are running IntelliJ IDEA 13 EAP you should use 0.21.45 (or higher) version of Scala and Play 2.0 plugins. This plugin will be available to use with upcoming EAP (32.106 or bigger)

The new features in the release include:

  • Convert Scala to Java collection (contribution by jozic)
  • Global completion for type aliases
  • Completion based on runtime time in debugger evaluate expression
  • Generate companion object action
  • Generate equals/hashCode (available for IDEA 13 only)


  • Fixes in parallel compilation of independent modules.
  • Better “show type on mouse” action. No blue highlighting, configurable delay.
  • SCL-6018 Inplace rename does not work for declarations and definitions
  • SCL-5970 Function rename doesn’t rename overriden methods
  • Evaluate expression in debugger for interpolated strings
  • Fixes in Introduce Variable
  • SCL-5592 Better path dependent types resolve in case of selector set imports, probably with renames
  • SCL-5938 Evaluate expression in anonymous functions and for loops
  • Fixed resolve precedence between package local classes and imported classes
  • Fixed some red code issues in projects, which use Spray library
  • Bugfixes in Play 2.0 plugin including better parser and analyzer

Here you can see, that plugin version for IDEA 13 and IDEA 12 are slightly different. Next October release will be remain almost synchronous, however after that development will be moved for IDEA 13 and almost everything will be in releases for IDEA 13 only.



Posted in Release report | 10 Comments

Scala and Play 2.0 Plugins 0.16.293 Update is Available

Today the new versions of Scala and Play 2.0 plugins for IntelliJ IDEA 12.1 have been released and are available for download. In case if you have the plugins already installed just press Update Plugin. From now the build process of Scala and Play 2.0 plugins is common, so Play 2.0 plugin has the same build number.

Please note that if you are running IntelliJ IDEA 13 EAP you should use 0.18.28 (or higher) version of Scala and Play 2.0 plugins.

The new features in the release include:

  • Introduce field refactoring
  • Display type on mouse hover action (available from settings)
  • Convert Java collection to Scala collection intention (jozic contribution)


  • SCL-5889 Fixes in breakpoint placement
  • SCL-5858 Fixed deadlock
  • SCL-4784 Improved unused import detection
  • Fixes in Debugger evaluate expression including evaluation of references to values defined in patterns.
  • Various Inplace Introduce Variable fixes
  • Implemented Java/Scala collection detection in Play project
  • Lots of stability improvements in Play plugin


Posted in Uncategorized | 18 Comments

SBT Plugin for IntelliJ IDEA Nightly Builds

SBT build definitionWe know that you have been waiting for SBT project support in IDEA too long. That’s why we make SBT plugin nightly builds available even before an actual release of the plugin.


Though work on SBT plugin is still in progress, the following features are already available:

  • SBT project import.
  • Incremental project model updating.
  • Auto-import (on project definition changes).
  • Editing of .sbt files (with full highlighting, auto-completion and navigation).

Many more features are on the way (see the roadmap below).


SBT plugin is currently available for IDEA 12 (“Leda”), the plugin builds for the IDEA 13 EAPs are coming soon.

You can use any of the following methods to install or update the plugin in IDEA:

  • Automatic updates (recommended)
    Add the following URL to the list of custom plugin repositories in Settings | Plugins | Browse Repositories | Manage Repositories:
    After that, you may install the plugin via Settings | Plugins | Browse Repositories.
    IDEA will check for the latest plugin builds automatically.
  • Manual download
    Get the latest build from SBT plugin nightly builds page and install the downloaded archive via Settings | Plugins | Install plugin from disk.

  • Build from sources
    If you are eager to get the latest snapshot of the plugin, you may use SBT plugin project on GitHub to clone the plugin repository by entering the following command:
    Then run sbt dist to build a binary distribution of the plugin (you may need to specify locations of IDEA and Scala plugin first).


To import an SBT project in IDEA use either File | Open or File | Import Project menu command and then choose a desired build.sbt file (alternatively, you may choose a project root directory).

IDEA will analyze the SBT project structure and create a corresponding project model that includes all required modules, source/output directories, libraries, dependencies, etc.

If you select Use auto-import check-box in the import dialog, IDEA will monitor the SBT project definition for changes and update the corresponding project model automatically (preserving your local modifications to the project).

In addition to ordinary modules (which correspond to SBT “projects”), IDEA creates special “SBT” modules, which describe SBT build definitions themselves (.sbt files and Scala files in project directories) in order to provide highlighting, auto-completion and navigation for these files and SBT libraries.


Here are the features that we’re going implement in the near future:

  • SBT console.
  • Command tool window.
  • Project make via SBT.


Keep in mind that SBT plugin project is currently in alpha stage, don’t be too hard on it :)

Please, report bugs and submit feature requests to our YouTrack (set “SBT” as a subsystem).

Post ideas and questions to our forum.

Complete plugin code is available as a project on GitHub.

Posted in News and Events | Tagged , , , , , , , | 31 Comments

Scala and Play 2.0 Plugins 0.13.286 Update is Available

Today the new versions of Scala and Play 2.0 plugins for IntelliJ IDEA 12.1 have been released and are available for download. In case if you have the plugins already installed just press Update Plugin. From now the build process of Scala and Play 2.0 plugins is common, so Play 2.0 plugin has the same build number.

Please note that if you are running IntelliJ IDEA 13 EAP you should use 0.15.20 version of Scala and Play 2.0 plugins.

The new features in the release include:

  • Inplace introduce variable
  • Inplace rename for all elements
  • Disabled by default inspection for functions with explicit Unit return type
  • Added inspection for functions in procedure-like syntax (if you think it should we enabled by default, please vote for it)
  • Better Find usages and rename for Play 2.0


  • SCL-1971 Implicit formal parameter setter could be resolved
  • SCL-3338 Good code is red: tuple views are not found unless tuple values are explicitly enclosed in parentheses
  • SCL-5677 NoClassDefFoundError when running an “All in package” scalatest using “In whole project”
  • SCL-5790 Good code red: path-dependent types
  • SCL-5729Overloading resolution fails for few collection classes
  • SCL-5726Forward reference with local lazy val incorrectly produces “wrong forward reference”
  • SCL-5735 Wrong “Unnecessary parentheses” quick-fix
  • Lots of Introduce variable bugfixes
  • Lots of stability improvements and bugfixes in Play 2.0 plugin



Posted in Uncategorized | 11 Comments

IntelliJ IDEA at Scala Days 2013, Survey and License Winners

Thanks to everyone who joined us last week in New York City for Scala Days 2013. We were impressed by how many passionate developers came to the conference. Special thanks to James Ward and TypeSafe for inviting us to such a great event.

It was also a pleasure to see a lot of the attendees at our session Scala Developer Tools in IntelliJ IDEA, where we presented the new features of the IDE for Scala developers, and announced the early preview of SBT support. We hope to post a recording of this session soon so everyone can watch it. In the meantime you can see the slides from the presentation.

While at the conference we ran a quick survey on Scala. We asked every developer who came to our booth to answer a few questions on their experience with Scala and IntelliJ IDEA. Over a hundred Scala developers gave us their feedback, and we’d like to share the results with you. Continue reading

Posted in News and Events | Tagged | 6 Comments

Scala Plugin 0.10.279 Update is Available

Right before the Scala Days 2013 we are exciting to announce that the new version of Scala plugin for IntelliJ IDEA 12.1 has been released and is available for download. In case if you have the plugin already installed just press Update Plugin.

The new features in the release include:

  • SCL-5267 Inspection to check isInstanceOf call in if statement
  • SCL-5613 Inspection to check collection chain methods can be simplified


  • Performance improvements of method dependent types
  • Lots of fixes in highlighting for projects using scalax.Graph library

There are also good news that the team of Scala support in JetBrains is growing. Nikolay Tropin is now responsible for all refactoring tools of the Scala plugin.

We would also love if you join us at JetBrain’s booth on Scala Days 2013 conference, which will take place in New York on 10-12th of June. At our booth you will be able to learn more about Scala support from our team. Be sure to attend our session Scala Developer Tools in IntelliJ IDEA on Wednesday, June 12th from 11:15 – 12:00.

Develop with Pleasure!

Posted in Uncategorized | 23 Comments

Scala plugin 0.7.264 and Play2 plugin 0.2.49 were released!

We are happy to announce new versions of Scala and Play2 plugins for IntelliJ IDEA 12.

Currently we are planning to make releases at the beginning of every month. This is one part of huge plan to make plugin more stable and regular. Nightly builds are still available to get fixes more quickly.

New features:

  • Inplace rename for generators and enumerators bindings in for expressions
  • Replace do-while with while and vice versa intentions
  • SCL-5603 Inspection for simplifying boolean expressions with boolean literals
  • SCL-5602 Inspection for double negations in boolean expressions
  • Create from usages quickfix in route files of Play2 project


  • Performance improvements
  • SBT-based compiler improvements
  • Improved method dependent types support in highlighting
  • SCL-4935 More robust breakpoint positioning for macro-arguments
  • SCL-5594 Single tuple argument in case classes generates right unapply method
  • SCL-4699 Browsing types (CTRL-N) defined in package objects
  • SCL-5569 Fixed type inference for generic Scala methods in Java
  • SCL-4703 Extra closing brace added incorrectly due to parsing error in scala doc
  • JavaScript parser errors caused by scala injection in Play2 templates
  • Formatter improvements in Play2 templates (fixed HTML indenting)
Posted in Release report | 11 Comments

Smarter Code Completion for Scala

Following the release of IntelliJ IDEA 12.1 the Scala plugin has been updated as well bringing to you a bunch of enhancements.

You might already know that IntelliJ IDEA provides a fantastic set of code completion features for Java, including instant completion, type-aware completion, chain completion, etc. You can find the full list in Top 20 Features of Code Completion in IntelliJ IDEA article. Almost everything mentioned in the article now is available for Scala developers.

Check out the new statement code completion for Scala:

We hope with this new feature you become even more productive and get more pleasure from development.

Please feel free to share your feedback on the discussion forum and report bugs directly to our issue tracker.

Develop with Pleasure!

Posted in Uncategorized | Leave a comment

A new way to compile

Together with the IDEA 12 release Scala plugin brings a brand new Scala compilation subsystem. Here are the main updates:

  • The compilation is now “external”.
  • Incremental compilation is now handled by SBT (instead of IDEA itself).
  • Compile server is now implemented via Nailgun (instead of FSC).

Of course, a lot of explanations is needed to clarify all the details.

External build

External build is a one of the major features of IntelliJ IDEA 12.

External build implies that all compilation tasks (including project model interpretation) are performed in a separate process, fully isolated from the main IDE’s process.

As a result, we can:

  • lower IDEA memory consumption and free its garbage collector;
  • reduce load on IDEA’s code model (PSI) and virtual file system (VFS);
  • speedup compilation (according to this and that).

Now we can compile IDEA projects without running IDEA itself, e. g. from command line or from build tools (like Ant, Maven, etc.).

An additional benefit is an ability to use an automatic background compilation, so that your project will be kept in compiled state all the time.

Background compilation can be also used as a means to reveal code errors when type-aware highlighting can’t keep up with code complexity.

For more information on external build you may check the Brand New Compiler Mode in IntelliJ IDEA 12 blog post.

SBT compiler

Although “SBT compiler” sounds like a completely new kind of Scala compiler, that is not really so. To see what SBT compiler is and how it fits into Scala compilation, let’s start with a “big picture”.

Here are the main tasks we need to perform during Scala project compilation:

  • We need to compile source code to bytecode (and to search for all kind of errors along the way). This task is always performed by Scalac (or Javac, for Java sources) no matter what tool is used to invoke it (IDE, SBT, Maven, Ant, Zinc or whatnot). So, Scalac (and Javac) is the actual “true” compiler, however it knows nothing about project structure, incremental compilation and so on. All it can do is to take a list of source files and produce a set of corresponding compiled classes.
  • We need to perform compilation incrementally (as opposed to compiling all sources all the time). Strictly speaking, this task is not required for project compilation (and it can even slow down a full project build). The whole point here is to save time during subsequent compilations. To do that, we need to track code changes and re-compile only affected files. And it is harder than it sounds — we need to monitor timestamps, store source-to-output mappings, check for public API changes, analyze direct and transitive dependencies (including ones between Scala and Java) and so on. There are not many tools capable of such a feat, and that is exactly what SBT “compiler” (as well as IDEA) does.
  • We need to compile project parts according to project structure i. e. to split project into separate, possibly dependent, modules of various types (test, production, resources, etc.), devise compilation order, apply compiler settings, provide required libraries and so on. Each tool (like IDEs, SBT, Maven, etc.) uses its own way of describing and storing project information.

So, bytecode is still generated by Scalac (and Javac), project format is still IDEA’s, but incremental compilation is now handled by SBT instead of IDEA (so, we don’t use SBT project model, only SBT compiler, that acts as a wrapper around Scalac).

What’s the point of such an update? – Because there is a qualitative difference between how IDEA and SBT discover dependencies and process changes.

IDEA analysis is bytecode-based and language-agnostic. While it’s a very fine-grained, robust and time-proved method, there may be some rare unexpected glitches, specific to Scala code.

For example, let’s define a class C (in C.scala):

and then “add” a method name via an implicit conversion (in Main.scala):

After we compile and run the main method, we will see that the output is “foo”, and that’s what we expect it to be.

Then, let’s add a “real” method name to the class C:

After the next compilation, we will discover that the output is … still “foo”, and that is is not what we expected… Why so? – Because, in terms of the bytecode, there’s no need to recompile Main class yet.

There are many additional cases (for example, related to named- and default parameters) which demonstrate, that bytecode analysis is not enough for proper incremental compilation of Scala code.

That is where SBT compiler comes to rescue, because it relies on source-based analysis of compiled code (to do that, SBT intercepts internal Scala compiler data), so it can take account of Scala-specific details to perform incremental compilation correctly (though SBT analysis of Java classes is still bytecode-based).

As a bonus, because SBT uses a so-called compiler interface layer to communicate with the Scala compiler, we can now run multiple versions of in-process Scala compilers in the same JVM. That’s how we can:

  • reap the benefit of JIT compilation (either during compilation of multiple modules or when using a compile server),
  • avoid creation of temporary files (with compiler arguments),
  • avoid compiler output parsing,
  • make compiler JVM parameters (in Scala facet) obsolete.

It’s worth noting, that there is a one side-effect of using SBT compiler, resulting in how Java files are handled in Scala projects (ones with a least one Scala facet). Because we need to maintain a coherent model of dependencies, compilation of all Java files, event in “pure” Java modules, is routed through SBT. For most use cases that is perfectly OK, unless you need to use a non-standard Java compiler (by the way, SBT supports in-process Java compiler as well).

For more information on SBT compiler you may check Understanding Incremental Recompilation article in SBT documentation.

New compile server

Scala compiler is a quite complex piece of software, so it takes time to load and initialize it. When you compile a project with hundreds (or thousands) of files, this time is negligible comparing to the time needed to compile the code. However, when incremental compilation is used, and all you need is to re-compile a few files, it may take longer to warm-up a Scala compiler than to actually compile those files.

One solution to this problem is to run Scala compiler in-process to avoid compiler re-instantiation when compiling subsequent modules. This, however, still cannot liberate us form a first compiler initialization. To speedup compilation further, we need to use a pre-initialized compiler instance, and that is exactly what compile server does.

Originally, Scala compile server was implemented via FSC (Fast Scala Compiler). While it works well enough, it has several limitations:

  • FSC instance is bound to a single compiler version, so compile server settings were a part of project configuration and FSC instances are not shared between projects.
  • Because FSC reuses symbol table between runs, it sometimes might produce various errors during compilation.

Now, because of our newfound ability to run multiple versions of Scala compiler in a single JVM, we can do better than that. New compile server is implemented using Nailgun (basically, it’s just a JVM process that can be accessed via a TCP/IP connection), so:

  • It is now a matter of personal preference whether or not to use a compile server. Compile server configuration is moved from project settings to application settings.
  • Compile server is now application-wide – it is reused for multiple compiler versions and shared between all projects (so we can save a lot of RAM).

Compile server configuration is now located in Settings / Scala:

It’s recommended to use the following JVM parameters for the Scala compile server:

  • -server – to maximize peak operating speed (for the price of longer start-up time) and to encourage soft references retention (that we use to cache compiler instances).
  • -XX:MaxPermSize=256m – to provide enough memory for loading of multiple sets of compiler classes.
  • -Xss1m – to ensure that there will be enough stack space for recursive code in Scala compiler.

If compile server is not used, it’s still recommended to use the same parameters (except, maybe, -server) in Project Settings / Compiler / Additional compiler process VM options.

How all this is related to Zinc

Zinc is a stand-alone launcher for SBT incremental compiler (and Nailgun server). It was created, primarily, to be used in command line tools (like Scala Maven Plugin).

Because both Zinc and the new compilation subsystem use the same tools and techniques, they are essentially equivalent. There is not much sense in using a launcher from another launcher, so we run both SBT compiler and Nailgun directly, rather than via Zinc.

Besides, we need much more data from the compiler (to display compilation messages, report progress, compile UI forms, run annotation processors, etc.) which is not available from Zinc output. Zinc’s Nailgun server also cannot be used by IDEA because its process is started without IDEA-specific classes (communication protocol) in JVM classpath.

As Zinc cannot build a project by itself, it must be invoked from another tool (like Maven), which stores all incremental compilation data using its own scheme, that differs from IDEA’s one. So, currently we cannot unite IDEA’s and Zinc/Maven’s incremental compilation even though they are very much alike.


Let’s sum-up all the advantages of the new Scala compilation subsystem:

  • Less load on IDEA process.
  • External project build.
  • Background compilation.
  • Source-based incremental compilation.
  • In-process Scala and Java compilers.
  • Simplified project configuration.
  • Application-wide compile server.

There must be a catch in it somewhere, you know… And here it is – because the new compilation subsystem is written completely from scratch, some bugs are simply inevitable. Please, report them so we can fix them as soon as possible.

Keep in mind, that the previous compilation subsystem is still available, and can be always turned on by clearing “Use external build” checkbox in Project Settings / Compiler page:

IDEA compiler configuration

You may also check there whether the external build is enabled in your existing projects.

For those who want to know even more details, here is source code for all the tools:

Posted in Uncategorized | 65 Comments