Mirko Stocker

Plans for 2011

I originally wanted to write a review of 2010 here, but by now I definitely missed the deadline for year-end-retrospectives, so I’m going to make this about my plans for 2011.

I’ve spent a large portion of last year on the Scala Refactoring project, and I’m quite happy with the results: four editors/IDEs are using the library to do refactoring, plus others use parts of it to manipulate or generate Scala source code.

It’s clear that I cannot continue investing as much time into it as during my master thesis (except of course, if someone would be willing to sponsor me 😉 ). My plan for this year is to find at least half a day per week to continue writing new refactorings and improving the existing code. One idea I originally had with the refactoring library hasn’t played out yet: getting others to create new refactorings. It’s really not that hard! So give it a try if you have an idea for a refactoring you want to automate.

Besides working on the refactoring library, I also really want to get back to writing for InfoQ. Speaking of InfoQ, I’m looking forward to QCon London in March!

Now, enough with the blogging – there are some bugs in Organize Imports I need to fix 🙂 A happy new year to all of you!

Scala IDE at Eclipse Summit Europe 2010

It seems to be customary to announce his Eclipse Summit talk in blogs, so here’s mine:

My talk will of course be on the Scala IDE for Eclipse:

This talk introduces the Scala IDE for Eclipse, the obvious choice for all Eclipse users who want to write Scala code. We are going to both take a look at the features the IDE currently provides as well as a glance under the hood.

So if you’re at ESE and want to know more about the Scala IDE for Eclipse, visit me on Thursday, just before lunch.

Eclipse Helios Released: What It Doesn’t Have

Many good reviews already cover all the nice new features that are in Eclipse Helios, so I’m going to show you a three annoyances that have been bothering me for years and are still not fixed in Helios. And these aren’t things like the high memory consumption or the sluggish interface.

Multiple Desktops

A bug that I observe almost every time I start Eclipse is Bug Nr. 98540, Eclipse shells open on different desktops (created in 2005). The problem is:

I launch the Eclipse process on one desktop, and then switch to another. The splash shell opens on the second desktop, not the one from which it was launched.

If you’re not using multiple desktops, this might not sound like a huge problem, but I can tell you, it’s really annoying if Eclipse just follows you around and doesn’t stay on the desktop it belongs to. This is not restricted to starting the initial Eclipse instance but also happens when you’re developing plugins and launch a new workspace.

Global Preferences

There are certain preferences I want in all my Eclipse instances, for example the “Show Heap Status”, or the Font of the editor. So it would be really nice if there were something like global preferences that can be saved somewhere and are then used by all workspaces. It’s already possible to manually import and export preferences, so you can share preferences, but doing it manually is tedious.

Another interesting project going into a similar direction is Google’s Workspace Mechanic. A bug report also exists since 2005.

Unnecessary Scrollbars Shown

The following screenshot should make the problem obvious:

Why are there scrollbars shown? I don’t use any other GTK programs, so this might be a GTK problem; but it still annoys me from time to time. And there’s a bug report for it since 2002.

Despite all these problems, I’m still a very happy Eclipse user and developer, so congratulations for this otherwise great release!

Scala Refactoring Thesis Finished

I’m done! A few minutes ago, I handed in my thesis on Scala Refactoring.

The project also has a new home at scala-refactoring.org, where you can find more about the refactorings I implemented, how they can be used, etc. I also recommend reading my report, but if you just want an overview, take a look at the poster:

The next steps for me now are to go on holidays, so please excuse if I don’t respond for a week.

Building Eclipse Plug-ins Written in Scala with Maven/Tycho

The Scala Refactoring project currently uses a rather crude hand-written ant build file; it compiles and runs tests. What it doesn’t do is creating a proper OSGi bundle, which I need if I want to do proper releases and integrate it into the Scala Eclipse IDE. Most of my colleagues are using PDE build, but from what I’ve heard, Buckminster or Maven/Tycho are the way to go.

