Warning! if you have no experience building plug-ins, this post will probably mean very little to you.

A few days ago, I was working with Anton, one of my Google Summer of Code students, trying to figure out how one might implement Eclipse plug-ins using scripts. More specifically, we were trying to sort out how rather than specifying an implementation class, you could specify a JRuby or Groovy script. We started with the obvious: generate a Java class that locates and executes the contents of the script. Fortunately, we both agreed that while generating code makes sense in some circumstances, it would be yucky and clumsy in this case.

Then we had the idea that it’d be cool if, when you specify an implementation class in an extension, you could somehow parameterize it. A quick review of ConfigurationElement#createExecutableExtension() revealed that you can indeed do just that. When you specify a class that implements IExecutableExtension, you can also tack on a colon followed by a value. Just after the instance of the class is created, it will be handed the value via the setInitializationData() method. Very cool, this allowed us to create facades for each of the types required by the extension-points. These facades use the parameter to find the actual script to execute.

So now, we can create extensions like this:

<extension point="org.eclipse.ui.views">
      <view
            class="org.eclipse.soc.yummy.facade.views.ScriptView:view.groovy"
            id="org.eclipse.soc.yummy.views.ScriptView"
            name="Script View">
      </view>
</extension>

With this, the ScriptView facade (which need only be implemented once) uses the script named “view.groovy” to provide actual behavior.

But Anton wasn’t satisfied with that. Providing a facade for each type required by every extension point is just not possible. So we set about trying to make it more dynamic. We explored the idea of using java.lang.reflect.Proxy to dynamically create facades. This is a great idea, except that you need to know the names of the interfaces you want the proxy to implement. No problem, you can just add that to the value tacked on behind class name.

The real problem is that the class you specify has to be a real class that createExecutableExtension() can instantiate. It occurred to us that the solution of the problem was to somehow recognise that the class specified is actually a factory and then use the factory to create the proxy stand-in. So we set about figuring out how we were going to change the platform code to make this work. The prospect of changing platform code to make this work was exciting. Unfortunately, after about five minutes, our excitement was dashed: we discovered that it’s already implemented (those darned platform developers keep stealing my good ideas before I even have them).

So, we can now implement plug-ins using scripts with extensions defined along the lines of:

<extension point="org.eclipse.ui.views">
      <view
            class="org.eclipse.soc.yummy.core.ScriptExtensionProxy:org.eclipse.ui.IViewPart/view.groovy"
            id="org.eclipse.soc.yummy.views.DemoView"
            name="Demo View">
      </view>
</extension>

Where ScriptExtensionProxy implements both IExecutableExtension and IExecutableExtensionFactory. When this extension is created (via the createExecutableExtension() method) it creates an instance of ScriptExtensionProxy, sets the initialization data (”org.eclipse.ui.IViewPart/view.groovy”) and calls the create() method which builds an instance of Proxy that acts as an implementor of IViewPart, using the code in the script file “view.groovy” to implement a view.

How cool is that?

Mark Dexter has made a series of videos to help you get started with Java development using Eclipse.

He’s posted the first video on YouTube. A better quality version of this first lesson, along with another 15 lessons and a companion document have been released on SourceForge.

Something that a lot of people don’t understand about Eclipse Java development tools (JDT) is that the “build” path and the “runtime” classpath are actually two different things. The “build” path, oddly enough, is used by the Java compiler when building a project. If you’re building a plain-old Java project, then this is pretty much the only path that you need to care about, since—in the absence of an explicitly-provided classpath in a run configuration—Eclipse will use the build path at runtime. This works out great when you’re developing a Java application and want to test it: it just works.

However, when you attempt to deploy that application outside of the warm and comfortable environment that is Eclipse, you have to set up the runtime classpath yourself. There are few ways to do this; you can set up an environment variable, just add a bunch of JAR files to the command line that starts your Java application, or make a shell script that configures everything just so. In short, the runtime classpath is different from the build path and the separation of the two of them can be pretty painful (especially when you leave the aforementioned warm and comfortable environment that is Eclipse).

When you build a plug-in/bundle for Eclipse, the world is a little different. The “build” path is still used for building the Java code and is absolutely necessary. However the build path is completely ignored by the Equinox/OSGi runtime environment. In the runtime environment, the bundle manifest (manifest.mf) is king and your plug-in/bundle’s runtime classpath is defined by the entries contained in that file. The Plug-in Development Environment (PDE) does a wonderful job of letting you define your dependencies in one place: it automatically configures the build path for you (using a wonderful dynamic library) based on the dependencies you specify in the bundle manifest. When you’re building plug-ins, you never have to look at the build path. This can make things a little (or a lot) confusing. If you add something to the build path of a plug-in project, the JDT will happily compile the code and will not report any errors (at least not related to the library you’ve added). However, at runtime, the build path is ignored and you’re bound to get a bunch of ClassNotFoundExceptions. Bummer.

