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.
