In-Depth

Will Java kill cross-platform development tools?

• By Neil Ward-Dutton
• July 31, 2001

Sun's ubiquitous Java is a strong candidate to become one of the holy grails of computing -- a universal implementation language. The still immature software is held back by several shortcomings, but it is likely these will be overcome sooner rather than later. If so, the low-end development tool market could change radically.

Will Java eliminate the need for today's cross-platform development tools?

Application Development Trends, August, 1996, declared: "Java provides the nirvana of cross-platform development and will continue to do so for some time." If true, won't Java soon crush today's cross-platform development vendors?

The fact is, an awful lot of experts are touting Java as a significant force shaping a new application development market. Java has come along so quickly, perplexed developers are asking: What is Java?; Where did it come from?; How did it get to this exalted position?; And what influence will it have on the future of computing?

First, Java is an interpreted object-oriented (OO) language. The syntax is a bit like C++, but simpler and truly OO -- you cannot write procedural code in Java. Java has a number of attractive architectural elements over and above C++ -- support for creation and management of threads, automatic garbage collection and dynamic code linking to name three.

Java code is compiled to bytecodes, which is interpreted by a "virtual machine" at runtime. In theory, this enables machine-dependent aspects of a program to be held within the virtual machine, separate from the main body of code written by an end-user programmer. Whenever a program needs to access a native system function, it calls a machine-independent function in the virtual machine which translates the request accordingly. This last fact alone is nothing new: Smalltalk is an interpreted OO language that has run inside a virtual machine since the late 1970s.

Originally designed for use controlling consumer electronics devices such as Personal Digital Assistants (PDA), and christened "Oak," the Java project was finished much earlier than expected -- before, in fact, the target PDA market was ready. Sun looked around for another market in need of the Oak technology and decided that an environment of heterogeneous networks (the Internet) had the same intrinsic complexities and constraints as embedded systems. In the embedded systems market, heterogeneity evolves with time and new devices supersede old ones, but heterogeneity within the Internet comes about between individual computing nodes.

Java's meteoric rise has been founded on some fortuitous timing. Interest in the World-Wide Web was fever-pitch at the time of Java's announcement, when some analysts were wondering what, in fact, this Web thing could be any good for in its raw, static form.

Java's position has been further strengthened by a number of factors, including the following:

• Early on, Sun made the Java specifications, source code and executables available, without charge, on its Web site;

• Java is close in syntax to C++, so many developers have been able to cross-train with little difficulty; and

• Java has become a central pillar in the temple of the anti-Microsoft lobby; the Internet development market is particularly vociferous by virtue of its heritage as the antithesis of corporate culture.

In the inevitable backlash which follows such a tidal wave of hype, numerous criticisms have been leveled against Java. These criticisms include:

• The language is not compiled, so performance is poor compared to C/C++;

• Security is too tight, so there is a limit on the useful things you can do;

• There are few development tools to help developers; and

• There is little available third-party support in the way of libraries and APIs.

The Java counter-argument includes:

• Just-in-time compilers and faster Java Virtual Machine implementations are being developed;

• Many security features are not actually part of the Java language itself, but are restrictions placed on the Applet class by the "security managers" built into Web browsers. Moreover, tight security can be seen as a benefit, depending on your respective point of view;

• New Java development tools are now coming out almost weekly; and

• Third-party support, though still weak, is improving rapidly.

Though great strides have been made in Java's short lifetime, significant work still needs to be done by third parties to enable Java proponents to make convincing arguments for world domination.

The second counter-argument brings out an interesting market feature. It seems there are two marketing targets in the campaign to win over Internet technology buyers. One is developers, who vendors believe will be put off by implementation restrictions. Programmers like to get their hands dirty and make the operating system do cool things, so the thinking goes. The other target is I/S managers, who probably see the stringent security mechanisms as a boon. This is illustrated by the recent slew of stories about companies effecting "no-download" policies. Imagine the situation if Java applets had no inherent security mechanisms.