Web projects have a similar issue. A web project needs various libraries in order to compile. These required libraries are need to be on the build path so that the JDT can find them. This includes libraries (like j2ee.jar for example) that are provided by the application server. I need these libraries at build time so that JDT can actually compile my code, but I don’t need to provide them separately at runtime since the application server will make them available.

Specifying dependencies between projects that are to be deployed on an application server is subject to the classloading strategy provided by the server. In Java EE, there’s no notion of projects; there is instead a notion of modules. Eclipse represents each Java EE module as a project. That is, a web module, which are represented as a WAR file on the application server, is represented by a Dynamic Web Project in the Eclipse workspace. So-called “utility” libraries, represented as JAR files on the application server, are represented as Java projects in Eclipse. I vaguely recall that there this thing called Enterprise JavaBeans, but we’ll save those for a later discussion. The final piece is the Enterprise Application. An Enterprise Application contains these modules, so that in the ideal world, an entire Java EE application containing multiple modules is contained in a single EAR file (You think that your hygiene is bad… I have a WAR in my EAR!).

Visibility between modules is accomplished through the manifests in a manner very similar to plug-ins. A module’s manifest declares all the other modules within the EAR that can be seen, and the runtime environment makes sure that everybody can see what they need to see. If this visibility between modules is not explicitly specified, then you’re going to get a bunch of ClassNotFoundExceptions at runtime (even if you’ve got your build path all configured so that everything compiles). Again, just like with plug-in projects, the Java build path is ignored at runtime. The Java build path is something that’s required a build time.

Update! I had previously mistyped the name of the Web Tools Platform.

Fortunately, the Web Tools Platform (WTP) takes care of this for you. As you are building your Java EE modules, you must specify your runtime dependencies between modules using the “J2EE Modules” tab on the “J2EE Module Dependencies” properties page (you can also add utility JARs to a web project’s lib directory using the “Web Libraries” tab). Just like the PDE, WTP automatically configures the build path so that everything you need to see at runtime is also available at build time If you’re building a web application, you should never have to look at the Java Build Path for your project (WTP also puts the libraries contributed by your application server onto the build path for you).

This extends to Java projects as well. If you have dependencies between multiple “utility” JARs, you need to manage those dependencies using the “J2EE Module Dependencies” property page to make sure that the right visibility is available at runtime. If your utility JAR needs to access libraries provided by the application server, you can set the “Targeted Runtimes” to include your server and, again, the build path will be automatically configured for you. For utility projects, this may seem a little weird, but if you’re accessing code in other modules and in application server libraries, you need this information for your application to work at runtime.

The short version of all this, is that you really only ever need to mess around with the Java Build path if you’re building Java applications.

The second annual Eclipse Summit Europe (ESE) takes place October 9-11, 2007 at Forum am Schlosspark in Ludwigsburg, which is in the Stuttgart region of Germany. ESE is the Eclipse Foundation’s premier event designed to create opportunities for the European Eclipse community to explore, share, and collaborate on the latest ideas and information about Eclipse and its members. You can register now! The early bird pricing deadline is September 6, 2007.

The conference will consist of one day of symposia followed by two days of technical and business track sessions, selected keynotes, demos, and networking gatherings. Sponsors supporting ESE will showcase their latest products and services, as well as the exciting contributions their organizations are making to the Eclipse ecosystem. The conference is a stimulating and dynamic event for Eclipse committers, contributors, adopters, add-in providers, and service providers to learn, share expertise, and discover new opportunities and solutions in the Eclipse ecosystem.

For more information on ESE, go here.

The PHP Development Tools (PDT) Project has been hard at work producing the next version of some excellent tools for building PHP applications. I have been using the 1.0M1 release (the PDT downloads page points to their update site) for a few weeks now and am really impressed. Here’s a screenshot of my workspace in action:

