Interview: meet the Groovy Eclipse v2 team
Interview: meet the Groovy Eclipse v2 team
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
DZone caught up with the team responsible for the latest developments on the Groovy Eclipse plugin v2. Continue reading to know more about Andrew Eisenberg, Andy Clement and the Groovy Eclipse plugin v2. Enjoy!
Andres Almiray: Can you introduce yourselves?
Andrew Eisenberg: I've been working at SpringSource for just over a year now, primarily on the AJDT project, but in May, I picked up working on Groovy Eclipse tool support as well. Before that I was working on a PhD at the University of British Columbia. My dissertation was about how programs can be made more expressive through the right kind of integration with an IDE. And I've been lucky enough to be able to apply my PhD work to real life now that I've graduated.
Andy clement: I'm a Senior Software Engineer with SpringSource. Originally joining them in the UK, I've since relocated to Vancouver where we do the majority of our tools related work (Groovy, AspectJ and also, with Tasktop, the SpringSource Tool Suite). My real background is transaction middleware development but the for the last few years (previously at IBM, and now at SpringSource) I've been leading the AspectJ Eclipse project. I do tend to be a 'programmer for hire' around the SpringSource team though and this year have also created the Spring Expression Language support in Spring Framework 3 and contributed some code to SpringSource dm Server.
Andres: You just announced the alpha release of the Groovy Eclipse v2 plugin, the Groovy/Eclipse community has waited long for better integration of Groovy with Eclipse, what can they expect in this release?
Andrew: Our goal with this alpha release is the ability to support the basic edit-save-compile-run cycle in Groovy with all of the (IDE) dynamism that people have come to expect from their Java tooling. What I mean by this are things like the editor should show errors on the fly and that you don't need to have saved a class for its members to be available through content assist. That being said, this is just an alpha version and although it contains most of the major features that will be available in the final release, there is still a lot of twiddling, performance tuning, and testing to do.
Andy: Yes, exactly. The aim initially is to optimize the tasks the developer spends 99% of the time performing. I would say we've learned a lot from AspectJ and the tools support surrounding it. It doesn't matter how clever your language is, if features like incremental compilation (in particular), code assist and navigation aren't there in the IDE, it really hurts adoption. This alpha release is also a proving ground for the brand new approach of integrating support for another language directly into Eclipse JDT.
Andres: How did you get into Eclipse plugin development?
Andrew: Early on in my PhD, I started playing around with the idea of extensible editors. In the same way that a language like groovy allows you to use metaprogramming to extend your language, I wondered if the same kind of metaprogramming could be used to extend your editor. Although, I was able to show an interesting proof of concept [link], I hit a wall when it came to a truly usable extensible editor. The reason for this has to do with the strengths and limitations of the JDT (the Java Development Tools,...). The JDT is a highly optimized and well-architected framework for building tools targeting the Java language. It was not designed to be extensible or to support other JVM languages.
After graduation, I was hired by SpringSource to address exactly this problem for AJDT (the AspectJ Development Tools). Progress in AJDT had hit a wall because of the difficulty in integrating the AspectJ model into JDT's Java model. The problem was JDT's lack of extensibility for new kinds of program elements (e.g., aspects). It turns out that we have been able to use AspectJ on eclipse itself to make JDT more extensible.
Soon after, I was asked to do a similar thing for Groovy-Eclipse support. I initially thought that the same approach could work (i.e., using AspectJ to make Eclipse more Groovy-compatible). But, it turns out (which comes as no surprise in retrospect) that every language is different and poses different tooling problems. Using AspectJ for groovy support was not a good solution due to the kinds of extensibility required on JDT. Luckily, I was working with Andy, who has a much deeper knowledge of the JDT compiler and saw that there might be a way to integrate the Groovy compiler with the Java compiler.
Andy: First, I'll say I don't consider myself a proper Eclipse UI plugin developer. I freak out if I see more than one thread :) I tend to work on low level components that just happen to be packaged as plugins. Whilst I was at IBM finishing up on optimizing Java support for CICS mainframe (yes, really), I was looking for something new to work on. My office mate returned from a conference and had a bright idea for a new project (he often did this, his name was Adrian Colyer, now our SpringSource CTO). He'd discovered something called Aspect Oriented Programming and wanted to start the effort to create the eclipse tools for this new language. Along with Mik Kersten (now of Tasktop) we kicked off the AspectJ Development Tools effort - I think this was around the Eclipse 2 timeframe. As it progressed, I moved more into the compiler/weaver side of things, leaving more capable eclipse developers to work on the UI side. With Andrew now looking after the AJDT project, I am pretty much on the AspectJ compiler and weaver full time - and due to AspectJ being implemented as a modified Eclipse JDT compiler, I've gained a lot of experience with that codebase.
When I initially tried the groovy plugin, I was having trouble getting it to behave. I decided to step back and look at what it was trying to achieve. After discussing the structure with Jochen Theodorou it looked like a better approach to eclipse support could be taken. Something we spent a lot of time on in early AJDT was copying big chunks of Eclipse JDT code just to change a couple of lines, or writing a lot of code to create support for a feature in AJDT that was already in JDT. A couple of examples of that would be: incremental compilation, supporting multiple input/output folders and persisting project state between eclipse restarts. This time around, for Groovy, I really wanted to let Eclipse handle all that - and so far that has been achievable by just giving Eclipse a little understanding of what the groovy compiler is doing. Having incremental compilation support in the first ever alpha release of something like this is a big deal, and is made possible by the approach taken.
Andres: Any tips you can share on developing an Eclipse plugin?
Andrew: Eclipse is not easy to develop plugins for. There is a very steep learning curve, and a seemingly endless amount of API to learn. Despite that, it is possible to create very powerful and robust applications if you know how to use the platform properly.
One of the best ways to learn about the Eclipse platform is to read the source code itself. It is generally well written and well documented. The platform is its own best client and it can show you how its own API should be consumed.
Another suggestion is to not be afraid to use internal APIs. They are often the only way to gain access to certain undocumented services, but if you do use them be aware and accept that you may have to refactor your code for future versions.
Andy: What Andrew just said there. That is the reason I try and stick to lower level component development :) The endless APIs can be daunting as I found out as soon as we started AJDT all those years ago. I would also agree that the best way to learn is to look at some eclipse code that is already doing something similar to what you are trying to achieve.
I would also say it is worth taking the time up front to code your test framework. It can be tricky to get a reliable test framework behaving in a plugin environment, but it will pay you back so many times over during its lifetime.
Andres: How did you get started with Groovy?
Andrew: I come from more of an Eclipse background, than a Groovy background. I've known about the language for several years now, but haven't had a chance to use it for anything real until I started working on the Eclipse plugin itself. It's really a wonderful language to program in. On the one hand, Groovy code often looks like Java code but there really is a profound difference between the two. And this is what makes the language so great. Beginners can appreciate Groovy as little more than a less verbose Java, and you can gradually move into seeing all the real advantages that it gives you including scripts, AST transformations, and closures.
Andy: Originally I was supposed to do some work with Graeme (Rocher) on Grails, in order to pick up groovy. However as soon as I started trying to work on Grails in eclipse, I found I wasn't having the same experience as I do when working with Java. I'm too accustomed to an IDE experience now, and with my background I thought "I can do something about this". Once the IDE works, I'll probably get back to Grails!
Andres: What has been the most challenging task so far in making the Groovy Eclipse v2 plugin?
Andrew: Rebasing the UI component of the plugin onto the new compiler has been a daunting task. The original plugin used a kind of replica of the Java model to represent Groovy code. I had to rip out that part of the code and use a real Java model instead. So far, this has given us quite a few benefits. For one, it is now possible to do Java search on for Groovy program elements. Also, this new plugin likely has fewer lines of code than the original because I was able to remove so much of the original code that was no longer relevant. This is likely to change as we start to implement new features.
However, probably the thing that I have spent the most time on is creating the headless build scripts that generate the update site. This was an extremely tedious task that required bootstrapping the new compiler so that it can be used to build itself. Even now, I am spending way too much time tweaking the build scripts so that it produces just the right artifacts.
So, here's one more suggestion about plugin building for Eclipse: get someone else to write the build scripts.
Andy: I've only really had one task so far, and that was quite challenging. Integrating together two entirely different compiler codebases whilst ensuring incremental compilation continues to work and that we don't damage how the JDT compiler builds plain Java. It was one of those tasks where you have to do an awful lot of programming before anything starts working. However, I actually did all the work twice.
The first time as a prototype to check the feasibility (which I blogged about a few times on other blog: http://andrewclement.blogspot.com/ ) - the prototype got as far as building Grails but there were so many hacks in it. So I then *completely* discarded that solution and started again, the rewrite was so much better (naturally). Luckily alongside the JDT compiler I could take the JDT test plugins and extend them with groovy support, so for the rewrite I used a TDD approach. This was in contrast to the prototype where there was no testing apart from what I did manually - I felt completely lost without automated tests to validate what I was developing and it is so great to have them now.
Andres: Can you tell us what is in the pipeline for the next release?
Andrew: I'm taking this to mean the final release of V2.
Currently, the major features are already implemented: incremental compilation, code browsing, content assist, and launch support. However, some of them, specifically code browsing and content assist are not complete, nor are they optimized.
In addition to these major features, we expect to implement some other editor niceties, like quick fixes, editor support for AST transformations, a more fully featured groovy console, and perhaps some grails support.
Andy: From a compiler point of view the next few months leading up to the final release of version 2 will mostly be spent polishing. All the pieces are basically in this alpha release because I wanted to make sure everything was going to be eventually feasible. So it already has basic support for AST transformations (with incremental compilation). With all the pieces in place the next steps are really improving performance and memory usage, and perhaps attempting to drive our custom changes to Eclipse JDT and groovyc back into the respective projects.
The one last bit of magic I need to work on is to support the ability to write Java code that invokes methods on a Groovy class that are added during an AST transformation. This is tricky as usually the transforms run quite late in the process, by which time the error about calling a non-existent method has already been discovered by the Eclipse compiler. An example of this is the @Singleton Groovy AST transform which adds a getInstance() method. I've prototyped it once and got it to work, but I wasn't at all happy with the solution so have turned that feature off for now - I hope to reactivate it with a correct implementation by the final release.
Andres: SpringSource and the No Fluff Just Stuff symposium series will be hosting a Spring/Groovy/Grails conference later in the year [SpringOne2GX, Oct 19-22], what can attendees expect to see there regarding Groovy & Eclipse?
Andrew: It's unlikely I will be attending the conference, but it will be well represented by all of the Groovy, Grails, and Spring luminaries. So, not only can attendees expect a complete introduction to the final release of the plugin, but they will also be able to see a full line up of excellent speakers on the entire Spring and Groovy ecosystem.
Andy: I have a session at SpringOne2GX where I'll hopefully be demoing the final release. My vision for that session is simply that I don't have to make any excuses for missing functionality and working with Groovy code appears as straightforward as working with Java code. I'm sure we'll have AST transforms, refactoring and debugging all in the mix for this session.
Andres: Any parting thoughts?
Andy: I do think a key feature of what we're building here is the ability to use multiple languages together and the user has a choice. If you want a nice strongly typed bit of code, use Java. If you need to do something more dynamic or with less boilerplate code (like XML manipulation for example), use Groovy. Even this alpha release allows them to work together seamlessly. Of course, there are the other JVM languages gaining prominence at the moment but I still think it is important for the user to able to choose the appropriate language to solve their problem. I mean at the end of the day it all runs on the same VM, why should there be any mismatch when trying to use these languages together at the source level?
Andrew: Yes, and Eclipse has set a high bar for development tools. There is an incredible amount of work to do to get groovy support anywhere near the level of support that already exists for Java. Although, I feel that this alpha release is a good first step, I wake up some mornings and shudder when I think of how much farther we have to go.
Opinions expressed by DZone contributors are their own.