Java History and Technology

Java was developed in the early nineties. At that time; it was called Oak. Oak was intended for use in embedded applications, such as cellular phones. For various reasons it never really took off. However, in the mid-nineties, as the Internet began to reach a wide audience, Sun Microsystems reworked Oak into an Internet programming language and renamed it Java 1.0. Java promised "write once, run anywhere" compatibility across platforms. In theory, and most often in the real world, a Java program developed on one particular platform, such as Mac OS, could run on any platform that has a Java Virtual Machine. In addition, Java enabled a special type of program called an applet that could be run in a Web browser and embedded in an HTML file (in much the same way that an image is). When Netscape included Java support with its Navigator 2.0 browser, Java quickly became very popular. In those days, many people predicted that personal computers were on the way out and that we would soon be using "network appliances" running programs written in Java and downloaded from a server.

Java Today

As you might have noticed, it didn't turn out quite that way. Java applets could more accurately be described as "write once, run most places." Applets are used in some highly interactive Web applications like games and stock analysis programs. More mundane Web applications like data entry, simple animation, and data validation have been taken over by other technologies like HTML forms, JavaScript, CGI (Common Gateway Interface), and animated GIF.

Java has been successful on the server side. Server-side code is the code that ties older computer systems to the Web, and the code that generates dynamic HTML files based on user requests to the server.

There are several reasons that Java applets have not become as popular as server-side Java. First, compared to other kinds of technologies, applets are very slow to download. It's only worth the wait in applications like games, where fast execution makes up for the long initial download time. Second, virtual machines for various platforms have not been consistent or stable enough to allow Java applet writers to develop commercial-quality software without extensive testing. Third, Java is relatively new, and therefore its specification and implementation are still very dynamic. It went through three major revisions in its first couple years of existence. Despite these limitations, applets are very useful for certain applications. They're also an excellent way to learn Java.

Nevertheless, the code included in the Java API (Application Programming Interface) is perfect for developing programs that run on the server side. You can write a simple Web server application in less than ten lines of code!

Future

Predicting the future is always a dangerous thing, but here I'll be vague enough that regardless of what happens I can pretend that I predicted it. I expect that the use of applets will increase over the next several years as user bandwidth increases and Java virtual machines become more stable. More and more of the functionality of personal computers will be delivered over a network. We'll eventually see many current personal computer applications taken over by what the pundits of three years ago would recognize as network appliances. Some of the software running on these appliances will be written in Java.

Java will continue to grow as a server-side programming language and will be the preferred way of customizing and integrating server applications.

Sun continues to push Java as a programming language for embedded systems. It remains to be seen whether Java makes any headway in this area.

The Language in Context

One of the first questions to ask upon encountering a new programming language is whether it's interpreted or compiled. The answer for Java is both. A Java program begins its life as source code, a text file saved with a .java extension. Each Java program is compiled to bytecode by the Java compiler. The bytecode will appear in a file with a .class extension. It is this class file that's actually transmitted over the Internet when a user downloads an applet. Think of bytecode as an assembly language. It's still readable by humans, but has a much simpler instruction set than a high-level language like Java.

Bytecode is then interpreted by the JVM. The JVM is called a virtual machine because it is said to simulate a hardware processor. I find this to be a pretty subtle difference, so I typically describe the JVM as an interpreter.

Getting the Most from Java

The good thing about using a JVM to run Java programs is that your bytecode will run on any computer that has a JVM installed. This means that when you compile your applet to a class file and put it on your Web server, it can download and run on Mac OS, Solaris, Windows 95, Windows XP, or Linux. The problem with a virtual machine is that it isn't as fast as a real machine. There are many schemes for speeding up the JVM, but the best you can realistically hope for is about half the speed of a program compiled for a specific processor.

Fortunately, this is good enough for most applications. If your program uses a Java graphical user interface, it probably spends the vast majority of processor cycles waiting around for the user to do something. If you're writing networking code, your network is probably a much bigger bottleneck than your processor.

If you have an application that's processor-intensive but still want to take advantage of the power of Java, here are some things you can do to speed things up.

* Just In Time (JIT) compilers: You can get a virtual machine that actually compiles portions of your bytecode to processor-specific machine code right before executing the code.
* Native methods: Java gives you the option to develop some of your code in a processor-specific language. This means that you could write the routine that calculates pi to the twelve-thousandth decimal place in C but write the rest of your program in Java.
* Processor-specific Java compiler: If you're willing to give up the advantages of portability, you can buy compilers that compile Java to processor-specific code.
* Your own benchmarking: Certain JVMs are better at some things than others. Figure out what your applications spend a lot of time doing and test the JVMs on the platform you intend to use.

Another thing to consider when deploying your application or applet: Java provides a utility for bundling all the files that make up your program into a single file. This file is known as a jar or Java archive file. Using a jar file is optional, but can make your code a lot easier to deploy.

Java is Object-Oriented

As I mentioned earlier, Java is an object-oriented language. All of your Java code will belong to a class. All of your classes inherit from the superclass object by default. None of your code will be located outside a class (except interfaces, which are class-like). Therefore, there are no global variables.

The Language and the Application Programming Interface

The core Java API is a large library of pre-written code that you can use to do everything from networking to building complex graphical user interfaces. Though this course focuses exclusively on the core Java API, remember that there are many other APIs available from Sun. They're designed to help you do everything from telephony to 3-D graphics. The API is composed of classes, so you'll need a basic understanding of object technology to use it. We'll cover object technology in Lesson 5. Lessons 6-12 are devoted to various interesting aspects of the core API. Please remember that those lessons barely scratch the surface of the functionality available in the core API.

Though the APIs are complex, the Java language itself is really quite simple to understand, particularly for experienced programmers. If you know C/C++, you'll find it very familiar. However, unlike some other languages, it's not possible to completely separate the API from the language because there is almost no functionality built into the Java language itself. Even a simple mathematical operation like exponentiation is part of the API instead of the language. Lessons 3 and 4 will focus primarily on the Java language.

More About Applets

All Java applets are subclasses of the applet class in the core API. Applets differ from other Java applications in that a browser controls applet program execution. For instance, the browser calls your applet's init() method when the applet is started. An applet's start() and stop() methods are called when the page where the applet is running gains or loses focus. Applets also differ from applications in that they have default settings that, for security reasons, will not allow access to the file system of the computer they're running on. There are ways to use the security features of Java to override this, but that topic is beyond the scope of this course.

For development purposes, CodeWarrior (and the JDK) includes an application that allows you to run applets from the IDE without using a browser. If you're working in Mac OS, you'll use the Applet Runner that's included with newer versions of the operating system and which will run applets from the desktop.

I've chosen to use applets for this class instead of applications because the "black magic" (stuff that you have to take my word for until much later in the class when you have the background to understand it) is much better hidden. The Course Notes contain a detailed description of how to convert your applets into applications. Take a look at the applications discussion in the Course Notes and you'll see what I mean.

Lastly, don't forget that both applets and applications require that a JVM be installed on the client system before they can be run.

(reading from Codewarrior web site)