In-Depth

Java: Brewed to perfection?

• By Deborah Melewski
• June 4, 2001

The Java programming language was born amidst a flurry of promises that included reduced development costs, platform independence and lower maintenance overhead. As with any new technology in its infancy, Java was put through its paces and scrutinized at every turn.

Were the last five years a case of Java jive? Not at all, according to those who have worked closely with the language. With some nurturing by parent Sun Microsystems, Java is widely used today and measures up well to its claims. Indications are that for moderate-sized applications, at least, Java has broken through some of the performance barriers it had to overcome. Advances in optimizing compilers are largely to thank, although experience gained architecting Java applications may be equally as important.

One of the leading criticisms to consistently plague Java is its performance. When stacked up against its most recent predecessors -- C++, for example -- Java was proclaimed to be very slow once deployed on the Internet.

Sun has acknowledged the importance of the performance issue and has, in fact, taken steps to help boost Java performance. "Customers have insatiable wants when it comes to performance," said Gina Centoni, director of Java platform product marketing at Sun. "They are constantly pushing the buttons on all of their systems, creating greater and greater dependencies and more complex systems. As a result, their performance requirements continue to increase," she added. "So performance is a space we continuously invest in."

Others are also hot on the Java Virtual Machine (JVM) performance trail. IBM has its own technology, Oracle has built the JVM into pieces of Oracle 8i, and Austin, Texas-based Tower Technology Corp. offers the TowerJ Java deployment environment.

In a move to further increase Java server-side performance, Sun has released HotSpot, its next-generation JVM. The HotSpot VM is accompanied by a compiler for server applications. According to Centoni, HotSpot for Servers has already provided significant performance increases.

In a significant move for Sun, Java 2 Standard Edition Version 1.3 will replace the classic JVM with the HotSpot VM as the default runtime. It will be available as the standard build during the first quarter of next year.

Centoni explained that there are significant differences between client and server performance issues. While Java and the JVM predominantly have roles on the server side, the client side has had its share of performance woes. Sun will also reach out to accelerate applications on the client early next year with the release of yet another new compiler.

"More recently most of the performance criticisms have been in the area of client performance," said Centoni. "For example, this involves how quickly your Java applications open, how quickly they refresh on screen, and how quickly you can download an applet into your application."

While the VM plays a key factor in Java performance, there are many other things to consider. "In the user's experience, Java plays only about 25% of the performance role, and that falls under the VM and Java runtime," said Centoni. "We take that role very seriously and we're constantly optimizing; we've made big investments there." >p> Ironically, the root of Java's performance problems may be the technology's most widely touted virtue: portability. Because Java is an interpreted language portable across so many different platforms, a virtual machine is required to convert Java bytecode into the zeros and ones of machine-level code for each specific piece of hardware and operating system encountered. [In fact, some developers advocate use of static, or non-interpreted, virtual machines that can draw out the best performance of an individual platform. Portland, Ore.-based Instantiations Inc., for example, offers the Jove tools suite, including a native optimizing compiler for Windows, to meet such needs.]

The HotSpot performance engine is said to speed execution of Java bytecode, which is particularly helpful in enterprise server environments that use multiple-processor platforms and multithreading.

However, the JVM cannot be Java's silver bullet. There are at least three factors remaining outside of the JVM's reach that can make or break Java performance. The first is the operating system and hardware platform the applications will run on. Obviously, a variety of platforms are found on the Internet. The problem? Some are bigger, better and faster than others.

Also factoring into Java performance is the use of native code libraries to perform certain GUI-related functions. Because these specific pieces of code run directly on the operating system, and not through the JVM, they have remained somewhat out of the realm of Java.

The third performance factor is application design and architecture. This area has improved substantially now that Java and those developing with the language have been around the block a few times. There are a number of ways to design (and not to design) a Java application that can help. There are also various ways to code and deploy that will help with the way an application performs. Often, these performance problems derive from communication back and forth over the network. Servlets, many say, are an appropriate technique to meet some of these issues. As well, problems can arise as a result of object-oriented programs in terms of object creation or collection.

According to Centoni, IT professionals making application decisions need to be acutely aware of these issues. It is important to take into consideration the bigger picture, including such things as how you have designed your application, and where you plan to deploy it.

Sun, third-party tools providers and those using the technology in development have been able to piece together, and oftentimes share, solutions and experiences that address some of these areas. There are many radically different approaches that can be taken. For example, if you are designing a plain vanilla form for data entry, Java is not going to be your best solution. HTML or eXtensible Markup Language (XML)-based solutions would be better choices.

