The Visual Editor, plug-in guidelines, UML and modeling
Tim: Could I ask about another project, the Visual Editor project. Can you outline what the goals of that are?
Mike: There’s a set of projects within Eclipse which are basically generic frameworks. The Visual Editor project falls under that category. It’s intended to be a very generic framework for creating GUI builders. So it’s not a GUI builder, it’s a framework for creating GUI builders. One of the interesting wrinkles of that is that it supports both Swing and SWT. So again, you have a framework even at this level where we will be able to offer developers choice.
Tim: Although it is as you say, a framework for creating GUI builders, it does come bundled with GUI builders.
Mike: Yes, and that’s consistent with everything that goes on at Eclipse. Our design goal is that Eclipse, and you’ll see at several different places on our web site, where we talk about building extensible frameworks and exemplary tools. People think of Eclipse as being an open source framework for building tools, but people inside Eclipse actually think of it primarily as for building extensible frameworks. And then we build a tool on top of it to show people how you can use those frameworks. So what the Visual Editor team is doing is completely consistent with what’s going on with what’s going on with the platform project and pretty much every other project inside Eclipse.
Tim: The ordinary developer, who isn’t going to build a GUI builder themselves, will be particularly interested in what they can get bundled with Eclipse.
Mike: Yes, and within Eclipse I’m trying to encourage more in terms of providing integration with the visual editor and the rich client platform, to help enable people to build these kinds of rich client applications.
Tim: One criticism I’ve heard of the Eclipse project is that there’s too much diversity among the different plug-ins, and that there isn’t a tight enough standard in terms of how an Eclipse plug-in should behave.
Mike: Certainly it’s a valid criticism. It is possible to load a set of plug-ins in your environment which do not cooperate in the ways that they should. And there’s several different reasons why that’s true. First and foremost, lots of plug-in developers cheat, There is a well-defined API that plug-in developers are supposed to stick to, and many of them don’t. There’s basically two different things happening within the community that I believe are going to address this over time. The first is, I’m seeing the emergence of distributions. Innoopract in Germany has put together an Eclipse distro that bundles together Eclipse 3.0 with on the order of 25 of the most popular plug-ins, and they have done the effort to make sure that these all work together well, and provide a good out-of-the-box experience for developers.
So that is one thing that is happening in the community that I think over time will help address this. The second thing is that we are looking at ways internally within the Eclipse community to define and build some sort of certification program. I actually think it is going to take a significant amount of time for us to get this off the ground. I’m talking six to twelve months. But I hope that at some point down the road you will see some sort of program by which you can get plug-ins which have been certified that they do conform with the APIs and that they should be expected to work in cooperation with other plug-ins in your environment.
Tim: I guess style guidelines are also important, because developers don’t like to switch between different UI styles within one tool.
Mike: There is a style guide on Eclipse, but I don’t know if I want to go too far down that path because I don’t want to do something that would stifle innovation. I think that the community forms a marketplace, even in the open source project. If someone’s building something in an open source way they want people to use it. When it comes to things like style and workflow and so on, I would like that to be answered by the community in the way that most things like this are answered, and that is by having people tell the developers of a particular piece of software that they don’t like the way it works. I wouldn’t want to have some sort of Eclipse apparatchik telling people how to develop every piece of software in the Eclipse community.
Tim: What progress is Eclipse making in supporting non-Java languages? I know C++ is fairly advanced.
Mike: Yes, and COBOL is coming along. Fujitsu is leading the COBOL project within the Eclipse community. There is a plethora of plug-ins out there for other language environments, especially scripting languages. You can get Eclipse plug-ins for Perl and PHP and so on. Aonix just announced a fairly comprehensive Eclipse environment for Ada. I’m struggling actually to come up with a significant language for which there is no support. Eclipse, UML and modeling.
Tim: I notice that there are some UML and modeling projects.
Mike: There is a strong and synergistic relationship between Eclipse and OMG in the modeling space, where they have come to us in various areas to help create implementations of UML specs, to make sure there is at least one open implementation for these things. I think that pattern of a strong relationship between open source and open standards is something that is great for the industry and something that I hope to see lots more of in the future. With regard to modeling specifically, there are a couple of projects, EMF [Eclipse Modeling Framework] and UML 2.0, that are expanding Eclipse in the modeling area. And that’s an area where I see lots of future growth for Eclipse. I actually hope that at some point we’ll have a top level project within the Eclipse community which is specifically directed in the modeling area. We’re also looking quite heavily at the whole model driven architecture approach and looking at what we can do in those areas.
Tim: JDK 5.0 is coming out shortly. What’s the status of Eclipse in terms of new features of Java such as generics?
Mike: There’s a plug-in available today that provides JDK 1.5 (or Java 5.0) support. It’s not part of the official 3.0 release but it’s made available concurrently with 3.0. So it’s out there in an open source way, and we’re looking for community feedback to see what more we need to do with it, but we have that particular Java branch well in hand.
Tim: Anything else you want to mention?
Mike: Two things. I’m not sure if you follow the BI [Business Intelligence] and reporting space at all, but I think the announcement this week of Actuate joining Eclipse and starting a top-level project to do BI and reporting is truly exciting, for three different reasons. One, this is a really interesting area for Eclipse to expand in. I think BI is a market segment that has been growing, and there’s a lot of interest in enterprises in having good BI tools. Two, to our knowledge at least, this is the first open source initiative with the kind of backing that is really tackling BI and reporting. We think that open source could have some interesting ramifications for all the vendors in the BI and reporting space. Then thirdly, I think it shows the success and momentum of the Eclipse Foundation as an organisation, to have a new strategic member step up and join the board. Whenever you can expand your membership at that level, that’s great news. One other area that I’d like to mention is embedded development, an area where we are seeing significant interest in Eclipse.
Tim: Do you mean J2ME specifically?
Mike: No. If you look at the vendors that are supporting our C and C++ tools, and QNX in particular which is a board member, the main usage of our C and C++ tools are embedded developers writing in C. J2ME is an aspect of embedded, but it is in my mind certainly not the aspect. There’s lots more embedded development that happens in languages other than Java. I expect to see significant amounts of growth in embedded development in multiple languages.
Copyright Tim Anderson Sept 06 2004