5 - Jeff McAffer of the RCP Project

Riyad Kalla: Welcome to episode nine of ten in the Eclipse inclusion podcast series. I'm your host Riyad Kalla. In this series we're interviewing key members from each of the Eclipse projects. They'll be included in the Eclipse inclusion release. Today we're interviewing Jeff McAffer who is part of the RCP effort. Thank you for joining us today Jeff. Why don't we start with you giving us a description of what the RCP effort is all about?

Jeff McAffer: Sure, thanks for having me. The RCP effort is really about making Eclipse available to people who are writing standard applications as opposed to classical Eclipse which is seen as a tooling platform for writing C tooling or Java tooling. But the RCP effort is all about using Eclipse in other domains and everything from spacecraft management like the NASA guys are doing to banking and finance and email like many of the IBM teams are doing. Managing all sorts of enterprise applications, writing all sorts of enterprise applications. That's really the gist of it. It involves generalizing the infrastructure we put together so that tools from the original tooling platform. Making it more flexible and handling the additional use cases and scenarios.

Riyad: The RCP group was an initiative put together to evaluate the platform as it was used for projects other than tools. This where we need to make it more application friendly. What is your role in this? Are you guys actually coding the wizards and all or are you kicking back comments to the platform team about where they need to improve?

Jeff: It's interesting. Maybe I'll set the context a little bit for this effort. The RCP effort for the most part, and actually I'll step back even a little bit further first, and say RCP really isn't a thing. It's more of a concept. It's a notion that you can use the Eclipse infrastructure for general purpose applications. It ends up that we don't actually have an RCP team and there's not actually an RCP project. There is an RCP team but it's a virtual team because the RCP notions cover all different aspects of the Eclipse platform. The RCP team is largely made up of folks who are platform Eclipse top level project committees in various areas like the runtime and the UI and PDE and JET et cetera all coming together. The focus is on a scenario where you're using Eclipse as a general purpose application framework or platform. What we do is we look at things that are developing in the community. RCP and the use of Eclipse as a rich client platform is really something that developed as a full effort from the community. People were taking our tooling platform and building whacky stuff, taking it apart and ripping code bits out and refactoring our code and literally hacking and slashing to get it to a point where they could use it for their application. We saw this and all these people coming in saying could you generalize this and make that more open. We said this is really cool and a really good idea so it became a first class effort within the overall Eclipse project. We put together essentially a virtual team with people who are focused on making these scenarios and making the tooling. There's a big effort around tooling and the PDE guys put in a lot of work to make the tools and wizards and all the building and packaging steps go fairly smoothly. That's really how it evolved.

Riyad: Well can back up to the roots of the project. When Eclipse started out obviously the Eclipse 1.0 release was definitely an IDE and that's where that thought that Eclipse was only an IDE for so long came from. Then in 3.0, which was fairly late in the game, 2.0 release was a big release but 3.0 was the first shipping RCP, the Eclipse platform as a premier general purpose application platform. Was Eclipse always intended to eventually meet that goal or was it because people started pulling apart the code that the RCP project got started? How did that come about and when did it start and things like that?

Jeff: I guess I would say that's it's a bit of both. In reality we needed to focus on a problem domain to be successful. Our problem at hand for us was tooling so we focused very much on tooling and gave all of our effort in that direction. We stepped back and looked at what we were doing and realized it could be more general. The use cases weren't coming at us and weren't pulling us in that direction. We were still focusing all of our effort on tooling platforms. Around the 2.1 timeframe, people were doing things like I described with the platform to use it in more general purpose ways. I gave a talk at EclipseCon a couple years ago talking about the evolution of RCP and in the 2.1 timeframe. I characterized it using current TV shows and the one I used for that one was Monster Garage where they take normal vehicles and they do bizarre things to them like put wood chippers in the back of a PT Cruiser and that kind of stuff. Things like that aren't right that people are doing with Eclipse. If a lot of people want wood chippers in the back of PT Cruisers Chrysler might start offering that as an option. We recognized a lot of people wanted file menus that didn't quit on them and stuff like that, a lot more fundamental things than just that but you get the idea. We built in the flexibility people wanted. Largely it was a pull process from the community and we sort of bit in hard and believed that this was a good thing to do.

Riyad: Is it still in process or are you guys running at full steam now and you know exactly what needs to go into it?