Importance of good design

Michael Denley, vice president of software services at Rorke Data Inc., Eden Prairie, Minn., has strong feelings about the role design plays in Java performance. "We hear sometimes rightly but most times wrongly that Java is getting a rap for poor performance," said Denley. "We always respond, 'Not our Java.'"

Denley firmly believes that poor performance typically stems from the way the application was designed and developed. "We spend a lot of time in our design to make sure we use good object-oriented programming practices," he said, explaining that the Unified Modeling Language (UML) and tools from Rational Software have been implemented to support design.

Rorke Data is the maker of the 100% pure Java-certified FLEXSTOR.db data warehouse repository for digital content and asset management. Now in its fifth release, FLEXSTOR.db handles millions of pieces of information or business assets that include pictures, sounds and movies. These pieces are all indexed by the system and can be easily moved around on the Internet.

"It's a universal language that you can develop once and use across multiple platforms. If I did this in C++, I'd have variations for each of the platforms I supported because of different libraries and platform issues."

"All designs have limitations," said Joe Mullen, product manager at Rorke. "You need experience to know how to do things right; it's just like any other language in that respect. For example, if you code C wrong you're going to have memory leaks and crash -- and that's not good for performance, either.

"With Java, you have different issues such as garbage collection. But if you spend the time to do it right in the Java world then it performs very well," said Mullen, adding that testing tools for analyzing object leaks and performance bottlenecks in the code itself are also critical to the outcome.

Rorke Data does not use Sun's HotSpot technology, but instead takes advantage of virtual machines in the Oracle Application Server (OAS) and Oracle database for performance. The company takes advantage of the VM in the database by putting persistent JavaBeans in the database.

According to Mullen, Rorke is getting all the performance it requires from Oracle 8i. "From a performance standpoint, HotSpot would be more applicable to us on the server side, and we don't have any performance problems
inherent on what we're doing on the server."

In fact, the company has found its main performance problems to be associated with communications over the network. Because of the large amounts of content being moved, tasks such as bringing images in the database down to the client can be slow. Sometimes these issues are a result of slower modem speeds, but in many cases the problems can be minimized with the management and caching technologies provided by Oracle.

According to Vince Casarez, Oracle's vice president of tools marketing, performance issues need to be addressed in both the development and deployment of Java applications. "Oracle leverages Sun's Java 2 spec to be able to plug-in some areas we can speed up on the development side, such as garbage collection, memory management and so on," he explained.

Jeremy Burton, vice president of server marketing and Oracle technology networks, added that "on the server side in deployment, Java got a reputation for being slow because what people initially tried to do with Java was to build the same kind of user interfaces they had used in client/server.

"Sun has worked a lot over the last couple of years to improve performance on the client side," said Burton. "The HotSpot initiative helps as well, speeding the execution of bytecode so that user interfaces respond better and work more like Windows applications."

Burton has also found that the world has changed somewhat. "People are not trying to rebuild Windows client/server applications in Java; by and large, people are now using HTML for their user interface and then [running] all the Java code on the server," he said.

What Oracle may be touting is purely server-side Java. The company emphasizes scalability rather than flat-out performance because the bottleneck is usually the network when accessing information, not the raw execution of code on the server.

Another company that finds most performance hits stemming from the network itself is EH Sof-solutions, Omaha, Neb. Two years ago the firm chose VisualCafé from Cupertino, Calif.-based Symantec Corp. as its standard Java development environment.

EH Sofsolutions consults with and mentors companies embracing new technologies such as the Internet, e-commerce and Java. The firm is currently using Java and VisualCafé to develop a distributed decision support system (DSS) for a large company in the transportation industry.

People accessing the DSS are out in the field moving goods. The DSS tracks movement, equipment and personnel. Java's portability has particularly benefited this project because the transportation company has a wide mix of platforms, including NT, Novell, NCR, HP, Solaris, AIX and OS/390. The system accesses data on the mainframe, while the server side runs on HP boxes. Out in the field, the clients are mixed, but a majority are Windows NT-based.

The new DSS uses BEA's WebLogic Java Application Server and Tuxedo for transaction processing. Java's portability has also played a role in increasing server performance with its ability to spread the application out among all the servers to balance the load. "With the Java tools, there's a framework in place so we don't have to be concerned about what we're running on or where we're running. It's all handled for us," explained Curtis Palm, CEO at EH Sofsolutions.

