An Interview with CodeGear's Jeff Anders

Building on examples or some reference code is a frequent developer practice. However, few IDEs curently support such a working style. In this JavaOne 2008 interview with Artima, CodeGear marketing director Jeff Anders explains Application Factories, a novel approach implemented in JBuilder 2008 that makes it easy to build an application by modifying a common reference code base:

A common approach developers take [to application development] is that they look at examples, what we would call template applications, as a starting point. If they know someone else in their organization, or in the open-source community, that has created something that looks similar to what they're trying to create, they'll frequently go and look at that as a starting point.

They may make a determination that, in fact, an existing application is not sufficient for what they're trying to do. In a lot of cases, though, they'll find that at least parts of it are usable, and is something they want to leverage. That is a very common starting point for many applications.

That's also a common starting point within organizations. As developers feel the pressure to do things faster and to get solutions to market quicker, the need to re-use pieces of code, or even whole applications, within an organization, are going to become greater.

In many enterprise application areas we see the need for this sort of reuse. In fact, the desire for this to happen is increasing. What typically happens is that a developer will sit down and pick up a piece of code or a module from somewhere—whether that'd be from within an organization, or from the open-source community—and they'll study it, they'll look at it, and they'll figure out how they can use that in a larger application they're trying to build.

If I'm building an e-commerce application, and I know that someone else has built a really good payment processing system that integrates with PayPal, for instance, I might want to leverage that. I don't need to go and re-invent how to integrate with PayPal all over again, but I do need to go through the learning process of figuring out how I integrate that module into my application. Once I've gone through that learning and built the solution, that's great: As a developer, I have leveraged what someone else has done.

At that point, the question is, How does anyone else in my team now leverage what I've learned about that?

That's what application factories help us address. As I'm learning about the modules, the code, other pieces of applications that I may be using, I can use things like custom tagging, scripting, and other capabilities that application factories provide to leave behind my knowledge, or "bread crumbs" in the sense of telling what I learned in order to integrate that module into my application.

When someone else comes around six months later, and they want to integrate with a different payment processor, they don't have to go through those days and weeks to re-learn all that. With application factories, they can just pick up my script, because the scripts were created such that they help them integrate the payment component as well. The person that integrated with the first payment processing system has made it easier for someone else now to integrate another one.

One of the big values of application factories is that knowledge—the learning and the experience the developer goes through the first time—can be retained within the project, and within the IDE, so that the IDE now becomes more useful to me. The IDE becomes more of a facilitator, and less of just being a plain Java tool.

A difference between what we do with scripts and what you might do with putting documentation and comments into the source code, or documenting the code through some JavaDoc or a UML model, is that those methods tend to be very static. If I put comments in the code, someone still has to go and read the comments and figure out what I meant by that and what action they need to take. Even if I document how to integrate something, another developer still has to figure out the action to do it.

With the scripting provided by application factories, the IDE uses the scripts. An IDE using application factories can create a script that says, "This file needs to be modified in order to touch these bits, and that file has to be changed in this way to incorporate this feature or that feature." So the script becomes an active part of the development, an active part of the creation of the application and, in fact, is used by the IDE itself. The script used by the IDE helps me as a developer make the modifications that someone else has already learned how to do. That's a difference from just regular documentation. It's a very active environment versus a passive environment of documentation.

To give you an example, suppose you have a Web application and wanted to change the stylesheet of that application. You would typically have to go in and figure out all the places where this stylesheet is used, which modules use it, how it is used. Through some tools within the IDE, you would figure that out, and then start opening up files and make the changes.

With scripting, when you create the application the first time, you create the script that records the fact that you need to go into these modules and make this change, and then you need to go into that source file and make that change. In that way, you capture the places across the application where that style sheet has some relevance.

When you come back to modify the application, you just run the script that had captured all those places. All you really need to do then is to point the script to the new style sheet, maybe provide some additional pieces of information to the script, and the script then goes out and changes all those files. You can watch what's being changed so that you can learn what the initial developer went through.

What do you think of Application Factories?

Resources

CodeGear's JBuilder 2008:
http://www.codegear.com/products/jbuilder

Talk back!

Have an opinion? Readers have already posted 1 comment about this article. Why not add yours?

About the author

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.