IntelliJ IDEA Scala plugin 2017.1.19: simplified Project View, ScalaTest selection by regexp, improved Akka support

After IntelliJ IDEA 2017.1 was released, we have added many new features to the Scala plugin.

Project View is simplified

We have reworked and simplified navigation to Scala nodes:

  • IDEA 2017-like icon style
  • Type + Companion object nodes
  • Flat package object
  • Files are leaf nodes

To explore the internal structure of a file, enable the “Show Members” parameter in Project View options:


Besides, we provide a View / Tool Window / Structure panel to see the structure of files opened in the editor:

UPDATE: a note about migration to the new scheme

Error highlighting in Project View

We have added error highlighting to Project View. The feature is disabled by default, but you can turn it on by going to Preferences / Languages & Frameworks / Scala / Project View / Highlight nodes with errors:


ScalaTest selection by RegExp

We have introduced a new kind of test suite selection: regular expression. It is now easier and more flexible to designate an exact set of tests in a particular Run Configuration. Here’s how we can filter tests with names that match “.*Phone” and with class names that match “.*UserDataTest”:


New features in Akka support

We’ve added a couple of new features to Akka support in the Ultimate version of the Scala plugin. Now we can highlight dynamic invocations that can be replaced with a constructor call:


Besides, the refactoring can suggest a system name as a candidate:


Your feedback on these improvements is very welcomed. Expect more features and improvements in the upcoming 2017.2 release of the IntelliJ Scala plugin.

P.S: Don’t forget to report bugs you find directly into our issue tracker.

Develop with Pleasure!

This entry was posted in New Features, Release report and tagged , , , . Bookmark the permalink.

7 Responses to IntelliJ IDEA Scala plugin 2017.1.19: simplified Project View, ScalaTest selection by regexp, improved Akka support

  1. Mike Slinn says:

    Where is the “Show Members” parameter in Project View options?

  2. Steve Swing says:

    The versioning confuses me. The blog post says: “…the upcoming 2017.2 release of the IntelliJ Scala plugin.” I’m using the IDEA 2017.2 EAP and already have the 2017.2.2 Scala plugin. Does 2017.2.2 already have the changes? A 3-minute github pull request comparison of 2017.1.19 vs 2017.2.2 was not immediately obvious. Thanks!

  3. Stefan Endrullis says:

    Sorry to say that, but the new Project View is IMO a big regression. I have a lot of Scala files that contain a normal class and one or two case classes (one-liners) used by this class. When I look at the project view now, I see several of those gray paper icons with a tiny scala symbol. They look completely different to all other class icons. It looks like something is wrong with this class, such as IDEA could not parse the file or was unable to detect the type. Why did you chose such a strange icon for this? Why didn’t you use the normal class icon with a small plus symbol indicating that this class is not alone?

    I have to admit that I was so annoyed by those icons that I started to extract the small case classes into separate files. After a short time I stopped and reverted everything again, since I recognized that I started to flood my project with dozens of tiny files making it harder and harder to get an overview of what is really important. Those case classes belong to their main classes and should be located their, too.

    Enabling “Show members” is also not an option since then I’ll get flooded with thousands of methods and fields I don’t want to see in the Project View. Moreover it doesn’t fix the “ugly gray paper icon” bug.

    So it seems that the only solution is to inline every additional class into the main class, although I don’t like this so much or to wait for the “gray paper icon” fix. :\

    • Pavel Fatin says:

      Hi Stefan,

      We believe that the new scheme is a considerable improvement over the previous one, while the perceived inconveniences are mainly due:

      1. improper representation of “static nested classes”
      2. suboptimal code that was indulged by the previous scheme.

      If some auxiliary class is used solely by a primary class, this class should be either:

      • inner class, and so be placed in the primary class itself,
      • static nested class, and so be placed in the companion object, by analogy with other “static” members. It seems that this is how it’s intended in Scala – in JVM bytecode such a class is compiled in the same way as a static nested class in Java.

      The first case is fairly obvious, while the second case is often overlooked, and people tend to emulate true static nested classes by placing auxiliary classes alongside with the main class. Such classes however are not properly encapsulated and are visible to other classes in the same package, even if declared private. Placed auxiliary classes in a companion object enforces the encapsulation and automatically solves the mentioned problem with the Project View.

      The second potential pitfall is due to the previous Project View layout – there were no much separation between a file and a directly from the standpoint of the UI, so many people used files in the capacity of directories, which is, however, suboptimal, from many points of view:

      • it’s file, not class that is a unit of compilation, so placing multiple large classes inside a single file can hider incremental compilation,
      • many IDEs and most file managers display only file / directory structure, so relying heavily on specific view while designing project structure can hider project analysis in other tools,
      • presenting file and directory almost in the same way actually limits the capabilities of programmer – by reducing the number of ways one can layout / encapsulate classes.

      With the new scheme, programmer can choose whether one wants to list classes “as is” or to “encapsulate” a set of classes in a single file, and that choice can be deliberate. Because the previous scheme indulged programmers to “abuse” files, some existing project structures might look awkward after the initial transition, but 1) splitting excessively joined classes and 2) joining excessively split classes should make project layout actually more structured and more clean.

      And when one chooses to put multiple classes into a single file instead of a directory, it seems reasonable to present this file as a file, not as a directory, without exposing the inner file content. IDEA has dedicated means for displaying file structure, namely structure tool windows and file structure popup. It seems that the primary use case for “compound” files is placing many small classes in a single file (e.g. colors.scala), when these classes doesn’t belong to any particular main class, and when listing each single class name in Project View is redundant.

      As to why the class + companion object is presented as a single node: the rationale is that companion object is just a holder of static entities for the corresponding type, and they act as a single entity. We don’t list static members in Java separately, and in Scala it’s even easier to find them. As class + companion object combo is extremely typical in Scala, this simplification cleans project view big time.

      Additional argument for the new Project View scheme is that other languages (for example, Kotlin) uses the same approach, so that’s good for the standpoint of consistency.

      It seems that the new scheme covers all the typical use cases and improves things quite a bit. Once the typical pitfalls are overcome, you can get much cleaner project tree and a seamless navigation.

  4. Randall Schulz says:

    I have to disagree about the file iconography change. I don’t think it’s your place to decide what is “suboptimal” to be “indulged” or not.

    If you feel the need to state an opinion about how one should structure their code, then add an inspection that we can turn off.

    The creators of the Scala language have determined what is allowed and what is not. It is up to programmers to choose how they will use the language. Given the fact that IDEA’s Scala plug-in still contains errors in determining what is actually valid code (that which the compiler accepts), I would prefer you improve the plug-in’s fidelity to the language rather than add opinionated heuristics that cannot be disabled.

  5. Randall Schulz says:

    It has been two weeks.

    I would appreciate a reply from JetBrains on the matter of the changes in the most recent release of the Scala plug-in for IDEA.

Leave a Reply

Your email address will not be published. Required fields are marked *