In answer to the question "Where are the high-level Open Source design tools for Java?" I believe that they're emerging from efforts at Eclipse.org. These efforts began with the Eclipse Modeling Framework (EMF) in 2002, and have been building momentum ever since, with the addition of the UML2 project, the Graphical Modeling Framework (GMF), the Generative Modeling Tools (GMT) Project, and Model Driven Data Integration (MDDl). More recently, with the creation of the new top-level Eclipse Modeling Project (www.eclipse.org/modeling) to act as a home and focal point for all of these modeling related technologies, there is clearly an ever-growing focus in this area. So what does it all mean and what's behind the acronyms?

The focus of the Modeling Project is on bridging the design-versus-development gap using a bottom-up approach. We're building practical development tools and frameworks, evolving them over time, and using them ourselves to build the subsequent layers of the onion.

For example, given just an XML Schema as input, EMF and GMF can generate a fully functional graphical application ready to be tailored and specialized. Furthermore, since the generator technology supports merging, a developer can switch between modeling and hand-coding. This is essential for the adoption of high-level tools by a community that likes to view them as a dimmer switch it can adjust to suit various skill levels, rather than "all dark" or "all light" tools that replace hand-coding. And since the model can be specified in the form of annotated Java (which the generator produces to support round-tripping) it's possible for a developer to work completely in Java without buying into the whole sales pitch of the model-driven approach.

We validate these ideas by eating our own dog food: EMF models are used extensively throughout the Modeling Project, and many of our tools are based on EMF-generated editors. Now, with GMF maturing, we're beginning to use it as the basis for more sophisticated, user-friendly tools.

The Eclipse modeling tools are trying to appeal to as broad a target audience as possible by supporting many different development styles, something that hasn't occurred in the past and that, hopefully, will dispel the myth that modeling and coding are mutually exclusive or just rigid one-way processes.

I believe the main stumbling blocks to acceptance of design tools have been the rigidity and complexity of the methodology itself and the poor quality of the artifacts that they generate. To address the former issue, the Eclipse modeling tools have focused on building exemplary support around a very simple core model rather than around something much more complex. To address the latter issue, we've focused on producing code of handwritten quality. If a tool doesn't produce high-quality code, language-fluent developers will often reject it.

To understand the target audience for modeling tools, I often relate back to my own experiences and how my thinking has evolved over the years. When I was first exposed to MOF (Meta Object Facility), I didn't know how to read UML diagrams, so I was immediately convinced that they were a useless diversion. "What's wrong with plain old Javadoc?" Then, I looked at the generated code, and I was immediately convinced that it was too verbose and inefficient to be of any use at runtime. "I'd never write such garbage by hand!" And, when forced to learn the meta-model itself, I was immediately convinced that it was full of extraneous baggage. "Who needs all this stuff?"

Despite my "well considered" objections, I continued to use MOF in my day job and had much time to reconsider. Having learned to read a class diagram, it didn't take long to be convinced of the cliché "a picture is worth a thousand words." It also became clear that if it's silly to draw a picture of a labeled box containing a labeled feature, it's even sillier to write by hand, possibly thousands of times, an interface with a getter, a setter, an implementation class with the same things as well as a field to store the data, and last but not least, a factory method to create the instance. All of this is menial work that's beneath the skilled developer. Ironically, the very simplicity of the diagrams that made them seem silly is precisely where their value lies.

The code being generated was of poor machine-written quality, but it quickly became clear that this could easily be addressed by producing simple, clean code that looked exactly like I'd write by hand. For example, a getter need not do anything more than return the value of a variable. And, by using a template-based approach, we could provide flexibility and control to any developer, letting him tailor what's produced by the generator to fit his specific needs or tastes. Add to this a generator that can merge its output with existing code, and you reach my tipping point: a tool that struck the dual sweet spot of automating menial work while enabling me to remain creative. Ever since then, I've worked on EMF in my day job and never looked back.

Given my own evolving ideas, these days, even when I hear "well considered" objections that sound all too similar to my own, I am quite certain that the value of modeling will slowly but surely become clear. It's ultimately not the modeling tools that are of the greatest value, but rather the models themselves.