So whom are the vendors targeting? Geeky developers or worried I/S managers? Microsoft, following form, is targeting developers. That is where Microsoft has found success in the past -- and the developers' market represents Bill Gates' spiritual home. Wisely, Microsoft has covered all bases with the release of J++, a Java development environment based on the popular Visual C++ Application Development Environment.

Cynical observers might view this as a plot to spoil Java. Microsoft's ActiveX is a core part of the company's strategy, and though it is not directly comparable to Java, ActiveX components are complementary to Java applets. The smart move here is C++ provides mechanisms to tie ActiveX components to Java programs, bringing the two technologies closer together and blurring any differentiators.

A cross-platform tool must, by definition, build cross-platform applications -- applications that can address multiple platforms. Such a tool has to embody the concept of portability. Ideally, that means being able to take all the code from an application, and implement the code for a different target configuration without changing anything.

In the context of cross-platform tools, a "target configuration" is made up of three elements: operating system, user interface and DBMS.

Fig. 1: Heterogeneous environments This application references user interfaces, operating environments and databases. Different operating environments have different APIs and different capabilities, so a lot of code will have to be duplicated and tuned. Source: Ovum Inc.

To enable portability between configurations, tools provide a services layer that hides the complexity of the implementation environment from the developer. This layer has traditionally been the domain of the 4GL. (See Fig. 1 and Fig. 2.) The services layer exposes a set of implementation-independent functions to the application developer, and translates function calls from the application to native system calls. Hiding these functions from application developers can enhance productivity and provide portability so a single learning curve can suffice for all environments, and a single specification can suffice for all implementations.

Fig. 2: Intermediate services layer This application addresses an intermediate services layer. Employing a services layer does away with the high degree of complexity that will arise from attempting to address multiple heterogeneous environments. Source: Ovum Inc.

Some cross-platform tools are close to the ideal. NatStar, from Nat Systems, McLean, Va., for example, supports Macintosh System 7, Windows 3.1, Windows 95 and Windows NT, OS/2, OS/400, OpenVMS, MVS, and five popular flavors of Unix; native user interface conventions for each of these operating systems; and native access to the DB2, Oracle, Sybase, Informix, CA-Ingres, SQLServer, RdB relational database management systems (DBMSs) and other ODBC-compliant DBMSs. Code can be ported from any viable configuration of these to any other configuration, without any changes whatsoever.

Java has the potential to match up to these formidable portability targets. (See Table 1 and Table 2.) The extraction of implementation-specific details from an application specification also omits an entire class of maintenance worries. But a larger class of worries remains: keeping pace with business changes. This can be addressed by repeating the same trick.

When analyzing the structure of a database application, it soon becomes clear that there are, in fact, a number of distinct concerns that get addressed. Broadly speaking, these concerns can be split into three types:

• Interacting with databases;
• Applying "business rules" to determine application behavior; and
• Presenting data to application users.

Would it not be great if a tool enabled developers to address these different concerns separately, rather than in a mass of "spaghetti code"? Not only would applications be quicker to create, but maintenance would be a lot simpler. The effect would be to make application maintenance more manageable and its results more predictable. As a side effect, creating new applications would become quick and easy.

PowerBuilder, from the Concord, Mass.-based Powersoft unit of Sybase Inc., Emeryville, Calif., is a better-known cross-platform tool than Nat Systems' NatStar. PowerBuilder supports Windows 3.1, 95 and NT, Unix and Macintosh, and can access Oracle, Sybase, Informix, SQLServer and other ODBC-compliant databases.