Jeff: It's very much a pull process although it's a bit of both. We see in our day-to-day uses of Eclipse the people who are close to us and the people who are active in the community and what they're doing and what they need. So we work very much with them to introduce the flexibility and function that they want. One thing is, as there's only so much that we do within the Eclipse platform, that's a low level project. We do a lot of enabling function and the framework and the basic function and flexibility. A lot of the value now of using Eclipse comes from all the other things you can get like BERT and DTP and all the other projects and EMF and all these other things like having RCP enabled technology so you can get and use BERT and have a report generating part to your application. A lot of enterprise applications have and need report generation tools. A lot of RCP applications need database integration so a lot of the advances in RCP, from a general application writer's point of view, will come in other projects within Eclipse by them developing more technologies that are applicable in RCP scenarios. There's a few areas in the Eclipse platform we can improve to make RCP better, things like provisioning management and deployment and those sorts of things. Those can be improved to make life easier for RCP developers and employers.

Riyad: Do you find the majority of the Eclipse development market both open source and commercial is still tools? Or have you guys been surprised that it's now a 50-50 split between untool related development and tool related development.

Jeff: That's interesting. It's very hard for us to tell. It's very difficult to find metrics for a number of reasons. For one, we can measure downloads of our different offerings but, since most of our offerings are tool related, we have an RCP download but that's something that relatively few people get because of the way you do RCP development. In terms of the sorts of surveys, analysts Forest and Gardener and people like that generally survey things like IDE usage. What's your favorite IDE? What do you use most of the time? That kind of question. Then the other part of the difficulty is we know of many companies that are using RCP and a lot of them frankly are retaining information as the secret sauce. It's an advantage that they have in their industry and telling their competitors they're using RCP and Eclipse and they are having great success and giving them orders of magnitude improvements or whatever is something they're not keen to tell all their competitors. It's very hard to measure and I don't know how we could answer that question really.

Riyad: So you could walk into EclipseCon next year and be surprised by some of the applications you see there?

Jeff: I am continually surprised by what I see.

Riyad: What's the most impressive one that just stuck in your mind off the top of your head that you're really shocked?

Jeff: I guess this one that came out a couple years ago really. It was by the NASA guys. The NASA stuff is cool because it's kind of sexy space stuff you know. For people who don't know what's going on, NASA is using Eclipse RCP in a project called Maestro and now one called Ensemble. This is the software basis used for planning the Mars Rover missions. Right now Spirit and Opportunity, the rovers currently on Mars, have their day-to-day actions planned and analyzed using Eclipse RCP based software. They've had an explosion of usage of Eclipse throughout NASA and indeed throughout the space community. A couple of weeks ago, I was out in California at NASA and gave a talk to a conference on space mission software. There were lots of people who were interested in Eclipse, using it as a development environment and also using it as an RCP to help them solve their problems with the space mission software. I talked to several groups at NASA that are doing lots of different things and evolving it very quickly. That's the sexiest thing all right. There are lots of other really cool things like whole banks changing their equities trading software to use Eclipse.

Riyad: What do you think the key there is? Because we've had other platforms out there for years and Swing has been there a long time. What do you think it is about the Eclipse RCP? You said at NASA the usage is exploding there. What is it about it that gets people hooked in and dialed in and sent running? What's the secret to it all?

Jeff: That's a good question and I honestly don't know the full answer to it but I can give some sort of guesses. Really I think it's the platform effect. It's the ability of one group within an enterprise to start using Eclipse for whatever reason. A guy goes to a conference and thinks it's cool or listens to this podcast and thinks it is cool. Then he goes and does some testing and experimentation and builds a little application. The guy down the hall saw they could do a similar thing but their domain was slightly different and they could start sharing these plug-ins and do all this different stuff. It just sort of evolves from there and that's what happening today in NASA for example and other places I've talked to. They're building and we have an RCP platform and if you look at the Eclipse project, we have OSGI. Maybe we could talk about that later. But we have OSGI at the bottom which is a runtime platform and then you have RCP which is a rich client platform and built on top of that is the IDE platform. We've been living this story ourselves by evolving platform after platform after platform and going up the value chain really. In terms of why is this different thing then Netbeans, Netbeans has a modularity as well. Frankly, I think we've tuned into that need and the community has pulled it in that direction and users of RCP are able to create realistic looking performance evolvable systems.

Riyad: You were mentioning RCP in the platforms and really embracing the idea of platforms. The RCP is branded as a combination of the runtime, like you said, and the OSGI runtime which is Equinox STJ face prerequisites like the help update manager. Where do you draw the line? How did you decide this is going to be the rich client platform and this is not going to be in the platform?

