Section 2.3. The Java Platform | Java for ColdFusion Developers

2.3 The Java Platform

This section contains a brief history of how Java came to be, which highlights its most important features today.

2.3.1 Brief History of Java

Not only was the Java programming language not originally called "Java," it wasn't originally a programming language. Java started out as a small, three-person project at Sun Microsystems in 1991. The goal of the project was to produce a language that would work on interactive, handheld home entertainment device controllers and home appliances. At that time, the TV set-top box and on-demand video markets seemed like the most high-profile way to enter the home, which would soon expand, Sun predicted , to include the "smart toasters" that have been right around the corner for 10 years . The project was code-named "Green."

The team of developers, which included James Gosling (now touted as the "father of Java"), saw little interest from their intended market once they had a workable design for their language. Interest in the possibilities of the language may also not have been sparked by its name , "Oak," which was conceived because there was an Oak tree outside Gosling's window. In 1994, however, the team realized that they were creating a language that would fit in perfectly with the way that applications were written and delivered on the Internet.

In 1994, interest in the Internet was booming. The Oak team performed a demonstration of a Web page that included applets before a group of venture capitalists who instantly saw the possibilities. The team wrote a Web browser called HotJava (currently in version 3.0) to display the applet-enabled Web pages.

The marketing people at Sun renamed the language Java (when it was discovered that another computer language was already called Oak), and introduced Duke, a little character in the shape of the old Star Trek emblems, to help show people how much fun it is to write applets. Java was announced in May of 1995, and the first non-beta version of the language was released in 1996.

Note

There is only a very marginal relation between Java and JavaScript. JavaScript is not part of the Java technology platform, nor is it a subset of Java like CFML and CFScript. Their relation is merely one of some syntactical similarities. JavaScript (originally called LiveScript) was developed by Netscape, and a legal agreement has been worked out between Sun and Netscape with respect to the Java name.

2.3.2 Goals of the Java Language

As the team at Sun was reworking Oak into the programming language that would become Java, several design goals surfaced. Chief among these goals are the following:

Object oriented. Object-oriented languages have a number of advantages over procedural languages, including code reuse, easier maintenance, and system extensibility.
Security. Because this was a primary goal from the beginning, Java is very secure. An example of Java's security is applets, which surged in popularity because they are programs that run client side without the ability to harm files on a local disk. It would be very difficult to distribute a Java- borne virus.
Platform independence. Programs compiled from 100% Java code will run without modification on any operating system that has a Java Virtual Machine, including Linux, Windows, Solaris, FreeBSD, Tru64, HP-UX, OS390, AIX, and so on. This is a significant benefit to the language and a primary reason for its popular implementation.
Multi threading. Java has the high-performance ability to run multiple system processes at once.
Distributed. The ability to dynamically download and load libraries and classes over a network.
Code libraries. There is a tremendous amount of code already written that you can use in your Java work.

We will discuss each of these in detail over the course of the book. One of these goals, however, we will discuss first, because of its relevance to the ColdFusion migration to MX, and because it is fundamental to how Java programs are built and run.

2.3.3 Java's Relation to C, C++, and C#

There are a number of close ties between Java and C, C++, and C#, which may be instructive if you are familiar with any of those languages. Java gets its syntax from C. This was an intentional effort by the designers of the language to make Java easier for programmers to learn. Since so many people already knew and used C, they wanted to facilitate their transition to Java. Many statements and expressions are similar or identical to those in C and C++.

It was also important to solve some of the problems that programmers faced using these languages. For one thing, Java has no implementation dependency regarding primitive data types, whose size is specified in Java. For example, an int is always an integer composed of 32 bits. In C++, an int could be 16, 32, or 64 bitsthe choice is left to the compiler vendor. This could cause unexpected behavior in programs.

C# is a lot like Java; it has garbage collection, single-class inheritance, reflection API, source-code documentation comments and tools, intermediate interpreted language (like bytecode), and so forth. .NET is not cross-platform like Java is.

There are features of Java that address specific shortcomings of these languages as well. For instance, the programmer does not have to worry about memory allocation and deallocation. This is because Java has automatic garbage collection. That is, when the JVM finds that a reference points to something no longer usable, it automatically reclaims the space. Java also removed pointer arithmetic, which made it too easy to accidentally overwrite data. These improvements eliminate worries over memory corruption.

Note

While ColdFusion developers don't have to worry about memory corruption either, you may be familiar with memory errors that pop up with some frequency while using ColdFusion Studio ( especially 4.5).

2.3.4 Compiled or Interpreted