The editor (top center) does the syntax highlighting and code-completion that I’ve come to love (the screenshot shows the code completion in action. The PHP Project Outline view (lower left) shows all the constants, classes, and functions defined in the currently selected project (or the project containing the current selection). The PHP Functions view shows the available built-in PHP functions available; you can right-click on a function and select “Open Manual” to show the documentation for that function (bottom center).

You can launch the file you’re editing directly from the editor, or can select a file and launch it from the Navigator or PHP Explorer view.

The next release, 1.0M2 is expected on July 30th. This is a great date, as it will give you something to be excited about after the excitement of the new Harry Potter book starts to ebb.

Update! I incorrectly indicated the version number as 2.0M1/2.0M2. It is, of course, 1.0M1/1.0M2.

It’s long past time to continue on a path I started down some time ago. About four years ago, Renaud Waldura posted a blog entry titled “Ten Reasons to Use Eclipse”. A few months back, I started reviewing the ten reasons to see what’s changed. My previous entries are here:

1. Ten Reasons to Use Eclipse
2. Eclipse is a platform
3. Eclipse Has Momentum
4. Eclipse is Easy To Extend
5. The Eclipse Workbench: Views, Editors and Perspectives
6. Eclipse is Faster
7. Never Compile Again

Reason #8 is titled “Interpeted Java”:

Eclipse is revolutionizing Java development by bridging the gap between traditional static languages (think C++) and dynamic OO environments (think Smalltalk). Java developers are used to the repetitive compile/debug/test cycle typical of static languages. Eclipse uses a combination of advanced techniques to emulate a dynamic programming environment normally associated with interpreted languages. This amazing feat gives Java developers the benefits of both worlds: a compiler still performs static analysis, and the repetitive compile/debug cycle yields to a smooth write/test activity.

Let’s look at a spectacular example. As mentioned above, Eclipse builds fully incrementally: it will even let you run code containing syntax errors. Calling a method with compilation errors in it breaks into the debugger, where I can fix the error and resume the execution as if nothing had happened. Behind the scenes Eclipse compiled the new class and dynamically replaced it in the running VM. My Java program can be changed, and in fact, almost be developed, while running! This amazing feature is known as hot code replace, and requires the latest JDK to work best. Eclipse Fill-in Templates

Ctrl-Space in Java editor popped a fill-in template

Because all code is always compiled, Eclipse has detailled knowledge of the methods and classes making up an application. In addition, the Java editor also constantly parses code as you type it. This unprecedented depth of knowledge about the code blossoms in a bouquet of sophisticated features inaccessible to a purely text-based editor. It makes the environment incredibly smart and able to provide contextual help at a level I had never experienced before.

To wit, the Java editor offers completion on class names, method names, and even argument names. It detects typos as they are made, underlines the offending statements, and offers corrections, e.g. creating a previously undefined method or class. It auto-imports classes when needed, and can flag useless import statements. Fill-in code templates are tailored to the current context, and save on typing efforts.

To summarize, the Eclipse environment leads code writers with an expert hand, and increases productivity by providing immediate feedback about the code.

The title threw me off a little at first. Eclipse relies on a Java Virtual Machine (JVM) to run Java Code. That is, Eclipse doesn’t run Java code in any form, interpreted or not. As Renaud discusses in his post, the Eclipse Java development tools (JDT) does indeed interpret Java code to make the editing experience better. By interpreting the Java code, JDT can provide great things like syntax highlighting and very intelligent code-assist. And it’s just gotten better. Code assist is way smarter than it was four years ago. It now features even more advanced features like null reference analysis and hyperlink debugging; these features are made possible because Eclipse can actually make sense of the code.

It’s natural that Renaud’s list is very focused on the JDT; four years ago, JDT was the schiznit (and in fact still sets the standard for language support). Eclipse continues to grow, supporting numerous languages. The C/C++ Development Tools (CDT) project released version 4.0 sporting huge advances in functionality as part of the Europa release. Europa also includes support for Ruby and TCL development thanks to the Dynamic Languages Toolkit (DLTK) project. DLTK also provides support for Python. Add PHP support to list (courtesy of the PHP Development Tools (PDT) project). The list of languages now supported by Eclipse is huge (and growing). The potential for Eclipse to support a virtually unlimited number of languages (with Mylyn integration) is realized with the DLTK project.

I’ve never gotten quite as comfortable developing with the debugger as Renaud suggests. The hot code replace features in Java are still nowhere near as flexible as Smalltalk, so I find that I tend to fix relatively little code in the debugger (though I still do it occasionally). The code completion functionality, templates, quick fix/assist, and hyperlink stepping features just seem to keep getting better and I’m well beyond the point of being able to live without them. What’s even better is that the same sort of functionality is being offered for other languages as well.

And incremental compilation just plain rocks. Plus the ability to run code that contains errors is very handy during development. I wonder why other folks haven’t tried to copy that?

Apparently, there is some confusion about the name of the “Mylyn” project. Let me try and clear it up.

This is “Our Lynn”, the Eclipse Foundation’s Marketing Events Manager.

This is “Mylyn”, the Task-Focused UI for Eclipse that reduces information overload and makes multi-tasking easy.

Any questions?

I spoke last Thursday at the Java Forum Stuttgart. This is a show that I really enjoy attending; the organization is great, the people are very nice, and Stuttgart is a nice city. I delivered two talks: one on Eclipse RCP and one on Mylyn. The RCP talk went well as usual. The room was filled to capacity (more than 100 people), there were several very good questions, and I believe that most people got what they were looking for. I don’t like admitting this, but there were at least a couple of people who I noticed close their eyes during the talk. That’s okay, I’ve been known to nod off myself once in a while.

Nothing of the sort happened in the Mylyn talk that followed (for those of you who haven’t heard, Mylyn is the new name for Mylar). I started the presentation with some slides liberated from Mik Kersten and Rob Elves’ EclipseCon 2007 talk. I changed the structure of the talk a little and added a few extra slides and bullets (and changed occurrences of “Mylar” with “Mylyn”). It’s a good talk, but I decided to change the flow and rather than do a bunch of demos woven through the presentation (like Mik and Rob do), I opted to do all the talking followed by all the demo’ing.

During the slide presentation, I felt like I was explaining a trick that I had seen a magician do the night before. Mylyn sounds fantastic, but I could sense cynicism in the crowd. How could it possibly be that good, I could sense people thinking. They were actually sitting on the edge of their seats. Nobody nodded off. Everybody was hanging on my every word. It was, in a word, awesome. Then I did the demo and watched the cynicism wash away from their faces. I could feel the wave of energy and excitement. I had a similar experience discussing Mylyn at the JUGC “Unshootout”. Mylyn changes the way that you write code. Mylyn is awesome.

So my new reason to love Mylyn is that as well as being incredibly useful, it demos well. Really well. Mylyn makes me feel like a rock star.

On a side note, among 120-ish or so German-speakers in the audience during my talk, not one of them seemed to know the German word for “collaboration”. Ralph seems to think that it’s because Germans don’t need a word for something that they just do naturally (along the same lines as why we call it “hockey” and not “ice hockey” like much of the rest of the world, I suppose).

I reported a little while ago about my experiences with Ubuntu. It’s time for a quick update.

The short version is that I like it. I like the way that it looks and feel. I even like the OpenOffice software, though it does bizarre things once in a while (need to make a few bug reports there). The performance on this Dell D820 is snappy, and it starts lightning fast (at least compared to the five minute startup of my previous Windows XP box).

That said, there have been problems…

I still haven’t been able to get the external monitor thing working right. At the recent JUGC (Java Users Group Cologne) event, I couldn’t get it to display right at all. At Java Forum Stuttgart earlier today, I did manage to get it to play well with the projector, but I had to restart and then fiddle with the resolution settings to make it work. At least it’s not a show stopper (rebooting doesn’t take all that long). I’ve heard that the next version of xorg should address this, so I’ll just wait.

I was having a problem getting suspend and hibernate to work, but they magically started working a couple of days ago. I switched to the restricted (i.e. non-open source) drivers for the display and that seemed to make everything right (or maybe it was another update, I really wasn’t paying close enough attention).

I tried to get bluetooth working today, and I ended up somehow screwing up the wireless networking. After removing the bluetooth stuff, everything started working again. I may spend some time next week trying to sort it out again since all the pictures I’ve taken this week are pretty useless to me without a bluetooth connection to my phone to download ‘em.

Speaking of the wireless, it just stopped working a couple of days ago. It took me a while to figure out that after I had connected to an ethernet cable the “roaming” setting on the ethernet adapter got turned off. After turning this back on, everything started working.

So… there’s been problems. But I’ve been working around them. All-in-all, as a former Windows user, I’m happy with the Ubuntu experience.

Eclipse Blogs does have an RSS feed. Unfortunately it’s hidden. I’ll try to resolve this next week by adding a fancy icons somewhere on the template (somehow, I managed to assume ownership of this sort of thing). In the meantime, tack “/feed” on the end of the URL for the blog and you’re good to go (you can get the RSS feed for my blog here).

With FireFox 2.0, there’s a menu option, “Bookmarks > Subscribe to this page…” which gets you to the same place.