Jeff: That's a really good question and we struggled with it for quite a while when we were trying to decide should we have an RCP download. That sort of question. So what is RCP? When you have to make a download, you have to decide what goes in it and when the rubber hits the road, you've got to decide. As we talked about earlier, it's really RCP as a conceptual thing and not an actual thing. If you try to tell somebody that was all it was, and you didn't give someone a concrete notion of what it was, its very difficult. We had to actually define it. The easiest way to talk about it is the base pieces of Eclipse that you need are used to write a rich client orientated application. So you obviously need a runtime as that's the basis of the whole shebang and then you need the UI bits: SWT, JFACE, and the UI workbench. That's really as far up the stack as we go when we talk about RCP. If you took off the RCP, you'd have CP because it wouldn't be rich anymore. You'd get a text UI or something if you took out OSGI and just started using SWT and JFACE, which are usable standalone. Well, you're not really running Eclipse because if you really start to dig down to what's the fundamental element of Eclipse, it's the plug-in story. It's the extensibility, that sort of stuff. If you take that out of the picture, you don't really have a platform. So you've taken the P off RCP. Really that base set of Equinox, SWT, JFACE and UI workbench are the key ones. Interestingly, you mentioned in your list help and update and forms and those sorts of things. Those are really cool examples of functions that are commonly used in rich client applications. Also, they're commonly used in IDE's. It's just another function you might need in your scenario. There are tons of this, other function from Eclipse projects or other open source projects or, for a fee, from other commercial offerings. Your job as an RCP application author is to gather these pieces of function, these plug-ins, and put them together and coordinate them to solve the problem you're setting out to solve in your domain.

Riyad: In the newest release Eclipse, the Eclipse 3.2 release, what were some of the exciting new changes? We've been talking hypothetically for a while. What were some of the kickers in that release that RCP authors are going to love?

Jeff: A number of things. A few things are specific to RCP and some are more general that we added in the platform that will also give a really good boost in the RCP world. Some of the explicit RCP things the PDE team did was to put in a lot more things to make the workflows smoother and more functional and to add more options and that sort of stuff when defining rich client applications and that sort of stuff. Target management is one of things that is near and dear to me. This is the idea that you can write an application that's targeted to a smaller JRE. You don't have to just be targeting a JRE, Java SE 1.5, you can target it against the foundation 1.0 JRE and ship something that's really, really small. That kind of stuff PDE has very sophisticated support for managing, making sure that you get compiled against all the right things that kind of stuff. Stepping back from the tooling side of things, there were some improvements in the update manager in particular and the incorporation of Pack 200 technology which is standard in JDK 1.5 and for digesting updates. The net effect is that Pack 200 basically allows you to compress your JARS anywhere up to 70 percent. That is, knocking 70 percent off the size of the JAR. The digest is basically an amalgamation of the metadata in an update site. So when you go to do an update, you can get all the metadata you need in one shot. The net effect is you can find out what's there really fast and get it in half the bandwidth you could before. Two times faster and less bandwidth and the latency is much lower because you can get the metadata all at once. That was a really cool improvement. There are lots of improvements in the tooling and new widgets in SWT that are useful for RCP development. Lots of things like that.

Riyad: Another one of the additions that I saw in the notes was the ICU for J the adaptation of that project. How has that been perceived and was that put in because it was more robust than the JDK or seen as necessary because of complaints from customers or platform developers?

Jeff: It was seen as necessary because we have a very strong commitment to supporting as many of the locales as possible. For those of you who don't know, what ICU gives you is there are certain problems with internalization in various locales around the world that the JRE doesn't solve. It just doesn't handle them properly and results in goofy things or just doesn't work. ICU for J is a library that actually does handle these locales better. Many of the locales are for most of the listeners probably remote and they think, "Why do we really care?" But it's very important. Eclipse should be seen as a global platform that anyone can use, so we take that really seriously. Then so we have this library and the API is very much similar to the original, the standard JRE libraries. So the conversion from the standard JRE library calls to using the ICU calls is really fairly straight forward in most cases. The change over is relatively easy and done quite quickly by most of the teams. It wasn't a huge impact to use, yet it gives people great value and opens up whole new markets for Eclipse and Eclipse based products for anyone building projects in Eclipse.

Riyad: Is ICU for J going to become a top level Eclipse project at some point?

Jeff: Indeed. ICU for J was also interesting in that it's one of the first times that the actual Eclipse project and SDK collection of things is incorporating a third party library. This comes from another team that happens to be folks from IBM and they're hosted I think on sourceforge. There's a very strong commitment behind it and that sort of thing. We just consume their binaries. They build it and take care of packaging and everything and we just take their plug-in. They've been kind enough to structure their code and the build output as plug-ins. They give it to us in a form that is easily consumed and we just take that and drop it in our builds and run with it. We don't even compile it ourselves. We just use what they give us. Bug reports go to them. Fundamentally, it's not a tenable direction for us to absorb every piece of software we happen to use into Eclipse. The whole point of components is you can take components from other people and use them. We're sort of walking the walk, if you will, in that regard.

Riyad: Going back to the RCP development for a second, what is your favorite GUI builder for Eclipse, commercial or open source?