Java performance has not been a major concern for the company. "Some of the biggest hits we've seen in performance are in the network itself, when moving information around," said Palm. "Java solves a lot of that with its ability to easily move objects around; for example, you can do number-crunching on the client box and then just send the object back.

"A lot of the performance bottlenecks I've personally witnessed have been in poorly architected systems," added Palm. "For example, where you see a lot of object creation or a lot of memory storage. Or when you're doing way too much with code in memory that's not actually being touched," he said. "These things can't be attributed to Java itself, rather to the architecture when someone didn't understand multithreading or object-oriented concepts [very] well."

EH Sofsolutions uses Symantec's JIT compiler. Palm notes that HotSpot technology "works well if you have applications that are doing a lot of things repetitively, because it becomes more efficient the more you use it." Palm was quick to point out that if there is a one-time load, you do not really benefit from the technology that much. "But if it is something in a 24x7 application, it tends to work very well," he added.

Palm also strongly recommends the use of testing and debugging tools to help ensure performance. He has found the Symantec tools to be very good in debugging code, and has also brought in additional code coverage and analysis tools, including JProbe from KL Group and DevPartner from Compuware/NuMega.

"As you're creating your code, also take a look to see if you can identify performance bottlenecks," suggests Palm. "These types of problems are usually about 20% of the code, but 80% of the work. If you can identify that and smooth out the rough edges, then you will be in much better shape as the project unfolds," he added.

"You can also use these tools to look at your code retroactively, to see where the big footprints are or why something is taking so long to load. Even if you can't go back and fix it, you'll learn from it for your next project," said Palm.

Palm concluded that performance all falls back on the architecture. "It's a new world; we must be very concerned about the distributed nature of it and what events you're triggering, where they're going and how they're playing out," he noted. "It's not like Visual Basic, where you can draw a few controls on a form, hook it up to a database and life is good."

Roadmap to experience

Concept Five Technologies, a McLean, Va.-based applications integrator, has a number of corporate-based frameworks with Java implementations, along with a number of Java-centric professional services engagements at Fortune 500 companies.

John Marsh, senior distributed project architect at Concept Five, started working with Java as a high-level designer even before Sun's official announcement of the language. He cites HotSpot as one of the technologies coming to speed up Java. "HotSpot does more tuning and looks harder at what's happening as it decides what's worth compiling," explained Marsh.

Marsh also points out that there are alternatives to HotSpot. "IBM has their own technology, and Oracle has built the JVM into front-end pieces of Oracle," he said. "There are also compilers that compile Java code to native object code on machines."

While this is a reasonable thing to do for server platforms, it obviously does not work for downloadable applets. But if you are building server systems, you can pick the best performance approach for a particular situation or platform. Marsh also suggests that there are system or Java profilers that can help tune systems, as well as help find the pieces of an application that run more slowly than others.

A real performance barrier on the Internet is the downloading of code, according to Marsh. "A lot of systems people have realized they didn't need that as much as they thought they did. When Java originally came out it offered a lot of things you couldn't do with standard HTML," said Marsh. "While Java is still much better for highly interactive systems, there are areas such as filling e-business forms that can be handled with 1K of an HTML file just as well as if 100K of Java code had been used."

User interface tools can help

While object-oriented programs can be an issue, Java performance woes ultimately come down to the interpretation situation, said Darren Cervantes, associate product manager at Boulder, Colo.-based Rogue Wave Software. "It's been a classic problem for the Java language. It's an interpreted language, and to whittle that down to a high-performance model has taken some time," he said.

Cervantes believes that the industry is just getting into improved performance with some of the new JVMs like HotSpot, TowerJ and IBM's new JVM. "Hopefully, with those JVMs we will see a large boost in the performance of the Java code as it is optimized at runtime instead of just interpreted as bytecode the way it has been," he said.

Another way to boost performance, said Cervantes, is to use thin-client applications. "A developer should pay attention to how much space the client side of an application is using," he said. "Developers can create a wonderful user interface, but the time it takes the user to download the UI and then use the particular component may take longer than it needs to depending on how well designed it is and whether it includes excess language."

Essentially, the thin client means the developer has taken pains to boil it down to the minimum necessary code. A lot of the functionality can then be put back on the server because that is traditionally a much more powerful machine.

To help create the thin client-side user interface, Rogue Wave Software offers StudioJ, a suite of Java-Beans components and classes. StudioJ provides developers with full libraries, and includes all source code and make files. StudioJ is also written in 100% Java and supports most Java IDEs

Performance positive

