Industry Trends: How Important Is Java?

Industry Trends: How Important Is Java?

by Dave Harms

Published 1999-09-21 Printer-friendly version

Clarion Magazine recently surveyed readers on the technologies they considered most important. High on the list were component technologies such as ActiveX and COM/DCOM, with a somewhat smaller percentage of readers showing interest in Java and JavaBeans. Java does come up for discussion occasionally in the Topspeed newsgroups, but on the whole I think it's a technology that's underrated by Clarion developers.

When Sun Microsystems introduced the Java language in November of 1995, it was with hopes that this new object-oriented language would revolutionize the programming, internet, and network computing worlds. The product was hot; the hype was massive.

It's fair to say that Java 1.0 didn't quite fulfill its promise, although it's hard to imagine any first version of a product living up to such optimistic press releases. But while the media frenzy waned, development continued. Over time Java (now in release 2) has gained a solid foothold in software development, though not in quite the way many pundits once predicted.

What does all of this mean to Clarion programmers? It means that Java is now one of the premier software development technologies (it's really much more than just a language, as the Java specification includes the runtime environment and a growing number of APIs). As such Java bears watching as much as Inprise's Delphi or any of Microsoft's stable of development products.

A Taste Of Java

My own interest in Java dates to 1995 when I began co-authoring the book "Web Site Programming with Java", published in 1996 by McGraw-Hill. (No, don't run out and buy it. This book is now quite dated.) I became involved in that project by virtue of having co-written "Developing Clarion For Windows Applications" with Ross Santos (SAMS, 1994), and definitely not because I had any special technical qualifications as a Java expert. That responsibility fell to my co-authors, both of whom worked for Sun. Writing and researching that book was an intense learning experience and my first significant involvement with an object-oriented (OO) language.

I found a lot to like in Java; for the first time OOP really made a lot of sense to me. And I'm convinced that if Clarion hadn't gone OO about the same time, I'd have long since left Clarion for Java. Happily, that wasn't necessary.

In many ways Java reminds me of Clarion, and vice versa. Both are powerful languages that put an emphasis on ease of use. Both are quite readable. Neither supports the use of pointers (well, Clarion sort of does), and both do a certain amount of automatic memory management, two key features that make a programmer's job much easier. There are many differences as well, of course. Java has a decidedly C-like syntax, is case-sensitive, and is designed from the ground up to be multi-threading, among others. As well Java is a "pure" OO language whereas Clarion mixes procedural and OO code. On the whole, however, I would classify Java as a high-productivity 3GL like the Clarion language (and here I mean just the language, not the Dictionary Editor and Application Generator and all that other good stuff).

It's Not What You Think

It's both fortunate and unfortunate that Sun launched Java as an internet development tool. The up side is that this gave the language unprecedented exposure. I recall seeing a number of prime-time news stories about Java during those early days. I mean news stories about a computer language! It was astonishing.

The down side is that Java is ingrained in the public consciousness as an internet-related product. This is almost entirely misleading.

Java Is Not JavaScript

The most discouraging result of Java's early hype is that many people equate Java with JavaScript. The SAMS book "Teach Yourself Java 2 Platform In 21 Days" sums up the relationship between these two products succinctly: "They have the same first four letters."

JavaScript was originally called LiveScript, and was created as a web page scripting language by Netscape. When Sun and Netscape entered into a marketing agreement which renamed LiveScript to JavaScript there was a lot of hand wringing among Java developers who (quite rightly) feared that Java would be tainted by association. Every time JavaScript fails on a web page it's the word Java that leaps out at the viewer. Which leads me to my second point.

Java Isn't Just Applets

Java isn't really a client-side technology. It can be used as a client-side technology, and again the early hype about Java was all about applets, little bundles of Java code that you could download and run on your web browser. But that's just a small part of what Java does.

Applets haven't proliferated quite the way most of us expected they would. Quite a few sites do use them, but in general internet bandwidth still isn't up to the task. This is one of the difficulties facing Clarion Web Edition, which uses Java applets to deliver Clarion screens to the browser. In some situations the Java applet solution is just too slow. And in any case, applets are really just a small part of the Java picture.

If you're like most people, almost everything you know about Java is wrong.

What's It Good For?

If Java isn't JavaScript, and applets aren't all that useful, then what's left? Quite a lot, as it turns out, both for web-related and "traditional" software development.

On the web front, Java is used increasingly for server-side development. Instead of applets, think of servlets, little bundles of Java code designed to run on the server. This shift began not that long after the release of Java 1.0, and was fueled by insufficient bandwidth and Java virtual machine compatibility problems. You can use Java to create web content on the client browser, but it's often more efficient (and safer) to do this on the server side and then deliver the finished product to the user as straight HTML, or HTML with a few bells and whistles. On many sites this kind of work is done in Perl, which is a widely used, robust, and almost completely bewildering script language. And although Perl is well-suited to this kind of work, it is by no means a general-purpose programming language. You wouldn't want to build a standalone business application with Perl.

Real Programming

Java is a real programming language. It isn't a scripting toy, and it isn't special-purpose, despite all that early press about how applets were going to save the world. You can use Java to write just about anything you want, excepting low-level code that deals directly with the hardware. Java exists at slightly higher levels of abstraction than many other languages, and that's a consequence of the attempt to make Java platform-independent. And this raises a number of concerns.

You've probably heard that Java is slow, and that it isn't a true compiled language. Both these statements are sort of true, and the reason is something called the Java Virtual Machine, or JVM.

If you're going to create a programming language that lets you write programs that can run unaltered on a variety of platforms then you're going to have to somehow reconcile the differences between those platforms (i.e. between a Windows PC and a Mac).

The Java approach is to not write software for a particular hardware platform at all. Instead, you write software to run on this other piece of software that sits between the Java program and the target platform. That piece of software is the JVM. There are JVMs for PCs running Windows, for the Mac, for Solaris, for Linux, and for a whole bunch of other platforms. The idea is that it's a lot more efficient to create tens or hundreds of JVMs than it is to create a multitude of versions of actual programs. The concept is good, but the problem is that you can end up having to write to the lowest common denominator.

Java does have mechanisms for calling platform-specific code, although doing this essentially defeats the "write once, run anywhere" purpose of using Java. That doesn't mean that it's a waste of time using Java, however, since programmers are generally more productive using Java than they are using C++.

The other major concern over the JVM model involves the speed of the executing code. Java compilers create Java bytecode, which is more like pseudocode than object code. The JVM executes the bytecode, but as this is a kind of interpretation there's some overhead involved. JVMs are getting faster, and speed concerns can also be addressed with Just-In-Time (JIT) compilers which translate often-used code to native code on the fly.

At present, Java code typically runs a bit slower than comparable C++ code, but for many applications it's an acceptable price to pay for the increase in productivity and the ease of maintaining Java code over C++ code.

The Java APIs and Components

At the same time as Sun has been refining the Java language, it has also been developing a number of APIs for everything from sound and graphics to e-commerce and telephony. These APIs have generally arrived later and less complete than most developers would like, but the lineup is starting to look fairly robust. Java also has a component framework called JavaBeans which competes with Microsoft's ActiveX/COM technology.

The component front in particular is heating up because these days it's not enough to use components within an application - you now need to be able to use components across applications, across intranets, and even across the internet.

In order to use a component that's somewhere other than inside your application you need some way to communicate with it, identify it, determine what capabilities it offers, send the component information, and get information back. There are, as you might expect, two primary competing standards for doing this.

CORBA And DCOM

One of these standards is Microsoft's Distributed Component Object Model, or DCOM. DCOM is (more or less) specific to the Windows platform, and is Microsoft's best hope for dominating the middleware market. CORBA is the collaborative effort of a bunch of people who are not Microsoft, and is governed by the Object Management Group. OMG was founded in 1989 by a group of eleven companies, one of which was Sun Microsystems.

Neither of these technologies is exactly new, and both have their strong points. DCOM certainly has the edge on the Windows platform, while CORBA has a "truer" object model and a greater measure of platform independence. This is of course an almost obscene oversimplification.

Of late, Java and CORBA have been getting significant support from corporate software developers. Although Java is owned by Sun, the specification for the JVM is publicly available. Java may not be as free or open as some would like (Sun still largely controls the language's direction and has resisted most efforts to have Java's future put in the hands of an independent standards body) but the relative openness of the specification means that any number of vendors can provide development environments.

Java and CORBA are headed for a major clash with DCOM and Microsoft development tools. A year or two ago the momentum was clearly with Microsoft, but that may not be the case any longer. Java and CORBA have both matured significantly, and perhaps spurred on by the DOJ action against Microsoft and the growing acceptance of open source software and the Linux operating system, many corporate shops are looking at solutions they perceive as less proprietary.

Will Java and CORBA win over Microsoft and DCOM? It's never a good idea to ignore the 800 pound gorilla, and in any case it's unlikely there will be a clear winner in the near future. More probably there will be some interoperability between the two systems.

What this does mean for Clarion developers is that in the future you're likely to be hearing as much about Java, JavaBeans and CORBA as you do now about ActiveX, COM and DCOM. How this will affect our day-to-day software development remains to be seen.

Reader Comments

To add a comment to this article you must log in.

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942