Jeff: Anyone who knows me knows that I'm not a UI guy so I don't do a lot of UI's and what I do are generally the subject of ridicule and used as examples of what not to do. UI builders are help for me but I don't tend to do UI's much. Having said that we've obviously got the visual editor in Eclipse.

Riyad: Can I guess what your favorite is?

Jeff: Sure.

Riyad: Motif.

Jeff: Yeah, yeah. You know what, it looked cool I would use it maybe if I was doing Swing stuff, but I'm not. The guys Instantiations have done what I hear is a really nice GUI editor called the SWT designer, I believe. I've heard lots of great stuff and seen demos and stuff. I haven't used a lot myself but it looks really good. I believe it's quite good.

Riyad: Now we'll gloss over to the next subject. This is just your opinion on the topic. How would you rate RCP development in general on Eclipse on a scale of one to ten? Where do you think it stands now and, if it's not a ten, where does it need to go to get to a ten? Is this like a Europa type thing where you think you'll nail it or is this a long-term need a couple more releases to get there?

Jeff: That's a hard question for me because I've been involved in it for so long. For me, I'd rate it a nine because there's still some stuff I'd like to see done better like better support for component management and sort of some of the basic level pieces and some more support for higher level pieces like help content authoring and intro authoring and those sorts of things. But if you step back from just me, for somebody who's not been deeply involved in it forever, I think the main challenges that they have are probably things around the class libraries and complexity. There's a lot of function in Eclipse. The platform gives you a lot of things it does for you but you end up having to program against a lot of these APIs. I think for sure we can make a lot of those paths easier. We can make the coding patterns better and that sort of thing and I think that is and will remain one of the major challenges for people adopting RCP whether it is Eclipse or any other large Eclipse library set. As I mentioned before in terms of evolution and why somebody couldn't rate RCP as a ten, it's not so much its deficient, it's just that it could be so much more. The BERT guys getting there and this is not at all a criticism of them. Further development like that and the incorporation of reporting or database management and all these other things are continually evolving. All of those sorts of things are coming in. The platform is getting richer and richer and you have to do less and less of the infrastructure. Really, that's what RCP is all about. It's the middleware for applications. It's all the gorp you don't want to do but you need to have to have a real application. As applications get more and more complex, richer and richer, there's more and more of this gorp you need. In the world of corporate development that's what we do. We do the gorp so you don't have to, essentially.

Riyad: That is kind of the problem. You said you know getting started with Eclipse isn't just a 30 minute thing where you sit down and start coding up an app the next thing you know you have things running. It's incredibly robust and rich. How would you suggest someone get started? Some guy's a Java developer. Let's say he's server side developer. He's done Swing once or twice and maybe an applet. He goes, "I want to jump on this bandwagon and become an Eclipse developer and I want to do a little utility. Maybe it just checks my email every once in a while and gives me summaries of my email from Thunderbird or something like that." How would you suggest he get started?

Jeff: We'll I'd probably have to send you a check in the mail later because that's a perfect intro for a shameless plug for the RCP book that me and Jon Michelle wrote. It came out last year and it really is structured such that it has a tutorial section in the first half of the book that does exactly that. It takes you step by step through writing, starting from an empty machine and telling you how to get everything installed and set it up and start your workspace.

Riyad: What's the name of the book for people listening?

Jeff: "Eclipse RCP", "Eclipse Rich Client Platform". It's part of the Eclipse series from Addison Wesley. There are really a number of other resources out there. There are tutorials given at EclipseCon and other conferences. I think EclipseCon two years ago and last year had several good RCP tutorials in them. A lot of those slides are available on the EclipseCon.org website. Really, the way to do this is to take baby steps and start small and start with a simple application running and start incrementally adding pieces to it. Then refactor that and say, "Well, if I spit that off, then I can do more use cases and can get more functionality or flexibility." Just keep on building it up and keep on refactoring. That's one of the key things, always refactoring and always sort of restructuring your codes so that you can get more flexibility out of it.

Ultimately... Whenever I talk about this sort of stuff I get really excited about platforms. And I keep talking about the word platform. I say that a lot. But ultimately, you're seeking to create a platform really. Because where you really get the value out of something like Eclipse, is making a platform that other people can use and that can be reconfigured to satisfy different use cases and that sort of thing.

Riyad: Right. Eclipse is a perfect example, or at least Eclipse plus all the sub-projects. It's a platform of platforms. Every project that comes out is never just a project, or just a GUI to do something. It's inevitably a platform of some kind with maybe some examples. And you're right, that is part of the key to the success story of Eclipse.

But I also think... You mentioned early on that the PDE guys did it again. From the beginning, at least according to the comments I've heard from other Eclipse developers, the amount of detail paid to the actual plug-in development itself...The idea was just strong right out of the gate, helping you develop plug-ins. There was none of this hacking through files just to get an icon to show up type of stuff.

