CodeGear, a division of Borland, recently announced JBuilder 2007, a Java IDE built on Eclipse. InfoQ sat down with Joe McGlynn, product manager at CodeGear to talk about the new release and and transition to an Eclipse based product.
McGlynn talked about the decision to move to Eclipse and the benefits it will bring.
We've moved to building JBuilder on the Eclipse core for several reasons. We believe that this is the right move for JBuilder users, and ultimately for Eclipse users. As the Primetime platform matured it had grown to the point where there were competitive pressures between Eclipse and JBuilder feature sets. This doesn't serve our customers -- they need powerful, innovative tools. By leveraging Eclipse and partnering with some of the OSS teams we've been able to deliver some great new capabilities that will enable our customer to cut their development time and risk considerably.
The versatility of the Eclipse platform and the abundance of pluggable tools make this a good tool to build from. As we add the JBuilder productivity capabilities we will be able to do some amazing things with the platform. Since Eclipse delivers the core features we were also able to address higher order problems. Our ProjectAssist/TeamInsight platform is an excellent example of that.
We are eager to contribute to the OSS community, and as our product roadmaps develop we will be taking the steps to make that happen.
Asked about how they intended to differentiate themselves when Eclipse is free and MyEclipse has a lead in the "enhanced" Eclipse market, McGlynn answered:
One of the ground rules when we began development was to be respectful of the Eclipse model, and not to build features that compete with or conflict with what Eclipse provides. For example, it would have been trivial to take the existing JBuilder EJB designer and host it on top of Eclipse. That puts us in the position of trying to be 6 months ahead of or 10% better than Eclipse - something that doesn't provide the best value to our customers. Instead, we developed a new Graphical EJB workbench that is a natural extension of the WTP platform. If a user if familiar with the WTP build and deployment model, JBuilder fits naturally into their workflow. As tools are introduced that leverage WTP, everyone benefits. In many areas of JBuilder 2008 it is difficult to tell where Eclipse stops and JBuilder starts -- that is by design.
Next the conversation moved to the transition process and McGlynn described the biggest challenge:
Our key challenge was making JBuilder a seamless extension of Eclipse. We didn't want to build an overlay and we didn't want to build a bolt-on. It was critical to us that our components blend very naturally with Eclipse.
McGlynn described the reaction from the Eclipse community.
The Eclipse folks we've worked with have been great. JBuilder is not about being an alternative to Eclipse in terms of competition, we want to extend it and make it a more power platform through contributions, and to produce a highly productive development tool for our customers.
McGlynn was asked if they were able to leverage any of the existing JBuilder codebase in the transition?
We've re-used almost none of the previous JBuilder code base. We didn't want to try to adapt things to work with Eclipse, we wanted to architect them from the ground up to be first-class Eclipse tools. We did some experimentation with this, layering our code management tools on top of Eclipse, and hosting parts of JBuilder using the SWT/AWT bridge. It worked OK, but it wasn't the right way to deliver the capabilities we wanted to develop.
We are using the Java LiveSource engine, which gives us the ability to provide additional visualizations of Java source code -- this technology was ported to Eclipse a while back by the Together team. We've developed all-new EJB and Web Services designers based on the LiveSource engine, so you have live two-way visualizations of your code. You can create your applications graphically (drawing the picture just writes the code.) If you have the code you automatically have the picture.
We also have full UML 1.4 and 2.0 modeling for Java based on the LiveSource mechanism introduced by Together. This, coupled with our advanced audits and metrics, provide a powerful toolset for code archeology. You can quickly grok complex applications, localize problems and surgically correct them.
OptimizeIt has also been completely rebuilt on top of TPTP.
On keeping up to date with new versions of Eclipse:
Our experience is that it is pretty painless. We're tracking Eclipse projects closely, and constantly developing against milestone builds. This is due, in no small part, to our early decision to extend and compliment Eclipse rather than build competitive features.
Lastly, the conversation covered the learning curve for the team on Eclipse.
This actually happened more quickly than we anticipated. Keep in mind that we have a team of developers that has lived and breathed JBuilder on Primetime for 10 years. Eclipse is different, SWT is different, the Plug-In architecture is different. The team was productive from the very beginning.