An Interview from JavaOne 2008

JetBrains' IntelliJ IDEA has been among the most popular Java IDEs. In recent years, IntelliJ added support for languages other than Java, and its Ruby and Groovy editing capabilities are considered among the best by many developers. More recently, Flex support was also added to the IDE.

In this interview with Artima, IntelliJ lead developer Dmitry Jemerov explains key focus areas for the upcoming IntelliJ 8 release, including differences between developers relying on the Java and .NET ecosystems, on the one hand, and those using languages and tools outside of Java and .NET, on the other. In addition, Jemerov talks about key features of IntelliJ's recent Flex support. Finally, Jemerov discusses his views on Scala.

On the multi-language focus for IntelliJ 8, Jemerov noted the following:

Polyglot programming is not a new thing: every Web project is a multi-language project. When we introduced support for JSPs many years ago, no one called that polyglot programming, but that's what it was.

Later, when the polyglot programming theme first became popular, people started to use other languages not simply around Java, such as for Web sites, but rather replacing parts of Java code with code written in another language, such as Groovy.

We support quite well the languages that live in the Java ecosystem. Our Groovy support, for example, is among the best. We are working on supporting Scala now, although it's a difficult language to support well in an IDE, and we're in the early stages of the Scala plug-in. The Eclipse and Netbeans folks are all working on Scala support, and I think ours is going to be very good.

In addition to writing parts of a Java application in another language, we can observe that some people have jumped off the Java ecosystem altogether. For example, they switch to Ruby and want to have nothing to do with Java. They have their fancy Rails stuff, Rails servers, such as Mongrel. There's no Java around that, and they want to have nothing to do with Java at all.

Although we support languages that can live outside the JVM as well, our strength in dynamic language support is how well we can help you integrate those languages in your Java projects. For example, we have a very advanced Ruby plug-in, and its key advantage is Java integration. Our JRuby support, integrating between Java and Ruby, is superior to what other IDEs have to offer at the moment.

But that doesn't help people who do not use Java, and do not want to use Java. When we released IntelliJ IDEA 7, we didn't have much to offer to people not wanting to use the Java ecosystem. We have a single, big, Java IDE, and it was not very attractive to developers outside the Java universe. With our forthcoming IntelliJ 8 release, we want to be able to offer something better to those developers, because that's a big and growing market, and there's a lot of innovation in that space.

What we've done in the past four or five months is a very massive refactoring of the IntelliJ IDEA codebase, to separate support for Java from the core platform. We have extracted functionality needed to support an IDE for some language: parsing, refactoring, code manipulation, and so on.

With that in place, we can start building products for other languages based on that platform. Because not all those products will include all the functionality of IntelliJ IDEA, they can be much less expensive, and we can choose the price based on the target market. And developers don't get the stuff they don't care about. The new products can be much slimmer, lighter, and easier to get started with.

There are many differences between a typical Java project and a project that lives outside the Java ecosystem. With Java, in order to start doing something, you need to configure a project: Set up things like the JDK, the sources, the libraries you use. You typically spend five or ten minutes configuring those things. In a Rails project, for example, you don't need to configure anything. There is a standard place where everything lives. We want people to be able to start working with those types of projects with no configuration: Just point to your Rails project, and off you go.

Another major missing piece in our offering was a debugger. Of course, we have a debugger for Java, which we've had since the inception of the product. But for different languages that do not run on the JVM, we did not have any debugging support. That was a major shortcoming, because people want to debug stuff in their IDE, that's one of the main reasons for using an IDE.

There some people who hold the opinion that you should not be using a debugger: Instead of debugging you should write unit tests that cover every method individually so if something breaks, you don't need to debug, but get a failing test instead. It's arguable whether that's the most productive approach. It may be faster to use a debugger once in a while than [to] spend the time to write all the unit tests for every single method.

We now have a framework we can use to build debuggers for any runtime system. The actual way we do that for each language is not something we came up with originally: For both Ruby and Python, there are standard solutions in this space, such as protocols for talking between an IDE and a debugee. For Ruby, there's a project called ruby-debug, and there's something similar for Python as well. We plan to implement all those standard protocols, call stacks, break-points, watches, and so on. We also abstracted away a common UI framework for building debuggers.

In the early-access release for IntelliJ IDEA 8, you can find a debugger for Flex, and one for JavaScript. Both of them are in an early phase. With this, we now have all the pieces to build a complete and attractive product for the non-Java developer market, which is what we're going to focus on a lot in the coming half to one year.

Besides using different languages and runtimes, there are other differences between Java developers, or .NET developers, for that matter, and those not using either of those ecosystems. There are different ways of doing things in the non-Java world. The Java and .NET ecosystems are about big vendors, about middleware, application servers, code generation—here's my WSDL file, please generate a Web service call or a Web service client.