Bob Bickel, senior vice president of products at Mount Laurel, N.J.-based Bluestone Software, recognizes that Java is still a fairly new language and therefore has not been thoroughly optimized. However, he finds that the many positives -- such as Java's cross-platform capabilities -- far outweigh any of the negatives.

Bluestone offers the Sapphire/Web Application Server and the Bluestone XML Server. "On the Bluestone server-side Java code, we make zero changes when we move it from NT to Linux, to Solaris, to AS/400 to OS/390. We have a big application server that is very robust and has a lot of complexity to it," explained Bickel. "For us to be able to make zero code changes to do all those platforms is just mind-boggling to me."

Bluestone's application server is set such that the Java runtime environment is linearly scalable as well as fault tolerant, meaning that any number of application servers can be put together to handle the load of users coming into a Web site, for example.

Another performance plus in this environment, said Bickel, is that the plug can be pulled on any one of those servers and the users will not see any downtime. They will simply be rerouted to another server. "The Java instructions may be running a little bit slower, but the fact that you can just add computers to solve a performance problem in a way eliminates that issue," said Bickel.

Information Technology Resources (ITR), Buena Park, Calif., is an outsourcing company working with American Isuzu Motors based in Orange County, Calif. American Isuzu Motors supports a nationwide network of some 750 truck and SUV dealers with its Dealer Communications System (DCS) applications.

DCS is basically a series of programs and screens that allow dealers to communicate around the country with the manufacturer to order spare parts, report retail sales of vehicles and submit warranty claims. The system was running CICS COBOL and Objectstar applications on the mainframe.

"Our charge was to move that antiquated system up to state-of-the-art technology," said Jim Turner, ITR group manager. "We chose Java and Internet technologies to do that. Our new implementation is Java going to a Web server that's physically running on the mainframe in our data center. The Java links directly to CICS COBOL," he explained.

"We chose to go with Java based on development time, and the fact that IBM was touting a product suite that included a Java IDE, the Web server and the Java gateway that would allow legacy-to-Web applications," said Turner.

"The alternative would have been an architecture with a big NT database in the middle. We would have had to write code to go from the PCs at the dealerships to the database and the mainframe, and back," he explained. "This was an extra overhead layer we didn't want to deal with."

With the new architecture, dealers use a dial-up 800-number. They download Web pages in Java applets, which are, in essence, application screens. Some of the dealers have older PCs and modems, which means slower connect speeds. Turner noted that "anything we can do to reduce the size of what's going across the pipe enhances performance."

For Turner, Java performance can be a concern, but he stressed that it depends a lot on the platform it is put on. To address performance, the company is using Sun's JVM, which Turner has found to be slower than some of the others out there. "We chose Sun because of its pure support of the Java development environment and runtime," he noted.

"The problem we had with performance on our system was due more to the loading of applets off of our Web page for people coming in from dial-up," said Turner. "We're going to move to servlets. The application has two sections; the piece on the PC that runs applets runs just fine. The applets download time from the server, however, is significant."

For tools, ITR uses IBM VisualAge Java, Lotus Domino Go Web Server on the mainframe, and IBM's WebSphere. From Phoenix-based UniKix Technologies, ITR brought in 3270 ScreenBean, a JavaBean that provides direct access to legacy mainframe 3270 applications; and PathFinder, which automates navigation through legacy 3270 applications and identifies data fields to be shared with other applications.

Turner has also looked at Sun's HotSpot technology, and is hoping that it may help to speed up some of the servlets on the host. ITR has not yet implemented HotSpot, because at the moment, according to Turner, the company is heavily focused on trying to get all of the new applications out.

According to David Matthews, vice president of marketing at UniKix, Java started out very much as a client language. "We were seeing a lot of the same performance issues in client/server. By and large, a lot people are aware of those issues now, and we're seeing interest in switching to the server side," he said.

In addition to seeing improvement in JVM and compiler technology, Barry Tait, sales engineer at UniKix, noted that there are performance gains in moving to servlet technology.

"In the past, there were some problems due to download times, particularly in downloading applets," said Tait. "Thirty seconds to a minute to download is far too long. We've found that with servlets, once they are cached in memory, subsequent access becomes faster."

Matthews believes that Java on the server side will be the next enterprise language, replacing COBOL over time. "Java is where the bulk of new apps will be written," he said. "We have to bring our systems software architecture into a full Java environment and that's what we're in the middle of doing right now."

With all the benefits of Java, is performance truly an issue these days? Concept Five's Marsh believes that it is getting to the point where performance is certainly not a deterrent to a large percentage of applications. For real high-volume software or real-time systems, however, he believes it will still be a barrier.