Software applications require an operating system to serve as a middle layer between themselves and the hardware that makes up the computer. For example, your machine might have a Sun SPARC, a DEC Alpha, or an Intel processor. The operating environments that work with this hardware have a different kind of machine language. Machine language, written in binary files represented as a series of 1s and 0s, is what any program that runs on a computer is eventually translated into. Because different types of hardware speak different formats of machine language, programs are often created for only one kind of system. Making it work with another system requires a rewrite for each specific platform you want your program to run on, which is expensive.

Computer programs are either compiled or interpreted, each of which have their benefits.

2.3.4.1 COMPILED PROGRAMS

Writing and running a compiled program consists of the following steps:

Programmer writes source code into a text editor.
The source code is run through a compiler, which checks the code for errors.
If there are errors, the programmer is notified and revises the code. If there are no errors, the program is successfully compiled into an executable binary program, which is platform-specific.
The compiled program is run.

The advantages of compiled programs are many. Chief among these benefits is that, as noted above, errors in the program can frequently be found before the program is distributed (don't laugh , now). Also, compiled programs run very quickly, because they are able to interact directly with the computer on which they are running.

Note

Some research has shown that HotSpot's dynamic JIT has provable performance advantages over compiled code ( mainly because HotSpot can optimize dynamically but compiled code can only be optimized at compile time).

2.3.4.2 INTERPRETED PROGRAMS

The primary difference between compiled and interpreted programs is time. Interpreted programs are not compiled before they are executed; their source code is interpreted into machine-readable binary code at runtime, for whatever the current platform is. Their advantage is that they are cross-platform. As you might suspect, however, they have serious drawbacks; among the worst is that they run slowly because they are not precompiled and because all of their error checking is handled on the fly.

2.3.5 Compiled and Interpreted: The Java Virtual Machine

Java solves the problems presented by this dichotomy in a unique manner. Programs written in the Java programming language are compiled and interpreted. When you write a Java program, you compile the source code into bytecode. Every Java-enabled system includes a Java Runtime Environment ( JRE ), which is engineered specifically for the given platform. The JRE consists of the Java Virtual Machine, the class files that make up the core of the Java platform, and other supporting files. The Java Virtual Machine is a software engine that interprets previously compiled bytecode into machine-readable instructions. It has no other associated files and is not enough to run a Java applicationthat requires a Java Runtime.

The Java Runtime, then, is specific to each platform and has variations from platform to platform. The reason that this offers an advantage over programs that are compiled into native code is that once a JRE is created for a platform, any Java program in the world can run on it, because the bytecode is all exactly the same.

This advantage was directly responsible for Java's fast rise to fame. It is what allowed applets to work in Web pages, because Java wasn't required to have a different set of code for each type of CPU connected to the Internet.

To recap, here are the steps required to run a Java program:

Programmer writes plain text source code and saves it with a .java extension.
The source code is run through a compiler (the Java Virtual Machine), which checks for errors.
If there are errors, the programmer is notified and revises the code. If there are no errors, the program is successfully compiled into a generic executable Java class file, which contains the executable bytecode. This new file is saved with a . class extension.
The compiled program is run: The operating system-specific Java Virtual Machine reads the . class file, runs a security check, and interprets the bytecode.

As you might suspect, this setup makes initial calls to an application rather slow, but subsequent calls very fast. Significant performance improvements are made with each Java release.

2.3.6 The SDK

The Java Virtual Machine is at the core of this architecture, but it alone is not enough to run Java programs. For that, you need the Java Runtime Environment. However, these tools together are not enough for the programmer to write Java programs. For that, you need the SDK (Software Development Kit). The Java SDK consists of a JVM, compiler and other tools, and core APIs. Documentation is a separate download.

Note

You may wonder what happened to the JDK (Java Development Kit). It has become the SDKit was merely renamed in November of 1999. The term JDK persisted through Java version 1.1. It can be confusing, because while the name has changed, the versioning has not. Sort of. Because so many changes to the language occurred, version 1.2 became referred to as Java 2 (three days after it was released!). Java is currently in version 1.4, with version 1.5 (code-named Tiger) to be released in the summer of 2003. So Java 1.2, 1.3, and 1.4 are all referred to as Java 2. Perhaps Tiger will be referred to as Java 5 (heyit was good enough for IntraDev, which just jumped from version 1.0 to version 6). Sheesh.

2.3.7 The JRE

The Java Runtime Environment is what allows access to the Java Virtual Machine and to the supporting system. The JRE offers a way to start up garbage collection in the JVM and to, for instance, write to the output stream. The JRE also features a security manager, which controls the JVM's access to resources on the local machine or network connections.

When Java classes are loaded into the Virtual Machine, a verifier ensures that the bytecodes are all correctly formed and that all security requirements for the application are met. It is in this way that Java applications are able to execute on the client (in the form of applets) in a safe manner. Careless or malicious programmers cannot do as much harm as easily in this circumstance.

2.3.8 The API and Editions

An Application Programming Interface is the set of rules for interfacing with a given technology; it is the syntax for using a language. Java's API includes hundreds of class libraries containing prewritten code that you can use to create Java programs.

You can find documentation for all of the APIs at http://java.sun.com/products. The APIs are extensive , and they can be daunting (even fruitless) for beginners to read. Later, in the "Gathering Your Tools" section of this chapter, you will find how to get to and read the Java API references.

The Java platform is specialized and packaged into different editions, each of which caters to a different target system, ranging from cell phones to supercomputers.

2.3.8.1 J2EE

Java 2 Enterprise Edition is intended for building large-scale, server-side systems for the enterprise. Everything that is in the Standard Edition is here, plus libraries for supporting enterprise directory services, messaging, and transaction management. We will discuss a number of J2EE technologies in this book, including JSP and servlets, XML, and JDBC.

2.3.8.2 J2SE

Java 2 Standard Edition is the most frequently used development kit, the obvious starting place for learning Java, and the one we focus on in this book. It includes a compiler and a runtime system, and with it you can write and run Java applications. More than one million downloads of JDK 1.4 were made within a month of its release.

2.3.8.3 J2ME

Java 2 Micro Edition is geared for applications that run embedded in consumer products such as cellular phones, PDAs, smart cards, pagers , set-top devices, and car navigation systems. The Micro Edition is the only edition that is subdivided into profiles. A profile is a definition of the libraries required for different platforms and the JVM requirements for supporting a given micro platform. For instance, there is one profile for PDAs and another for wireless devices. The edition includes a runtime environment, like the others, but it is a very small footprint runtime. For instance, the smart card runtime consumes only 128 kB of memory.

2.3.8.4 STANDARD EXTENSIONS

The Java platform also features a number of "standard extensions," which are small packages released as add-ons to an edition. For instance, something called JAXP, the Java API for parsing XML documents, has been available as a standard extension. These are not included in the regular JDK download; you must download each one that you wish to use. Very popular or useful extensions often get added into the core of a new edition release. The XML parsing that used to be performed by JAXP has been incorporated into the core platform for Java 1.4.

2.3.8.5 WHAT'S NEW IN JAVA 1.4

Java 1.4 contains a number of new features that are of interest, many of which we examine in this book. Each JDK release focuses on performance improvements. But each also offers a varying number of new features. For JDK 1.4, these include

New I/O classes offering improved performance, and the ability to lock files and create file memory maps
Support for mouse wheels in GUI development
Built-in logging with the java.util.logging package
Support for secure sockets and HTTPS
XML support includes SAX and DOM parsing and XSLT transformations (as noted above, these were standard extensions for Java 1.3)
Incorporation of WebStart, an exciting utility for distributing programs via the Web
Assertions, which are used to verify design assumptions in your code
64-bit addressing for Solaris machines
Regular expression support, with the pattern syntax used in Perl 5

New JDKs will be shipped approximately every 1215 months. You can follow new releases and work with beta releases at the Sun website at http://java.sun.com. To see in advance where the technology is going, you might look at http://jcp.org/jsr/stage/jsr.jsp, which is the homepage for Java Specification Requests. This site offers information about proposed updates to the language, who is involved in the user groups, what the proposed specification will do, and why it is needed.

2.3.9 Execution Environments

There are three execution environments for Java, as you likely know. These are as follows :

Standalone applications . These range from small command-line programs that output a string, to utility programs, to full-blown GUI applications such as a Web browser, text editor, spreadsheet program, character games , and so on.
Applets . These are just applications made specifically to run in a Web browser.
Servlets . Servlets are run on the server side, usually as part of a Web application. These and JSP (JavaServer Pages) are the aspects of the Java language that fulfill the same goals that ColdFusion does.

All of the above are written in the same language, using the same general tools. The SDK contains everything you need to write, test, and run Java applications. If you are writing applets, then you can use either a Web browser or a specific command-line utility (called appletviewer ) to execute your applets. Servlets are a different deal and will only run in a servlet container such as Apache Software Foundation's Tomcat or Macromedia's JRun, both currently in version 4.

The JVM is one leveleverything ultimately runs in a JVM. Then, besides applets and standalone apps, there are various types of components (JSPs, servlets, EJBs, JMX MBeans) that require a particular type of container, which provides calls to execute their lifecycle methods and provides services to the components .

Because knowledge of the Java programming language is necessary for writing each of these, we will begin by getting everything we need to write and execute Java programs. We will spend a good deal of time discussing server-side Java, but not much time on applets. The reason for this is that interest in applets has lagged significantly since the introduction of server-side Java.

Top