DZone Interviews: Peter Gromov on IntelliJ's Groovy support

DZone 's Guide to

DZone Interviews: Peter Gromov on IntelliJ's Groovy support

· Java Zone ·
Free Resource

Peter GromovHello and welcome to another DZone interview. Without a doubt IntelliJ IDEA is the IDE of choice of many Groovy developers out there, simply because it was the first IDE to raise the bar in terms of support for the language -- and continues to do so. Peter Gromov is currently in charge of all things Groovy on IntelliJ, let's hear what he has to say about his experiences with the language. Enjoy!

Andres Almiray: Could you please introduce yourself

Peter Gromov: I’m a senior software developer at JetBrains. I work on IntelliJ IDEA project and I’m responsible for Groovy-related stuff there, and a number of other things.

Andres: Let's talk about IntelliJ's Groovy support. How did you get involved with the project?

Peter: The people who had been developing it before me had gradually left the company, and I took over the process. At first I had an impression that everything was already written, and my task would be mostly maintenance and little bugfixes. And this was what I did. But the users kept filing feature requests, more and more of them. Then at some moment I found that I actually didn’t have time for all the Groovy activity. So now I’m not alone, there are also Maxim Medvedev and Sergey Evdokimov working on Groovy and Grails integration.

I also have been using Groovy myself, first for my pet projects, then for IDEA development. Eating your dog food is always good. One of the reasons of IDEA’s success regarding Java is that the developers actually use it and try to make it as comfortable as possible. So now we do the same with Groovy. This really helps to improve the plugin. One of our goals now is to make working with Groovy as comfortable as with Java.

Andres: What was the most challenging part of integrating Groovy into IntelliJ?

Peter: Working with the real world outside of IDEA. This is the joint compiler, debugger, Grails plugins layout, etc. Inside IDEA, you basically have control over everything, you are allowed to do anything to get the job done. That’s great but not challenging. But when you have to interact with another process, things get complicated. You are much more bound now, you have to think much more how to achieve the goal you have. And this is exciting!

Another problem I enjoyed solving was that of GDSL performance. In IDEA, you can write Groovy scripts in a special DSL which will contribute to IDEA’s own highlighting and completion processes. So you can teach IDEA some knowledge about your project and it’ll help you coding. The DSL looks very nice, but executing it on every change for every reference you have in the code is veeeery slow. So you have to invent some smart caching strategies. Now many Groovy properties and methods that IDEA knows about are defined via this DSL. And I’m proud that the Groovy code from those scripts gets executed only once per IDEA session.

Andres: It is really a pleasure to work with Grails and IntelliJ. What can we expect in future releases?

Peter: We’ll release IDEA 10.5 very soon. It introduces some new refactorings for Groovy code. Of course, it provides support for the just released Groovy 1.8. In Grails, we have much more code completion and navigation than in previous releases. This includes almost every reference you can imagine in controllers, GSPs, domain classes, constraints, criteria, mappings. We support even the names coming from plugins. IDEA knows about method’s named parameters, references in string literals, your custom tag attributes. And if you rename the thing a reference points to — it’ll be changed as well.

In IDEA 11, IDEA will be able to convert Groovy code into Java automatically. That’s quite useful when you discover a performance bottleneck in your Groovy code. There’ll be a cool new Grails console, with completion for Grails commands. IDEA will show some understanding for Grails configuration files and the properties one can define there. And many more little things.

By the way, any suggestions are welcome in our issue tracker. And those who post many bugs get a free license. :)

Andres: I guess IDEA 11 can’t come soon enough, where’s a time machine when you need it? What’s the feature you like the most regarding Grails and IDEA?

Peter: *Scratches head* Perhaps the navigation buttons at the top of Grails files. But that’s a tough question, really. When you spend a lot of time coding in IDEA you start just using it without noticing how cool it actually is. This leads to me being surprised when people are fascinated by things I use every day, e.g. that completion works, that rename renames every reference, highlighting, quick fixes, live templates. So I guess what I really like most is how everything just works. Well, sometimes it doesn’t (and then I file a bug and sometimes even fix it right away) but most of the time you get what you want with the most intuitive actions. Consistency. What works in one place, in one language, will work in another language. That’s great.

Andres: It’s been a while since a good portion of IntelliJ became open source. How can developer help and submit a patch to the Groovy code for example?

Peter: Just file a YouTrack request with patch attached. Or email me (peter@jetbrains.com). I also can help with understanding the code.

Andres: Do you work in other areas besides Groovy/Grails/Griffon support for IntelliJ?

Peter: Certainly. I work on the general code completion API and Java completion. I’ve also created language plugins for FreeMarker and Spring AOP, as well as the underlying machinery of our XML- and annotation-based framework supports (like Spring, JSF, Web, Hibernate etc). Now I’m also maintaining Velocity integration. And doing some minor things in the core. I guess that’s it.

Andres: How do you keep in touch with Groovy news and community?

Peter: There are different sources. There is Twitter and other kinds of feeds of Groovy people. I’m also reading developer’s mailing list to get notified of the upcoming changes. In addition, there’s always personal communication.

Andres: What's on your reading table right now?

Peter: My hobby is computational linguistics, so now I’m reading a compilation of scientific articles on how people comprehend and generate speech in languages like Japanese or German. The only reason I mention this is that “computational” means writing programs, and I do it in... guess which language? Correct :)

Andres: Intriguing. I presume this is one of your pet projects. Any chance you can tell us more about this?

Peter: I’m playing with natural language parsing trying to understand how one can write a program that could parse texts as precisely as people do. Something in the tradition of the early work on artificial intelligence. Computers are generally bad at that, even Google knows very little about the syntactic structure of the texts it indexes or translates. So it’s a challenge, and I accept it :)

I’ve been parsing natural language for several years already and in many different programming languages. And I must say that my relationship with Groovy in this field is the longest so far, more than one year. Though I wish it had more functional programming features, it’s the most convenient for me so far. Thanks for it!

Andres: Besides more functional programming capabilities, what else do you think would be good to have in the language in a future release?

Peter: Besides functional programming you say? It’s hard to think of anything besides that. Perhaps lightweight Python-like generators which yield a value and then freeze their state until asked for the next element. But anyway, pattern matching and simple immutable structures manipulation (e.g. cloning an object with some properties changed) are much more important for me. And yes, bundling Groovy++ could also be a good idea.

Thank you Peter!

Peter can be reached at @donnerpeter though he barely tweets these days.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}