Buchminster looks rather complex to me, so I went with Maven, even though I had no prior experience with it. Now, a few hours later, I have a Hello World plug-in written in Scala and a bunch of poms that build everything I want, even an update site!

Tycho needs Maven 3, which hasn’t been released yet, so I downloaded the latest alpha build and created an alias that pointed to the mvn binary.

I started with Mattias Holmqvist’s Blog where he explains how to create the initial Maven configuration and an OSGi bundle in Eclipse (I created a Hello World Plug-in Project). Now, we don’t want to have a Java plug-in but one written in Scala, so I added the Scala Nature to the project and re-wrote the two generated files in Scala.

To add Scala functionality to my pom, I followed the Eclipse Scala Maven Integration wiki. I also had to add the Scala Eclipse Plug-in nightly build update site to my list of repositories so Maven could resolve the scala.library dependency the project has.

    <repository>
       <id>scala eclipse nightly</id>
       <layout>p2</layout>
       <url>http://download.scala-ide.org/scala-eclipse-toolchain-osgi-2.9.1.final/</url>
    </repository>

Because I apparently didn’t follow Maven’s source layout, I had to explicitly specify the source directory via:

<sourceDirectory>${basedir}/src</sourceDirectory>

Adding the update site and feature projects was a peace of cake when following this tutorial (scroll to Creating an Update Site / P2 repository) from the Tycho project.

I’ve put the whole project on GitHub so you can try it yourself. And remember, this is my first day with Maven, so if I could make the poms even smaller or more idiomatic, please tell me. Or even better, just fork my code!

Next I’m going to find out how to run unit tests and how the integration in Hudson works, and then I can migrate the Scala Refactoring project and delete a build.xml file.

Update April 2012: I’ve updated the sample repository to the latest versions of Scala, Eclipse and Maven-Tycho.

Update July 2012: Updated the sample repository to the use Scala 2.9.2, Eclipse Juno and Tycho 0.15.0.

DIY Refactoring for Scala

Scala Refactoring Term Project Finished

Suspendisse elementum semper elit sit amet feugiat. Phasellus dictum metus et eros porta fermentum. Nunc vel elit at quam molestie euismod et sit amet sem. Phasellus id iaculis tellus, sit amet aliquet ex. Vestibulum ipsum magna, convallis nec ornare sit amet, tincidunt quis elit. Aliquam efficitur, est a gravida viverra, ipsum mauris pharetra neque, sit amet ultrices dolor leo eu tortor. Praesent bibendum sem ut luctus euismod. Donec vitae lobortis sem. Etiam cursus aliquam sodales. Etiam risus dui, aliquet id convallis at, volutpat ut ex. Mauris vitae tortor fringilla, egestas turpis at, ornare ante. Mauris et quam elementum, posuere tellus a, ultrices dolor. Etiam aliquet dictum lobortis. Suspendisse sagittis, sapien quis eleifend scelerisque, velit nisl volutpat ante, ut molestie lacus massa et nulla.

Fusce efficitur velit ut dui euismod, vel ultrices metus consequat. Aenean vehicula ipsum magna, vehicula egestas nisl ultrices in. Aliquam id suscipit felis, nec suscipit turpis.
John Doe

Donec scelerisque vehicula tempus. Aenean ac scelerisque sem, ac tincidunt quam. Duis mattis ipsum non arcu luctus sagittis. Proin laoreet lectus mi. Nulla facilisi. Sed sit amet maximus mi. Sed iaculis id orci in congue. Mauris a interdum est, non condimentum libero. Curabitur ac aliquet nunc. Aenean eleifend dui ipsum. Pellentesque quam odio, ultricies ut nisi et, placerat tincidunt augue.

