Mylar is often referred to as one of the key innovation in IDEs since content assist. I will never forget how much easier it became for me to stay in the flow of my coding the day I switched from Emacs to Visual J++ 6 and could instantly see all relevant methods instead of searching for them. Having built a single suite of AspectJ tool support that ran in JBuilder, NetBeans, Eclipse, Visual Studio and Emacs, I am often asked about which IDE tool platform is best and whether Mylar itself could be ported to other IDEs. To me this question boils down to: what is required of a platform to support unforeseen extensions such as Mylar’s Task-Focused UI? This entry discusses how openness and modularity enable the implementation of innovative solutions. Part 2 will discuss how tools and community can create a positive feedback loop that can help shape innovations into usable tools. Part 3 will discuss how frameworks and integration make it possible to create a solution that integrates across tools and platforms. While I will be using Eclipse as an example of a state-of-the-art platform for innovation, I will conclude with a demonstration of how it is possible to integrate Eclipse-based solutions with other tool platforms such as IntelliJ IDEA and NetBeans.

Openness

Openness is a spectrum. We are seeing a trend of open data coming from web services, making it possible to embed Google Maps in your own site and making it feasible for Mylar to provide a rich UI to web-based issue trackers such as Bugzilla. However, open data is not sufficient to for providing deep integration that is streamlined with the user experience. For that open APIs are needed.

When programmers design APIs, they do so with a preconception of the kinds of extensions that will be supported. During crunch times, such APIs often take a back seat to other items destined for the feature matrix. In addition, there is a necessary tendency to limit extensibility in order to limit the maintenance burden of the API. As a result, I have never encountered an API that would have supported a robust implementation of either AspectJ’s AOP or Mylar’s Task-Focused UI. For example, when we integrated AspectJ with the pre-Eclipse version of JBuilder the open APIs could not get us to the point where we could show aspects in JBuilder’s existing views. Instead, we had to create new views, at the cost of a streamlined user experience.

Java is a language that builds on a long tradition of object-oriented openness and extensibility. As such, it helps developers cope with API limitation by providing mechanisms such as method overriding and reflection. Relying on such mechanisms introduces a maintenance burden, but it enabled us to ship JBuilder integration for AspectJ, albeit without a streamlined and well-integrated user experience. An amazing thing happened when we were handed not just open APIs but a completely open source IDE platform. Building the NetBeans integration for AspectJ took an order of magnitude less times and facilitated maintenance. Open source platforms make their architecture dramatically easier to understand, access, and extend. That translates to faster implementations, easier maintenance and most importantly, to a better-integrated user experience.

Modularity

The key thing I have learned from building IDE extensions is that the measure of an open platform is its modularity. I was thrilled to see this demonstrated by Carliss Baldwin, who argues that modularity increases option value, which in turn can increases a platform’s utility (see her publications). The Spring Framework’s architecture exemplifies the power of good modularity. Modularity determines which components you can reuse and extend and which ones you have to re-invent. For example, Mylar adds an entirely new paradigm for working within the Eclipse IDE that affects almost every view and editor within Eclipse, yet it only adds the need to open a single new view (the Task List). Monolithic platforms often try to provide quality by limiting extensibility, attempting to ensure that the platform is hard to break by third-party extensions. Extensible platforms instead ensure quality with good modularity. For example, Eclipse’s content assist is fully extensible, but will disable an extension that malfunctions or takes too long to execute, informing the user of this fact so that they can help the originators of the extensions identify the problem. I was thrilled to see a bug of this form reported to Mylar because it made me realize how platform mechanisms of this sort can drive the input that is required for innovations to mature. I will discuss the role that the community feedback loop plays in Part 2.

An incredible thing happens when you mix openness with good modularity. Unforeseen innovations can be made highly usable and robust by a team that is independent of the creators of that platform. But to enable reuse of that modularity we still need a solid component model. To facilitate creating and the innovations we need the platform to provide good tool support. I will address those factors in upcoming posts.

Thanks! My plan is to blog every week or two, so Part 2 should come next week. If you have any particular curiosities about this topic please post them so that I can address them here or in the upcoming entries.

[…] a few weeks of experience building on it, it became clear to me that Eclipse was going to be the platform for innovation in the tools space. At that time I based this judgment almost entirely on the modularity and […]