A comparative evaluation of NatStar and PowerBuilder by Ovum, a London research and consulting firm with U.S. operations based in Burlington, Mass., using such a layered reference model has yielded some interesting results. While both tools support a range of target configurations, the ease with which business changes can be incorporated into applications built with NatStar, and those built with PowerBuilder, is vastly different. NatStar's architecture supports a strong separation of concerns, which fosters both rapid development and rapid enhancement. NatStar is a model-based tool, which holds an entire application specification in an active repository. Any application behavior not specified in the graphical models you build of data and processes, is defined in a "proprietary" 4GL. PowerBuilder provides little separation of concerns: application developers will tend to write application code in event handlers behind screen widgets. Most of the application is hand-coded in the PowerScript 4GL, and many of the productivity aids are aimed at painting screens quickly.

Given the differences between NatStar and PowerBuilder, application development tools available today can be segmented into three types:

1. GUI builders that just target one operating system/UI configuration, and maybe a small set of DBMSs;

2. Cross-platform GUI builders that support a range of operating systems, UI and DBMSs, but do not help you build adaptable applications; and

3. Cross-platform tools that produce applications that are adaptable in the face of business changes, as well as portable.

Visual Basic falls firmly into the first camp, PowerBuilder into the second and USoft Developer from USoft, Brisbane, Calif., Passport from Passport Corp., Ronkonkoma, N.Y. and NatStar into the third.

Being a language and not a development tool, Java does not really fit in any of the above categories. Nonetheless, the features it provides, and the existing and planned support from third-parties, would seem to place it in the second category. Any adaptability built into a Java application by a set of developers using the standard Java Developer's Kit (JDK) is purely by virtue of the experience and professionalism of the developers. The Java development tool market is just beginning to flower, but most of the offerings only provide "RAD" (rapid screen painting) functionality.

Predictions

Being a 3GL, Java is susceptible to "spaghetti code" problems. Its OO nature allows developers to encapsulate different concerns in different classes, and the language design removes a lot of the nasty stuff that C++ programmers have to contend with -- but housekeeping code will still tend to be mixed in with code that defines true application behavior.

Java is in the running to be a universal implementation language. Presently, a number of shortcomings exist in Java, but there is a good chance they will be overcome soon. Given that, the differentiation between many low-end development tools begins to disappear.

It is easy to see how vendors of tools in the second camp might be a bit nervous. But, while Java's performance and third-party support remains an issue, it is unlikely that tools in the first camp will be seriously threatened: many of these (like Visual C++) are based around fast 3GLs. One notable exception here is Visual Basic, and the potential dangers to its market are left as an exercise for the reader.

The third camp will not be significantly affected by Java. In fact, the architecture of such tools lends itself well to augmentation to include generation of Java code: many high-end tools can already translate their proprietary 4GL into different flavors of 3GL code optimized for multiple platforms.

Vendors of these tools have spent a lot of time, energy and money over the past five to 10 years developing sophisticated systems which enable adaptable applications to be built. Those vendors will add Java generation functionality to their tools. It is unlikely that a new vendor will build a model-based tool from the ground up, specifically aimed at generating Java code.

Ovum's model of adaptability

Ovum has developed a reference model which forms the basis for its evaluations of 4GLs and client-server development tools. The model is split into six layers, with each layer addressing a distinct concern. The bottom two layers of the model cover support for specifying a logical, normalized representation of data the application will address. The third encapsulates "business rules," which are bound to the logical data model.

Specifying business rules directly against the information model has two benefits: first, because the model is normalized, the rules are normalized; and second, each time the "front end" of the application attempts to read or write data, it has to go through the business rules. So, the architecture enables developers to write a rule once, and have it automatically inherited wherever it is relevant.

The top three layers of the reference model address the "application" -- the way the data and rules are actually presented to the user, and the definitions of application flow. The bottom layer of the three covers definition of views on the data model, but explicitly excludes definition of how the views should be presented. The middle layer specifies ways of merging views to create applications, and allows a twist: specification of multiple user roles, so that different views can be wired together in different ways. The top layer covers presentation details.

Source: Ovum Inc.

Source: Ovum Inc.