Jeff: Yeah. Well in the very early days... It's kind of just a side story. It was very ironic. The PDE guys actually struggled because PDE wasn't there at the very, very beginning when we were actually just developing from ground zero, all the way up. So most of the core Eclipse team got used to hacking and slashing the files to get a menu to show up.

So then the PDE guys went and did all this great stuff, making all these cool editors so you didn't have to hack and slash the XML files. But everybody was used to hacking and slashing the XML files. They just didn't move over. And I'm guilty as the next guy.

But now, oh my goodness, I can't believe that I ever did that because now I look at the XML files and I have no idea what format they're supposed to be, what tags are where and all that sort of stuff. So PDE is definitely where it's at.

Then the class path management stuff, I've got to tell you, anybody trying to manage class paths... In fact, today I ask people, "Why would you ever create a new Java project?" You know, going "new project" and then picking "java project".

Why not create "new plug-in project" and allow PDE, even if you have not intention of writing a plug-in, running it on OSGI or Eclipse or anything like that? Your just doing a regular Java, you're designing a JAR. But that JAR always, inevitably, has dependencies on something else. And PDE has a large area of function that helps you manage those dependencies.

Riyad: Interesting, I wasn't aware of that. So would that work be pushed into the JDT at some point?

Jeff: Well yeah. We're talking about that and trying to decide at what level, how generic that function could be made and where that would fit. But I think that's a really value add.

You, as an Eclipse developer, can get today... Just forget about "new java project." Always make a new plug-in project. And then you can describe your dependencies. You can check your dependencies. You get errors when you violate them. You get help in finding them, all that sort of stuff.

Anyway, that's an aside as to the value of the PDE and some of this other tooling that is bringing Java developers and plug-in developers today.

Riyad: Very interesting. So let's change gears here. We talked about RCP. But a lot of Eclipse developers and people who read about Eclipse all the time are going to see phrases like OSGI, Equinox, Eclipse Platform. First, can you explain the differences between OSGI and Equinox and then the Eclipse Platform? Give us an idea of where all this stuff sits in relation to each other.

Jeff: OK. Maybe I should situate OSGI and Equinox first.

Riyad: Sure.

Jeff: Because those are actually two separate things. OSGI is actually a shortened term. OSGI Alliance is actually the right name of the standards body. And we talk about the OSGI Service Platform Specification as one of the specifications that that body puts out. That forms the basis, that specification. We then the take that and implement it in the Equinox sub-project.

So there's a sub-project called Equinox, whose parent is the Eclipse top-level project. And that is an implementation of the OSGI Service Platform Specification, Revision Four. In fact, it's the reference implementation of that specification. So Equinox is this implementation of the framework. The framework gives you, essentially, the runtime.

The OSGI term for plug-in is bundle. But anybody who knows me, know I'll say plug-in equals bundle. They're the same thing. Plug-ins are bundles and bundles are plug-ins. It's this notion of having a unit of code, typically a JAR or a directory that has a bunch of JARs in it that has set of dependencies on other bundles or plug-ins.

And the system can load those plug-ins atomically. You have one class loader that loads all the classes in there. They can correctly manage the interdependencies at class loading time. That gives you the basis for the Eclipse component model and the ability to have plug-ins, add plug-ins, remove plug-ins, all of that sort of thing.

So, that's sort of OSGI and Equinox. That's what they are. And you're original question was what's the difference between OSGI Equinox and what people see as the Eclipse Platform, or the IDE, the STK?

Basically, it's fairly straightforward. The OSGI Equinox is the runtime for the platform. So the platform is really just a collection of bundles, or plug-ins, on top of the Equinox framework implementation.

Riyad: I see. Now how did OSGI get started? We had talked to some other project leads and they had mentioned that Eclipse started way back in the late '90s and early 2000. Did Eclipse start as a normalized tool platform and then later they said, "Hey, let's just standardize this whole process and call it OSGI?" Or did OSGI start and then Eclipse came along?

Jeff: That's actually interesting. There's a little story there. Basically, OSGI and Eclipse started about the same time and on their own merry paths.

Riyad: Both at IBM or outside?

Jeff: In fact, both at Object Technology International which at that time was a subsidiary of IBM. We had one group of people who were doing tools, who were in one set of physical locations. And another group of people who were doing embedded runtimes, who were in another set of locations.

They both had cause to evolve a component model. The OSGI work evolved out of some of the stuff at OTI and some of the stuff at the rest of IBM. They all colluded together basically to satisfy component needs in the embedded set-top box environment. OSGI used to stand for Open Services Gateway Initiative. The gateway was residential gateways, set-top boxes, that kind of thing.