Phasellus viverra sapien non luctus venenatis. Nulla vestibulum metus orci, et mollis neque molestie ac. Praesent vitae imperdiet tortor, non finibus ante. Suspendisse potenti. Donec sagittis velit nisi, quis pretium felis elementum id. Etiam feugiat arcu at urna faucibus, nec sodales ligula dapibus. Nam ullamcorper augue ac semper luctus. Nunc vel enim at velit tristique molestie vel et tellus. Sed mauris tortor, dictum vitae odio sit amet, malesuada pharetra massa. Nullam justo lectus, blandit sit amet fermentum vitae, laoreet nec purus. Cras non magna nunc. Integer laoreet metus in tortor sagittis scelerisque. Proin sem mauris, blandit eget felis et, mattis auctor dui. Proin convallis congue nisi, sed rutrum eros viverra non.

Extract Method for Scala

I haven’t blogged in quite a while now. Actually, the last entry was to announce my term project on Scala Refactoring. My excuse is, I was hard at work! So without further ado:

class Demo1 {
  def demo1(i: Int): Int = {
    val a = i
    val b = a + i
    b
  }
}

Select the line with the assignment to b, murmur the incantation press some keys, et voilà:

class Demo1 {
  def newMethod(i: Int, a: Int): Int = {
    val b = a + i
    b
  }
  def demo1(i: Int): Int = {
    val a = i
    val b = newMethod(i, a)
    b
  }
}

It also works with multiple return values and when passing functions. Now, the code isn’t ready yet, and I have to concentrate on writing my report right now, so it might take a couple more weeks until I can ship something.

Scala Refactoring Term Project

If you’re a Java programmer and haven’t yet heard of Scala, take a look at this nice Scala Tutorial.

What follows is my project proposal for my master term project (12 ECTS, ~360 hours of work, the same as a bachelor thesis actually). The project starts next week and will keep my busy for the next 14 weeks.

If Scala wants to succeed Java, it needs strong IDE support, and this includes automated refactorings. Although studies show that refactoring tools are underused, they still serve as a strong selling point to convince programmers to use an IDE (or even a whole language) over a simple text editor. Several Scala IDEs are under development, but all of them lack extensive support for refactoring.

I’ve worked on various projects implementing (Ruby, C++) and supervising (JavaScript, Groovy) refactoring tools. Taking advantage of these experiences, I believe that a sound refactoring engine can be built for Scala in due time.

Objectives

Scala should get an IDE independent facility to perform refactorings. This API can then be used by all IDEs and other tools to refactor Scala code – fostering collaboration to get truly great refactoring capabilities instead of several half-baked implementations from competing IDEs (as the situation with other languages – e.g. Ruby – is today).

The basis to create a successful tool is the code manipulation strategy, i.e. how the source is modified, and most important, how the changed source is obtained (formatting, comments, white-space). In the past, we at the Institute for Software experimented with different strategies but have yet to come up with a silver bullet. Therefore, the first focus of this project will be to analyze existing ways and to come up with a suitable code representation for this project. Additionally, Scala’s functional aspects (especially pattern matching) should lend itself ideally to the manipulation of tree-like data-structures.

Finally, to make the implementation of refactorings easier, several granularities of abstractions will be needed. Basic building blocks to modify the source trees (e.g. ‘move x to y’, ‘rename x to y’, ‘create a new X at y’) can then be assembled to complete refactorings (“cursor position is x, rename all references to ‘y'”) and exposed together with – probably already existing – query-operations (‘what can be renamed’, ‘what is located at the current cursor position’) and feedback (warnings, errors) through the API. The result of such a refactoring operation will be a set of diffs the IDE can then apply and show to the user.

Vision

To my knowledge there exists no language that has IDE independent refactoring support, and the only people creating new refactorings are the developers of the IDE. If this project succeeds, Scala will have a simple API to manipulate its source code on which refactorings and other code manipulation tools (e.g. quick fixes, code generators) can be built by Scala programmers and not only IDE adepts.

Desired Results

An API to do refactoring together with an implementation and ideally two reference users in the form of automated tests and an Eclipse plug-in. Whether these goals are realistic will be determined during the project and adapted if necessary. A more detailed project plan will be developed in the first week of the project, as soon as the effort can be better estimated with regards to the available environment (e.g. the richness and suitability of the AST).

Now, what do you think? How important is automated refactoring support for you in choosing an IDE or a language?