Align the Scala Development Tools with the Bleeding Edge of Eclip

Align the Scala Development Tools with the Bleeding Edge of Eclipse

Too long time for me to blog anything here. In this long time, I’ve received three important offers(one small company, one big big company and one institute). Although I have not decided which to go finally, this these days are and will be impressive in my life:)

Recently, I’m beginning to prepare the defense of my Phd thesis. I accidentally found I received one email to ask whether I'd like to continue one of my 2009 GSOC[1] proposals in this year. After some browsing, I find that I am really eligible to participate in the 2010's program[2]. So, I decide to prepare this year’s GSOC for the real last time.

As an Eclipse guy, that you know, I will stick around the community. This year I raise my hands over the topic of language support using Eclipse technology, which is my best point of interest in recent years. In this year’s program, I will submit Scala Eclipse-sided enhancement proposals to promote both communities deeply into each other:)

One BIG picture! Scala is really one nice and natural language choice for one Java programmer, after I have learned some other dynamic languages like JRuby/Javascript/Lua. All the languages have their values in the appropriate places. So, in the this blogging, I don't like to fire the language WAR. I just record things about Scala and mainly SDT (Scala Development Tools, formally called Scala IDE for Eclipse[3]). This blogging could be considered as the starting point of my adventure.

Scala have three mainstream IDE supports currently. Without doubt, the enirovement of them are Eclipse, Netbeans and IntelliJ IDEA respectly. Some of Scala developers will use some of them. Among them, the SDT(I use SDT as the synonym to the "Scala IDE for Eclipse", it is my favorite name) seemly has the best integration with Java development tools(yeah, that is, JDT). I will not fire another IDE WAR...But, I predict that, the future belongs to Eclipse:)

Thanks to Miles Sabin, the SDT have one good body and have provided many nice basic functionalities, such as the wizards, highlighting, hyperlink navigation, builder, and recent code completion [4]. However, many advanced features still have not been included in the current SDT. One much inconvenient thing for me is that, the latest SDT only works with Eclipse Galileo(R3.5). The milestone of Eclipse release train has been already relatively stable for coding. Nobody will wait one year to taste the latest cool Eclipse functionalities by milestones:)

I spent about three non-fulltime days to review the SDT codes(and knowledges about the Scala and AspectJ). Finally I make the SDT avaiable under the 3.6M6[5], the latest milestone of Eclipse Helios. Cool!:) All of the basic functionalities work finely. Yeah, now the latest Scala 2.8, latest SDT(SVN) and the latest Eclipse 3.6 are in the same box now.

Some thoughts about the SDT as follows:

1. The current architecture of SDT is much nice.

This makes JDT infrastructure reusable and makes JDT integration natural. AOP/AspectJ is another cool technology. AOP/AspectJ was one of hottest topic in some days. After many new technlogies(like DI?) or frameworks appear, the people go to forgot this technology. The SDT demonstrate the power of AOP/AspectJ.

2. many codes highly depend on the Java reflection and Class.forName.

This is a little against to the OSGI best practice. And this cause one HyperlinkDetector bug when my porting. I suggest every man in the community read BJ Hargrave's "Why Class.forName sucks!" at EclipseCon 2008[6]. There are many reasons and ways to refute using the Class.forName. I rewrite the HyperlinkDetector related part in codes, and remove Class.forName statement. No problem here. (I will describe some details in my proposal.)

3. some aspects codes can be updated for new Equinox Apsects runtime.

I rewrite the aop.xml to mf.

4. the Java<->Scala collection interoperability is a little problem for newcomer.

I met some Map type checking problems when I overrided one class from one existed Java framework(Eclipse indeed). Scala has the concept of "Existential Types". I think I need more deeply lookups in this field to see what is the best practice. This is a language level problem indeed, not related to SDT. But this gives the Eclipse tooling more space to be improved as well:)

5. The build process of SDT can be simplified into small and easy pieces.

My original thought is that, bootstrapping the SDT form plain Eclipse enirvonment.That is, I can not use the SDT to build SDT at the very beginning. Miles has written one great document to show how to build the SDT[7]. But, frankly, I have not the courage to read through the document. This will be more serious for the Eclipse newcomers.

As my testing, the Eclipse PDE build tooling workflow fits the SDT as well in fact. (need a little trick:)) After some targeting and layouting, I even can run and debug the plugins in the workspace directly without any packaging, deploying or the prerequisite SDT installing step. This aslo makes SDT development's life easier.

6. naming of the version of scala-plugin-aspects is a little not consistent.

The version of bundle in the svn is 1.0.0. But the name of the scala-plugin-aspects jar is like "ch.epfl.lamp.sdt.aspects_2.8.0.r21304-b20100331125642.jar". It is the product of the ant build scripts. It is not an error strictly. However, I think it is not the best practice in Eclipse world. Just a note here:)

7. SDT in svn seem not much stable.

I meet several wired bugs, however they can not be repeatened...

Oh, here, I add one pciture to show the code completion is ready-for-use now:)

At the end of this blogging, some immediate suggestions for the current SDT, IMHO

1. re-arrange the build flow

Beside the above mentioned, SDT building artifacts can depend on the binary snapshots of latest Scala and Eclipse instance. Re-build sources of Scala is time-cost and not convenient/necessary in common cases.

2. "Release early, Release often"

align the head of SDT with the latest Eclipse and latest Scala(latest Scala is said to be used for SDT development, not SDT user)

The SDT is a tooling under the umbrella of Eclipse, so keeping its release rhythm synchronous with Eclipse(JDT) will a killing reason for the acceptance of SDT.

3. add the dist of standalone SDT installment package for downloading

The SDT needs some bootstrapping hackings in the configuration of Eclipse instance. Although it is easy for old men, it is not cheap for newcomer. I guess many people would not configure the SDT correctly. This would highly block the acceptance of the SDT and, of course, Scala itself.

I will contact Miles/scala-plugin team to see whether he/they like to accept my codes or some of it. Of course, it can be hoped that Scala will have one more bright future with the help of Eclipse:)

I have one little idea about the Scala language for e4, although I am afraid whether this will be supported by our voters. But I think I will start/push this idea some day. It will not be long...

I am planning to write more things about Scala and SDT recently. I wonder if there are some collaboration efforts about these in the community. If you are, let me know!:)

[1] http://socghop.appspot.com/

[2] http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#graduate

[3] http://www.scala-lang.org/node/94

[4] http://old.nabble.com/IntelliJ-and-Eclipse-Plugins---Scala-2.8.0.Beta1-td28035792.html

[5] http://download.eclipse.org/eclipse/downloads/drops/S-3.6M6-201003121448/index.php

[6] http://www.eclipsecon.org/2008/?page=sub/&id=377

[7] http://lampsvn.epfl.ch/trac/scala/wiki/EclipsePlugin#CreatingAndSubmittingPatches