On handle-based models and the recent Eclipse Handly proposal
by Vladimir Piskarev
This is going to be quite a special post to me for two reasons. First, I must admit that I’ve never blogged before, so this is my first blog entry ever. Second, it’s about the recent Eclipse Handly proposal that I’m entitled to be the sponsor for. I find the proposed initiative important enough to justify starting a personal blog for the first time in my life. Here’s why.
I’m old-enough to remember the good old days of Eclipse as (just) an IDE platform and a great Java IDE built on top of it. That was how it all started. Then, seemingly, the focus has been gradually changing: RCP, Modeling, Runtime, and now the Internet of Things and M2M draw a lot of attention. That’s all great, but it looks like, somehow, the initial IDE-platform mission was overshadowed by this diversity and has never been realized completely. Now, that’s just an opinion, but many people seem to have similar feelings. See, for example, a recent blog post by Doug Schaefer, the Eclipse CDT project lead. (Doug, and Marcel Bruch, the project lead of Eclipse Code Recommenders, have kindly agreed to become our mentors.)
But how could that IDE-platform mission be more fully realized? That’s not an easy question for sure, but I believe a possible answer may lay in creating a multi-language IDE infrastructure slightly above the level of abstraction offered by the Eclipse core and doing it piecemeal. Simply put, Eclipse needs to become a great multi-language IDE and that goal just cannot be achieved in one go.
And this is exactly where I see the proposed Eclipse Handly project fits in. It aims to become a first piece of the puzzle, addressing language-oriented handle-based models. “Language-oriented handle-based models? That’s mouthful. Isn’t it something that EMF does already?” No, it has nothing to do with Eclipse Modeling effort. But it has to do with the core of a multi-language IDE in a very real sense.
If you have ever looked into the design of Eclipse Java development tools (JDT), or for that matter, CDT or DLTK, you already know that at the tooling’s core lies a handle-based model for the programming language(s) in question: Java Model, CDT model, DLTK model, etc. To a large extent, it’s the handle-based model that makes possible seamless tool integration and unified user experience provided by the IDE.
Unlike the more common object-graph kind of models (such as EMF-based models), handle-based models employ a variation of the handle/body idiom, where clients have direct access only to immutable, equal-by-value ‘handles’ to model elements, while the corresponding element state is stored separately in the internal ‘body’. Such design has a number of properties that makes it an especially nice fit for a large-scale long-lived model of a programming language from the workspace root level down to structural elements inside a source file as required for IDE tools. Here are the main characteristics of a language-oriented handle-based model:
- ideally suited for presenting in structured viewers
- scalable due to virtualization made possible by a handle-based design
- eventually consistent — need not be consistent all the time
- can refer to non-existing elements — existence can be tested with exists()
- tolerant to inconsistencies in a source file (syntax errors, etc.)
If you have not come upon handle-based models before and are curious to know more about them, I can recommend the excellent book “Contributing to Eclipse” by Erich Gamma and Kent Beck, especially the pattern stories about the Java Model.
But the question remains: “what does Handly bring to the table?”. Initially, two things — a set of reusable building blocks and a uniform API for language-oriented handle-based models. Three things, actually. I forgot to mention out-of-the-box integration with the Xtext editor.
What does it mean in practical terms? A detailed system overview and an exemplary implementation will follow as part of the initial contribution, but in a nutshell, you should specialize (via inheritance) the system-provided interfaces and abstract classes for model elements specific to your language, override/implement a few methods and provide the necessary model plumbing (using supplied building blocks) such as the model’s cache and the delta processor. Of course it’s not that simple as it may sound from this description, but in the end you’ll get a full-featured handle-based model not unlike the Java Model in its essential qualities (functional and non-functional). And if your language happens to be Xtext-based, you’ll also get an automatic asynchronous reconciling of your model (with corresponding notifications) when typing in the Xtext editor; it’s just a matter of a few bindings in the Xtext UI module for your language. The initial contribution will include an example of a full-featured Handly-based model for a simple Xtext-based language, complete with automated tests, content outline and a CNF-based navigator view.
Furthermore, your Handly-based model will be accessible through a uniform API, which can potentially be leveraged by a multi-language IDE infrastructure in the future (for example, it could be used by a common outline framework).
Now, that’s just a vision and an initial contribution. Making this a real success requires bringing the IDE community together, breaking down the project silos and, last but not least, your help. Spread the word to people you know who might be interested. If you have not yet read the proposal, perhaps it’s a good time to do it now. Please send all feedback to the Eclipse Proposals forum — it’s the official communication channel. The forum topic for the proposal contains a short FAQ that you might find interesting too. If you’re even mildly interested in the proposed area of work, I ask you to join the developer mailing list as soon as the project is created. We are open to everyone’s input. Especially welcomed to contribute and join the ranks of the project’s committers at their earliest convenience are folks with significant experience in handle-based models. Seasoned Eclipse-based language-tooling developers, you are very much invited! It might be an excellent opportunity to come together! I expect a lot of fun down the road!