Java is the new Cobol. But there has been a burst of language innovation on the JVM, for example Groovy, Scala, and Clojure. These languages can not become mainstream without a first-class IDE like Eclipse. Eclipse may not be that IDE.
This presentation about the Scala Eclipse plugin is alarming. These JVM languages tightly couple with Java, and so need to integrate with the Java IDE features. But the Eclipse project has been unwilling to support that. Scala and Groovy have had to resort to binary aspect weaving to monkey-patch Eclipse. Unfortunately it appears that is not sufficient, and the presentation concludes that forking the Eclipse JDT may be the only solution.
Fortunately IntelliJ seems to be doing a good job of supporting these new JVM languages. But it is sad to see that Eclipse, which started as a very progressive forward-looking initiative, is now a roadblock to progress.
I don’t find this presentation “alarming”.
The bar to move away from current paradigms is high. It is not simply the Eclipse project that is uninterested in supporting new paradigms. Academics in the peer review process are, too.
A big problem is that Sun is not involved in Eclipse, but involved in Fortress. Until these two projects collide, there’s no hope. More generally, you need one big IDE project and one big language project to collide. Best hope might be NetBeans and Eclipse, as I don’t see Ultra Large Scale Information Dominance Military projects providing much Fortress-with-Eclipse funding.
By the way, Andrew McVeigh, who contributes to Alloy 4 Eclipse project, proposed a top-down restructuring of Eclipse plug-in development. Best paper would be “Using resemblance to support component reuse and evolution”.
A slight correction to the presentation. The Groovy-Eclipse plugin does not use weaving, but rather uses a feature patch. This allows us more fine-grained control over integration with JDT. The weaving service used in the Scala-Eclipse plugin is borrowed from AJDT (AspectJ development tools), except that they use a slightly different set of aspects. Same basic idea, but different mechanisms.
My opinion is that the problem of Java tooling is basically solved by JDT, meaning that JDT is very well tuned for Java. This has been the case for the past few iterations of JDT. You will notice that very little has changed in JDT in the past few versions of Eclipse. So, IBM has removed almost all of its developers from working on JDT. I believe there are none working on it full time any more. My guess is that their job is to bug fix and to keep things stable.
Adding support for new languages is definitely destabilizing and so falls outside of their scope. I’ve looked closely at this issue and the problems are political/economic and not technical. It is not in IBM’s best interest to support Java-like languages on the JVM and so IBM (as the current gatekeepers of JDT) have no reason to make the changes.
Andrew, thanks for the corrections and clarifications. So do you think that the new JVM languages should band together and fork the JDT?
Funny you should mention that, because we just got together (via skype) earlier this week to chat about things. There’s nothing formal. We’re just trying to get a few of the basics down, eg- How do we make sure that all these language tools don’t step on each other’s toes (they already do)? What is better for which circumstance: feature patching or weaving? We have a fairly good idea of some minimal functionality to push into JDT that, but we haven’t thought about how to convince the JDT team to accept any potential changes.
If you are interested in learning more, you can join the google group:
http://groups.google.ca/group/jdt-hackers
Just wondering, I saw the presentation online via the slides Jonathan linked, and was not there in person. What’s wrong with DLTK? (Dynamic Languages Tool Kit)?
Also, how familiar are you with how other IDEs manage plug-ins and extensibility?
Sounds like all the thinking you need to do is remember this:
Just wondering, I saw the presentation online via the slides Jonathan linked, and was not there in person. What’s wrong with DLTK? (Dynamic Languages Tool Kit)?
There is nothing wrong with DLTK. It does a great job of providing support for languages that do not need to interact with the Java model. However, the DLTK does not allow your language to hook into the java builder, or allow your language to hook into Java search, etc.
Also, how familiar are you with how other IDEs manage plug-ins and extensibility?
Not too familiar. Are you aware of any other IDE that provides better extensibility?
I’m a .NET whimp now so I don’t know how Eclipse’s language extensions work currently. However, I know how they worked prior to the new versioning system for Eclipse bundles (that I believe Gamma worked on).
I believe Omnicore CodeGuide IDE (for Java) is based on its Xdevelop IDE. Xdevelop has an open API that groups things fairly logically. No silver bullet, of course 🙂 Apart from that, not really.
You may also want to get Andrew McVeigh interested in the group – check out his Backbone project – an architecture description language for evolving systems. http://code.google.com/p/backbone-adl/
Screw Eclipse. It has sucked for Java, let alone Scala and the others you mentioned, for a long time now. I agree that it would be nice to have a free IDE that was great, but Eclipse has already not been good for much for a while now. It’s way too slow anyway. Hopefully someone else will make a nice open source IDE for these things, but I guess we will have to stick with IntelliJ for now.
This was my baby before it was Miles’. The original strategy was to fool the JDT into thinking that Scala files were Java files, and to some degree I succeeded, but there were lots of wholes and demands for even tighter integration than I implemented. At the end of the day, I think there is a breaking point where we need explicit cooperation from the UI JDT team in Zurich, or the plugin will just wither on the vine. That never happened, which is funny, since Zurich is just a couple of hours from Lausanne…(a lot of the other JDT backend work is done close by in France).
My feeling is that Scala can and should stand on its own. If you don’t consider tight integration at the Java source level, the Scala plugin is already pretty complete. Its the unmet promise of tight integration that screws a lot of things up. Admittedly, lots of stability problems to, the Scala plugin really needed another year of work.