J2EE Doesn't Have to Be a Rip-and-Replace Proposition -- ADTmag

J2EE Doesn't Have to Be a Rip-and-Replace Proposition

By Stephen Swoyer
March 8, 2005

There may indeed be situations in which it makes sense to rip out a fully-functioning C or C++ application and replace it with its J2EE equivalent.

Given the option, however, most codejockeys would probably prefer to let sleeping applications lie, especially if the programs in question are based on fairly trouble-free code that mostly does what it's supposed to do.

Fact is, even in instances where there's ostensibly a good business case to be made for ripping-and-replacing existing application assets, a hybrid approach often makes more sense. Of course, selling company management on the wisdom of such an approach can be difficult.

Independent programming consultant Charles Martin offers the example of a major hardware vendor that implemented its entire e-business application stack in the form of C-based CGI applications.

In this case, Martin explains, fork()/exec() was driving up utilization on the company's Sun Starfire servers: Every time an application fielded a new request, it spawned another process. One upshot of this was that the company was buying a new Starfire box every few months.

Of course, the company could standardize on a far less resource-intensive J2EE solution powered by BEA's WebLogic application server, JSPs and Struts. After all, if the C code is well factored and tests well, it should be relatively easy to port to JSPs and Struts, Martin notes. Perhaps company management, mindful of the same thing, has even ordered such a migration.

Of course, if the C code is well factored and tests well, there's nothing necessarily wrong with it, notes independent programming consultant Jeff Grigg, so there's really no reason to eighty-six it in the first place, is there?

Instead of forcing a rewrite to a different language, Grigg suggests, the organization should instead focus on solving the business problem. In Grigg's view, the company could implement a hybrid approach in which Java programs call C and C++ programs via the Java Native Interface (JNI). This could be done by means of a multi-threaded Java servlet, which could call, via JNI, the bulk of the legacy C application code. This solution isn't perfect, Grigg concedes,--there'd have to be some translation between Java native streams and the particular streams the existing C code is using--but should work well enough.

"[It] saves lots of time and money. [It] can be done more quickly [and] is lower risk," he says. "[It] enables the business to put the remaining investment--that would be wasted by the rewrite--into additional valuable functionality."

Of course, selling such an approach can be difficult, particularly if there's a mandate from management to do it their way. But Grigg, like many accomplished coders, says that a little psychology can go a long way.

"My general approach, in the real world, is that if they ask for big-unnecessary-thing, X, when they really need j, I offer them j followed by X," he says. "Generally, once their business problem is solved by j, it's pretty easy to get them to give up on X; there's no longer any business justification for it."

Consider the case at hand, says Grigg. "The command from on high was to convert to JSPs and Struts. That's in my proposal. In practice, no one will seriously consider your proposal unless it covers all the 'hot buttons' dictated from on high," he explains, noting that the programming team can promise to deliver the requested architectural change "in a later release."

"In practice, we may never get to that release," he points out. "And by the time we would, the powers on high will probably be distracted by something else, and won't care much, one way or the other."

As for the business case for standardizing on WebLogic and J2EE, which could include a mandate to standardize on a single architecture, or a single programming core competency, Grigg says he isn't quite convinced. "If you want to make a big investment in rewriting the code so that you can fire your staff and hire a different staff, well that's a business decision," he says. "I'd like to see the ROI claims on that. It seems like a waste of time and money to me."