This was, like you said, in the late '90s, when this vision of people having a cable box on top of their TV and playing games, ordering food and all that sort of stuff via downloaded software was prevalent, as a way forward. It hasn't really evolved that way, but OSGI's specification turned out to be fairly robust and flexible.

So anyway, Eclipse and OSGI evolved independently. And way back when, probably in 2000 to 2001, something like that, we crossed paths in one of our company meetings. I was talking about what a plug-in is. I had a poster session in a little conference we had, "What Is A Plug-in?" And they had a poster at the same time, "What Is A Bundle?" And so we were both sort of standing at each other's poster, saying, "Oh, really? Looks familiar."

And this was very early on for both technologies. So we looked at this and said, "Should we get together?" Basically this goes back to an earlier discussion about focus. We were very much focused on a set of problems and a tooling domain. And they were very much focused on a set of problems and the embedded domain. So we continued on our separate paths.

Then, as we both matured, certainly as Eclipse matured, we had our own runtime that we built ourselves. And it was different than any other runtime so there was no standardization there or anything. We were looking into 30 timeframe, as part of this RCP work to get some more flexibility in the runtime, both in terms of provisioning management and in terms of dynamic behavior. You know, adding and removing plug-ins on the fly, all of that sort of thing. And trying to appeal to a wider audience at the runtime level and be able to leverage a wider set of tools and technologies around it.

So we were looking for a standardized runtime to base ourselves on. We came back to OSGI. We investigated a few things, but we came back, eventually, to OSGI and sort of bit in whole hog and joined the OSGI community. And we work on the expert groups that set the specifications. There were some use cases that they didn't address in their R3 spec. We worked closely with them to bring some of the Eclipse use cases in. Now they're incorporated in the R4 specification.

So really, the short answer to your question is they evolved separately but now we're very much sort of in bed together.

Riyad: How come the Eclipse Foundation isn't listed as an OSGI Alliance member?

Jeff: Yeah, that's a good question. Right now, there is a huge overlap between the membership, between the OSGI membership and the Eclipse membership, companies like Computer Associates, Nokia, obviously IBM, Intel, Ericsson, Motorola and Oracle. All those guys are members of both OSGI and Eclipse. So it would make sense, with the obvious cross interest here, that OSGI be a member of Eclipse and Eclipse be a member of OSGI. And I believe that's going to happen.

Both organizations have been evolving policies and mechanisms to enable that to happen more easily. The OSGI Alliance recently introduced an associate membership level intended to accommodate this kind of thing. And the Eclipse foundation is actively figuring out how to interact with standards bodies. So I think those things will happen and you should probably see something in the not too distant future in that path.

Riyad: Is the writing on the wall that at some point these two things are going to overlap so much they might as well just combine? Or is the differentiation too big?

Jeff: I think, fundamentally, The Eclipse Foundation Charter does not allow them to set standards.

Riyad: I see.

Jeff: So Eclipse is not a standards body and OSGI is a standards body. So, at a fundamental level, I think they don't match. I also think that they're better off being separate. It sets up healthy tensions and all that sort of stuff. I think that it makes a lot of sense.

And OSGI has a usage. You can go out and buy a BMW. If you're so lucky as to have a BMW, one of the newer ones, you've got OSGI in it. That's not the Eclipse OSGI. The point being, OSGI has a lot of other uses. Eclipse is just another major stakeholder or interest-holder in that technology.

Riyad: Now, you kind of touched on the runtimes. What role did execution environments play, like client side, server side and so on, in developing Eclipse? Does that really structure and form the development efforts? Or is that just a side effect you look at later?

Jeff: Well, a bit of both. Because if we have the community pulling to use Eclipse in a certain way, whether it's client, server, tooling, embedded or whatever, obviously we sit up and take notice. And people contribute function in that area.

The server side stuff is a good example. Some other people, people from the community, were interested in using Eclipse on the server in a certain way. They put their money where their mouth is and contributed code that facilitated the use of Eclipse. In this case, embedded inside of traditional out servers like Tomcat, Waz and that sort of thing. When the community stands up and says, "This is what we'd like to do," and even more so when they stand up and give code and make contributions, we just love that stuff. That's great.

Riyad: Well then, going small first, how viable is Eclipse as a mobile application platform? And I'm asking this because I'm thinking of my old Palm. You know, these little black and white apps and these tiny little things on it.

Don't the memory and CP requirements, due to the class loading, the complexities of a JVM and the Eclipse Platform kind of class it out of smaller embedded markets like phones, and into a small computer market, like iPac and things along those lines?

Jeff: You know what? Because Eclipse is based on an implementation of the OSGI framework, and OSGI's origins are in the embedded world, the answer to that is... Actually I don't know if it's yes or no.

