Java in the Enterprise: Java Helps Re-engineer Huge Legacy Systems

Print-friendly Version

Articles Index

"A year after rewriting a legacy application into what is probably the largest Java application in the world, its developers say that using Java was exactly the right strategy," says Greg Dennis, vice-president of architecture for Andersen Consulting and one of the architects of the Java-based VIA travel application.

"It involved rewriting 30,000-40,000 lines of C, and 10,000-20,000 lines of COBOL," says Dennis, who recently gave a frank talk to a San Francisco audience of about 350 people. "We also wrote a Java-based desktop application that had 15 windows, 200 images, and was 5MB in size. And it worked," he adds. The payoffs? A fast-learning curve, and very little in the way of programmer retraining costs, an extremely robust system, reduced maintenance costs, and quicker time to market than the company experienced with C and C++.

The application needed to handle all aspects of travel reservations and arrangements for travel agents worldwide, with a view toward possibly someday letting travelers themselves log in over the Web and make their own arrangements. This involved transaction processing, which in turn meant interfacing with legacy COBOL and Oracle database code. It also had to handle flight availability, reservations, variable ticket pricing, and travel profiles.

Teaching C programmers new tricks

The choice of Java brought many benefits. First, it was surprisingly easy to make the transition to Java, even though none of the programmers working on the project had ever used Java; most of them were C and C++ programmers. "It was definitely a risk at the beginning, because we knew that if we were six months late with the code, we probably wouldn't be in business," says Dennis.

Once the transition to Java had happened, programmers could cut new code or modify code much more quickly than they had been able to do in C and C++, which had been the group's standard programming languages for years. "In the first stage of development, we were about 15-20 percent lower than we had been in C," says Dennis. "In the second stage, we matched our old efficiency. Now, in the third stage, we're about 20 percent faster than we used to be," he adds.

"We were even able to map a lot of the C and C++ code onto Java in a fairly automatic process," Dennis says. "We had inexperienced offshore programmers in Manila, and a different, more experienced group in Minnesota, and the ones in Manila got a week of training in our conversion process, and they were able to handle the change to Java, while the other group handled the more difficult issues," says Dennis.

Robust code, less maintenance

"Java also resulted in much more robust code," the system's creators said, recounting that that one of the junior engineers plugged in a Java Server, installed it, and migrated part of the code in less than four days, and the system worked without a hitch for days.

"Our developers don't spend a lot of time debugging anymore, or wondering why threads aren't working, and we believe we're on our way to being a 7-by-24 shop," says Dennis.

But what about performance?

"Java is now fast enough," says Dennis. In almost all cases, Java was able to process calls in less than a second (using the latest JIT compiler), even when that meant handling millions of transactions. And in the main exception to this rule, Java still only took a few seconds to return a result, after the complicated pricing transaction was divied up into different parts and run in parallel on several servers. Dennis says that he expects use of the JDBC and RMI, which were not available when his group started working on VIA, to make the system even more fast and efficient. And, he emphasizes, "The portability of code is a big win."

The downside

Dennis did not, however, whitewash the difficulties that the project's workers experienced, which included the following:

• The lack of good, mature tools to help programmers working in Java. Although he expects the situation to improve steadily over the next few years, he says that when it comes to tools, Java programmers will probably be working at a disadvantage compared to their C and C++ counterparts, who have had mature tools to work with for years. In particular, the team spent a lot of time debugging memory leaks.

• Dynamic download remains a performance bottleneck.

• Interfacing with native, legacy code is still slow, although this situation will probably improve now that RMI is available for handling such code.

• Porting from C was not entirely automatic, and some C code, particularly that involved in memory management, had no Java equivalent, and had to be handled separately or taken out. On the positive side, however, he said that having Java handle threads and exceptions, easily and gracefully, saved some time.

• Java Server is still slower than some other technologies the team has used. "You'll especially notice it in CPU-intensive applications," says Dennis.

The future

On balance, though, how would Dennis sum up the experience? He ended his presentation on this note: "Although I wanted to communicate some of the issues and challenges that we've run into, I do want to give the impression that we've had a great experience with Java, and really believe Java has been a great benefit to us...We've built a big, complex, business system that does online transaction processing, and has the performance that we need, and our applications are more robust than our C counterparts."