Java, a Balanced Perspective

What engineering managers will not hear from their technical zealots

Engineering managers are used to having their young enthusiastic engineers promote technical innovations such as the Java programming language. In fact, managers rely on them to propel their companies into the future. However, engineering managers must separate what is probable from what is possible, mixing the result with budgets and reality and then molding what survives into the corporate vision as described by the CEO.

Java is different. Instead, CEOs are coming to engineering vice presidents with, "Everybody is talking about Java. What are we doing with it?"

Engineering managers are feeling the heat from above and below, yet they realize that a floundering Java project will still be their responsibility. So here is the other side of Java, the side engineering managers may not hear from engineers looking to surf the leading edge or from CEOs and marketing vice presidents responding to the hype equating Java to technical leadership.

Consider first that Java is interpreted code. This makes it portable across hardware platforms, somewhat like other languages before they are compiled and thus optimized for specific platforms. Interpreted code is slow. So even though Java pushes the envelope with just-in-time compilers and virtual machines, it produces applets because it is too slow to produce applications.

Using object technology to string together Java applets, Applix, Corel and Coopers & Peters delivered watered-down versions of their applications written in Java, possibly to show the world that it could be done and that they were Java experts. PC Magazine (May 27, 1997, page 115) tested these Java applications using a variety of Java virtual machines to report that 59 percent of its tests ended with "system locks or application errors that rendered the application nonfunctional".

This clearly could have been Java on its bad day, but the Webmasters Guild conducted a membership poll reported last January, reported in Web Developer Magazine (May/June 1997, page74) to learn that 66 percent of its members did not use Java on Web sites they designed. Excuses ranged from "too slow" to "no pressing need." Of the 34 percent using it, the majority indicated their Java applications were in the "bells and whistles" category.

Over time, Java should become more useful as the language of so-called middleware interface tools between the Web and the thousands of legacy software programs waiting to become Web-enabled, though you can read about a practical alternative in an article called "Connecting Legacy Software to the Web". Java was designed for Internet connectivity applications and such middleware code is rarely so large as to expose Java's leisurely speed.

Moving from server-side processing to client-side processing, Java provides the benefit of taking Web site visitors beyond the narrow transactional confines of their browsers. Along with Microsoft's ActiveX and Javascript in a limited capacity, Java is the only language with much of an ability to address this very real need. Java and ActiveX are also unique in that their entire development environments can be downloaded free from Sun (www.javasoft.com) and Microsoft (www.microsoft.com), respectively.

To balance the growing popularity of client-side Java and ActiveX, it is worth considering that client-side security is unproved. This can be merely annoying if a Java programmer doesn't suspend the execution of the applet when the Web browser calls the stop() function. It can go as far as the virus-like destruction of important files when the applet is executed by browsers that permit it, for example, Sun's own AppletViewer. Ironically, Java could become truly useful after all browsers allow it to write useful information from the Web server to the customer's hard drive.

We expect progress in addressing these problems as Java makes its entrance, particularly as Java's concept of a "operating in a sandbox" is better defined. But in the meantime, why take the chance of your Java/ActiveX applet being on the list of suspects when a customer's computer goes on the fritz?

By adding more functionality to ActiveX, thus trying to overtake Java by pleasing programmers, Microsoft also made it easier for programmers to do harm as well as good. Microsoft is taking steps to address the risk, but people like Fred McLain in Computer Reseller News (Sept. 16, 1996, page 71) and Web Week (Nov. 4, 1996, page 5) are showing how easily the system can be defeated. The liabilities involved in all this will probably be decided by the courts, but not for years and, one hopes, not with your company as a participant.

As though we needed confirmation of the security risk, Netscape's browser and all firewalls now provide ways to shut out Java, ActiveX and the downloading of all other executable code. See "MIS Managers Look to Firewalls to Shut Out Java" in Web Week (Aug. 19, 1996, page 37).

Given that most Java and ActiveX applets provide only animations and other esthetics more suitable for business-to-consumer Web sites, engineering managers should ask for value justification before signing up for the potential liability. If a stranger showed up in your lobby with a floppy diskette and asked the receptionist if it would be okay to load some software on your computers, would you allow it? Then why would you think nothing of a click on a Web page that downloads an executable program?

This is why DP managers are beginning to block Java and ActiveX (by just changing a setting on the browser), and Web designers who develop such client-side Java or ActiveX are learning that more and more of their visitors can't enjoy their creative genius.

So to foster that balanced approach to Java, it is only fair to point out that it is quickly becoming one of the most useful interpreted languages, as would almost any language with this many talented people working on it.

Beyond the hype, Java is a fully object-oriented language, unlike C++, and this appears to have substantial benefits in terms of development effort and maintainence. Java also has native support for multitasking, eliminates pointers (bugs waiting to happen), and substitutes the concept of native interfaces for multiple inheritance. This means that COM interfaces, for example, come almost free with Java, but there is also a lot of ugly grunt work involved in building C++ COM objects.

Your software engineers should therefore add Java to the rich tool set they command, but the focus should remain on the problem to solve rather than to make a fashion statement about the tools chosen to solve it.

To view past 'Weaving Your Web' columns

To view other columns

EE Times Info

Subscribe to EE Times

Contact our editors

EE Times Services

EE Times Online provides a number of helpful services for our readers and advertisers. The EE Times Network is a portfolio that includes an editorial calendar, a media kit and a list of trade shows and conferences.

is a vehicle to request information from vendors mentioned in recent EE Times print ads and articles.

Product Shopper

J.O.B.S. Online

Search Firm Directory

Media Kit

Marketplace

Reference Library

We've teamed up with Computer Literacy to provide easy access to more than 100,000 technical books that can be ordered right here online. Technology subjects range from artificial intelligence to microprocessors, Web servers to operating systems. Look for books that will be offered as adjuncts to subjects from our editorial calendar in the near future.

Please become a registered user of EDTN. It is free and will make it easier for you to receive the information you need. See the benefits of registration, or:

Register Now

Search EDTN and the Top 100 Electronics Sites