With Python or Ruby, for instance, there no so such big tools. For many tasks, people [in these communities] simply don't need big tools. If you have a dynamic language, you don't need a stub for calling a Web service: You just start calling its methods. Because the language is dynamic, it automatically builds the necessary Web service calls, sends messages to the Web service, and gives you the results. 

There are also parts of the missing pieces in our current offering that people may not be asking about yet, because they don't have those tools at all. I'm speaking of profiling tools. This part of the tools ecosystem is going to grow. If you have a Web application written in any language, you need tools to investigate its performance. With Java and .NET, there are many solutions for solving that problem. For Ruby, there are some tools, but they are not established, and don't provide the kind of features their Java and .NET counterparts do.

On Flex support in IntelliJ:

For Flex support, we are focusing on our traditional strengths, mainly code editing. ActionScript is quite a complicated language. Because it has typing information, however, we can do a lot of things based on those types, such as smart code completion, all sorts of code navigation, code analysis, and refactoring, of course.

That is also the area we feel [Adobe's] FlexBuilder falls short: It has only very basic refactoring support, and a not very sophisticated code completion support. That's the area we're focusing at now.

We also will be putting our debugger infrastructure to full use for Flex, too. And we're planning to also have good integration with the Flex compiler. We don't yet have that in place, though: If you're using IntelliJ to develop Flex applications now, you have to use an Ant task to build the Flex application. We will soon integrate with the compiler to alleviate that burden. The open-sourcing the Flex framework has considerably helped in that regard.

We are not going to build a visual designer for Flex, however, at least in the coming year. Supporting that would require a lot of infrastructure for the entire stack of Flex and Flash technology, and building that would not be a good use of our resources. There are many developers who don't like visual designers anyway, and for them IntelliJ IDEA is a good solution. Some developers already use the two IDEs in parallel: IntelliJ provides better code editing features, whereas FlexBuilder provides a visual designer.

On supporting Scala in IntelliJ:

There's a bit of a problem supporting Scala in IDEs in general. Scala is a very complex language. It has been designed in academic circles, and by people doing research in programming languages. Many people seem to think that Scala is the next big language to replace Java, but I personally don't think so.

Honestly, I don't know any language today that would become the next big thing. Groovy is interesting, but it's a dynamic language and has all the problems of dynamic languages. It's OK for small pieces of code. But building something the size of IntelliJ IDEA [in a dynamic language] would be a complete nightmare.

A dynamic language works great when you have a clearly-defined structure of an application, where you know where everything lives, where everything is, and what everything is around you. For example, with a Rails application, you have a very strict structure: You have controllers and views and models, and so on. It's all very uniform. You can easily jump into any place of the application and understand what's around you: Here comes the model, and here's the data from the Web request, and so on. That's easy to figure out.

With a product like IntelliJ, there is no such uniform structure. It's very big and very diverse. In my day job, I have to make changes in many places of the code. Static types are the only thing that lets me jump into any place in the code base and understand what everything is around me. I need to know what things are, what I can do with various things around the code that I need to change. With static types, I see that immediately. With a dynamically-typed language, I would need to spend half an hour investigating what goes where and what is what before being able to make a single change.

A statically-typed language is very much needed, but I can't tell what other language will fill the space Java currently occupies. Many people may not like Java for many reasons, and some of those people feel that Scala is going to replace Java in the niche of a statically-typed language.

I don't believe that, however: Scala is very complicated, it's tricky, and has a lot of surprises and edge-cases. I would say that Scala is at least as complicated as C++, and with C++ you need a hundred-page style guide before you even start writing C++ code, otherwise you'll end up writing C++ code that nobody will understanding.

With Scala, there are different aspects of that complexity, but the language is still very complicated. Also, Scala doesn't have a specification in the sense that Java has. With Scala, you need to study how the language actually works, and it's a lot harder to have a fixed set of test cases you can use to test your IDE integration with. As well, the language keeps changing, which is also a problem for the IDE developers, because they need to track the evolution of the language.

That said, Scala support is probably the most asked-for thing from us at the moment. But I don't think people ask for it because they use Scala today. People ask us to support Scala because they think that that is what they're going to use in the future, and expect that they'll need it. Whether they'll actually be able to use that feature [Scala support], I'm not sure about.

What do you think about the directions for IntelliJ 8, and about Jemerov's comments concerning Scala?

Resources

IntelliJ IDEA:
http://www.intellij.com

Dmitry Jemerov's blog:
http://blogs.jetbrains.com/yole/

Talk back!

Have an opinion? Readers have already posted 27 comments about this article. Why not add yours?

About the author

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.