Tim Anderson's ITWriting

Oracle's Java tools strategy: an interview with Ted Farrell


Want to reproduce this article?

If you would like to reproduce this article in your own publication or web site, please contact Tim Anderson .

Oracle's JDeveloper

Part two of an interview with Ted Farrell, Architect and Director, Application Development Tools Division, Oracle Corporation. Parts of this interview have appeared in Application Development Advisor. Interviewing Ted is Tim Anderson and David Norfolk. To jump back to part 1, click here.

JDeveloper, Eclipse and third-parties

Tim: What is Oracle’s relationship with the Eclipse project?

Ted: Oracle used to be on the Eclipse board of stewards. Now that Eclipse is its own entity, it has a board of directors that we’re not on. We’re still participating as an add-in provider, but the cost to be on the board of directors is pretty large and it didn’t match our strategy. Eclipse today is a base Java IDE, and a pretty popular one, it has a lot of cool features.

In the next version of JDeveloper we have pretty much all those features that you find in Eclipse or IntelliJ. We’ve focused back on the core developer, whereas in the 10g release the main focus was getting ADF integrated, and to target the high level business developer. We’re now shifting resources back onto the core developer as well. So there are two paths that we take, the ADF enhanced mode, and the pure “just give me an IDE” type of developer.

That’s where Eclipse stops today. They don’t have a Framework, they don’t really have any productivity tools. The real big differentiator is that anyone, including IBM, who plugs add-ons into Eclipse, are really coming from different groups. Even though you do have a lot of functionality from the base Eclipse Framework, it’s still very jarring in a lot of cases. A JSP editor might be made by a third-party company, a Struts editor made by IBM, then the core EJB editor that is also IBM. If you bring out Eclipse and turn on those extensions and try to use them, it’s not a smooth clear transition.

When you’re in JDeveloper it’s all the same concepts, all the same data. It’s a coordinated integration as opposed to just technical integration. That on top of the Framework as well.

Tim: Is JDeveloper well supported by third parties?

Ted: JDeveloper is built of a base pure Java tools framework similar to NetBeans and Eclipse, and we have a good set of partners. If you go on OTN [Oracle Technial Network] you’ll see there’s over 50 extensions for JDeveloper. We don’t spend a lot of time toting that the way Eclipse did. When Eclipse first came out IBM spent a lot of money seeding universities to get people to build extensions. The total number of extensions can be misleading because if the extension isn’t really useful who cares?

Tim: With the 3rd Party JDeveloper extensions, how do you avoid the same consistency problems that you’ve described in Eclipse?

Ted: We have a set of guidelines that we came up with internally that we are now publishing to our partners. You’ll have the same information that we have when you’re writing your plug-in. We can enforce that in some cases in code, but in general it is up to them. What we do is the same thing we do internally, which is to specify things like “this is how the property inspector’s supposed to work”, “this is the behaviour of a double-click, or a drag”.

We also define our data objects. We have a lot of different types of data in the tool, and we’re very good at describing what they are and allowing other people to extend and use those.

ADF helps here. ADF has a concept called the ADF model, which is the core piece of ADF. If you want to try ADF, you can just grab the ADF model layer. What that will give you is some really cool declarative data binding. So it will allow you to actually bind any back-end data source whether it’s a web service, EJB, Java class, legacy adapter, and bind that into any web page, JSP page, Javaserver Faces page, or Struts controller. We’re getting more and more customers interested in building to this set of APIs. That particular set of APIs we submitted last year to the Java Community Process as JSR 227, we want to get more people writing to that. That’s the centre keypin of the architecture. So if you write to those APIs on either side, you are really tightly integrated in, you get a lot of things in the tools.

Tim: Do you enforce standards on the plug-in vendors?

Ted: Not on anyone who builds and extension and posts it on the Web, but for our partners we do. Anyone who wants to make a strategic arrangement [with Oracle] or have a plug-in that we endorse, has to go through the same checklist and sanity check by the UI group here, that our stuff has to.

Tim: Is JDeveloper simply a support tool for your database server and application server, or does Oracle have ambitions in the IDE market in itself?

Ted: We don’t make anything on tools. That’s not a strategic thing. We do think tools are very strategic to selling the platform. Some of the stuff that we’ve shown, ADF, JDeveloper, and the productivity gains that customers can get over a straight IDE have helped us hugely in sales accounts on the runtimes. That’s where the strategy goes. But our goal is to be the number one IDE in the market, because if we do that, we’ve succeeded at building a tool that makes sense for people. That’s going to draw people in and sell more runtimes. Even if it doesn’t, this is the advantage of the standards. You can build something for your own needs, but it can be used for other things because we’re all committed to the standards.

Click here for part 3 of this interview

Copyright ©2004 Tim Anderson