The answer is yes, you can use Eclipse in small environments because the basic Eclipse framework, the Equinox framework is around 800k. I have sort of regularly run Eclipse on my Linksys NSLU2, affectionately known as the slug. It's a little network attached storage device. It's a 133mgz, XScale processor with 32mg of RAM. And I run little server applications on there. It's running Linux and stuff so it's a fully operational computer.

The example we wrote for the book, it goes all through the book, is a chat client. And that chat client, we sort of did up a packaging for it to run on an iPac. And that packaging, with a J2ME, Foundation 1.0, JRE VM and class library, plus the actual application was around nine megabytes.

And we have several things running on phones, especially on the Nokia. The Nokia guys are big in the embedded Rich Client platform project at Eclipse. And on their 9300s, that sort of class of phone, and the series 80 phones they've got lots of OSGI and Eclipse capabilities. So you wouldn't put it on the tiniest, cheapest phones. But definitely if your phone has Java capabilities that are semi-rich, then you can run Eclipse there, no problem.

Riyad: Very interesting. Now going bigger, you mentioned the interest in using the OSGI underpinnings of Eclipse in the server side environment. And Wolfgang's written a couple of articles on EclipseZone covering that. How has that influenced your work on putting Equinox together, now that it's being used on the server side? Or is it affecting the work?

Jeff: It's affecting it, though, again, it's this thing where people are coming in and pushing things in a different direction by adding. They're contributing their code and their code places dependencies or requirements on the framework, the underlying implementations.

You need to generalize this. Again, it's sort of like RCP, right? You need to generalize that bit, change this bit, or give me a call here, whatever. So it's not fundamentally going to change the way Eclipse works.

But we are restructuring the way we start up, the way that we treat class loaders and globals. We used to internally use system properties all over the place. And we did that explicitly. We did that knowingly. And it turns out, obviously, that that's a problem when you do this kind of stuff. It was a relatively simple change to go and change it all to use, essentially they're bundled context properties. They're things managed by OSGI. So now we just don't have globals anymore.

We did things like... The URL stream handler factory, there can only be one of them in the entire JRE as this is something that's in the class libraries. You can only call a set once. And so obviously that's a problem. But we implemented this multiplexing technology that will go in there and basically hammer the existing one and them multiplex them over multiple frameworks.

So that if you have multiple, nested frameworks running, as you might in a server environment, they're all contending to set the URL stream handler factory. Everybody thinks they're the right ones to set that, right? They can all set that one and they'll all get their own view of the world because we went in and did this multiplexing stuff.

Riyad: Hmm. Very cool.

Jeff: So it's that kind of work. It's really very fundamental, almost... I won't say trivial, but very small tweaks that then open up and enable this whole different range of use case.

Riyad: Well, talking about different use cases, what kind of review process do bundles go through before they get added to Equinox.

Jeff: Well, Equinox is a sub-project of the overall, top-level Eclipse project. It has a mandate that really says it's to do... Work going on in Equinox is anything related to OSGI specifications, or in direct support of running OSGI based systems. So that sort of sets the bar, the context if you will, for what is an acceptable bundle to go into Equinox.

So if somebody came along and said, "Oh I've got this bundle that computes fast Fourier transforms. It's really cool." We would say, "Well that's great, but Equinox is a very specific area." That's the first level.

Somebody, for example, shows up and wants to contribute an implementation of some OSGI specification. There are many, many services specified by OSGI. And we have an implementation of many of them but certainly not all of them. So if somebody shows up and wants to give us an implementation of one that we haven't implemented yet, it's pretty much like any part of Eclipse and any open source community.

There's a set of reviews that people go through. We look at the code. The rest of the committer community assesses whether this is decent code. There are legal reviews that go on. And we also, frankly, look really hard at whether or not the people who are contributing the code are in for the long haul.

The sort of dump and run scenarios are just brutal, right? Because that takes a whole lot of time for us then to start maintaining this code and it's even worse if we start building a dependency on that code and then the original authors, through perhaps no fault of their own... But if they never had any intention of staying around, that's really unfortunate.

I'm not sure if that's what you were after. But that's really what we look for.

Riyad: In the 3.3 planning guide for Eclipse, there's a discussion of storage services for OSGI bundles. What's that about?

Jeff: Right. That's sort of recognizing that many of the services people have, things like permissions service, configuration admin, user admin, all those things, "they need to persist" things, they have information that they need to store. And rather that having everybody write their own storage manager basically, the idea here is that we would write it once and then use it everywhere.

Riyad: Like embed Derby, or something like that, and let...

Jeff: Well, I wouldn't want to go that far, but yes, that kind of idea. And, in fact, the value of doing this is that you now decouple the storage of the data from the data itself. Like what the data is, preferences for example. So now you can imagine scenarios where your preferences are stored on a server someplace, in a database, LDAP, take your pick.

And this becomes, I won't say easy, but certainly feasible if you have a separation of concerns in there. I think, even if we never did that, it would be a good code-cleanliness exercise to separate those out and have a separate storage service from the actual domain policies.

Riyad: Can you tell me a little bit about this JMX management feature that we've read about a little bit on the site?

Jeff: That's in the incubator. In the Equinox sub-project we have a number of work areas. Well we have components, sorry, I should say. And one of the components is the framework itself. And then there's a bundles component that is where we do all the service implementations and such. And then there's an incubator because there's lots of things, like the server side use of Eclipse and such, that are not fully formed. We need a place to work on them.

One of the things that we set out to do was look at running Eclipse systems. Because the serviceability is a big problem, people are having trouble. It's either slow or big or there's some error happening and they want somebody to be able to look at it. And they often want people to look at it remotely.

So obviously JMX is one of these things that comes to mind. And we wanted to get a better view, get an understanding of JMX and a basis of how to do service management. So we did bit of work to write a set of beans, JMX MBeans, to expose basic Eclipse notions like plug-in, or bundle, services, extensions, a resources model, preferences, that sort of stuff.

And, of course being the kind of guys we are, we wrote it in an extensible way so you could just drop in more plug-ins that contribute more bean factories and expose more concepts. In fact all the ones that we expose are contributed in exactly that fashion.

So right now it's very rudimentary. We're not UI guys, right? So we didn't get the UI designer out and start playing with it. So it's a fairly rudimentary UI that allows you to view a tree of beans, navigate through that and see the interrelationships. You can look at a bundle and the see what services that bundle is using, look at the service and see what bundles are using that service and who owns that service, etc. And then you can perform operations like a start and stop on the bundle, that sort of thing.

Riyad: What's the long-term goal for the JMX integration?

Jeff: That is a hot topic. There are several people who are in the sort of management domain. Several other projects within Eclipse, Corona and some other projects that are coming up, they're all very interested in management.

We're actually not that interested in big end management. We were just interested in being able to poke around in other guys systems to see what's going on so that we could help with serviceability.

Riyad: I see.

Jeff: But I sense that, coming in the next year or so, the stars are aligning somehow, the time has come for there to be a service, like a management platform or a management framework, a set of facilities around Eclipse. I think that's going to evolve. I wouldn't be able to say how it's going to evolve. But I think that's going to happen in the next year or so.

Riyad: So maybe even see the first semblance of it in Europa you're thinking?

Jeff: Could be. It's really hard to say. It depends, I think, on which projects are doing it and exactly what parts of it you're interested in. But the upcoming 3.3 plan for the Eclipse Platform, I'm certainly pushing to have some elements of that on there.

Riyad: Very interesting. It's going in every direction.

Jeff: Yeah, well we try to stay focused though. We're not just going willy-nilly. It's driven by particular problems, in this case being driven by things like serviceability, configuring and provisioning, those sorts of things. So these are real problems that people have in using Eclipse in an enterprise setting, whether it be as an IDE or as a Rich Client platform.

Riyad: Or soon to be app server or however else it gets deployed.

Jeff: Yeah, exactly.

Riyad: Well, we're getting close to the end of this podcast. Is there anything else you wanted to add before we sign off?

Jeff: No. I think I feel obligated to reiterate the point around platforms. And Eclipse as a platform for building platforms is the message that I like to get across when I talk to people about what Eclipse is. Everybody can use a platform. Everybody can build a platform.

And using Eclipse and writing a closed set of software is perfectly cool. You've gained by doing that. But you've not got the whole story. You've not gained the whole value add because the rest of your business, the rest of your domain could benefit from that.

We see that over and over again. You asked me before what the coolest things and I talked about the NASA guys. And similar things happen in neutron beam instrumentation, where they've got a whole platform now around managing neutron beam accelerators and stuff like that.

Riyad: Wow.

Jeff: It just makes sense right? Because you've got all these people who need the same stuff. And, again, you can get one set of guys to do the gorp and everybody else can just use the gorp. So building platforms on top of platforms is really the message.

Riyad: So the message is, Eclipse, we build gorp?

Jeff: We build good gorp though.

Riyad: Well Jeff, I want to thank you for taking the time. This was a long interview and you hung in there. We covered a lot of ground today. I appreciate your time with helping us learn all the ins and outs of the Eclipse RCP and platform in this case.

Jeff: Sure. Thanks very much for having me.

Riyad: Absolutely.

Jeff: It's been a lot of fun.

Riyad: We appreciate everyone tuning in and hope you enjoyed yourselves. This concludes Episode Nine of 10 in the EclipseZone Callisto Podcast Series.

[music]