What Is Javaby Chris Adamson
- "Java" generally refers to a combination of three things: the Java programming language (a high-level, object-oriented programming language); the Java Virtual Machine (a high-performance virtual machine that executes bytecodes on a specific computing platform, typically abbreviated JVM); and the Java platform, a JVM running compiled Java bytecodes, usually calling on a set of standard libraries such as those provided by Java Standard Edition (SE) or Enterprise Edition (EE). Though coupled by design, the language does not imply the JVM, and vice versa.
In this Article
- The Java Programming Language
- The Java Platforms
- The Java Virtual Machine
- The JVM Without Java
- The Java Community Process
We recently received an email asking for a "What Is Java" entry on the O'Reilly Network What Is site. Who could possibly not know what Java is in 2006? After ten years of books, websites, and conferences, doesn't everyone know what Java is? Apparently not.
After all, things have changed.
For every dusty definition that speaks of applets and Just-In-Time compilers, there are new directions and new realities that have settled in, understood by many, yet not always completely documented. Java used to mean:
- Bytecode interpretation
- Slow performance
- A "cargo cult" awaiting drops from Sun
Today, it means:
- Web applications, web services, SOAs, etc.
- Hotspot dynamic compilation
- An open source community, increasingly independent of Sun
The old slogan "Write Once, Run Anywhere" still holds true--but what's being written and where and how it's being run are changing.
Java, the language, is a high-level object-oriented programming language, influenced in various ways by C, C++, and Smalltalk, with ideas borrowed from other languages as well (see O'Reilly's History of Programming Languages). Its syntax was designed to be familiar to those familiar with C-descended "curly brace" languages, but with arguably stronger OO principles than those found in C++, static typing of objects, and a fairly rigid system of exceptions that require every method in the call stack to either handle exceptions or declare their ability to throw them. Garbage collection is assumed, sparing the developer from having to free memory used by obsolete objects.
One of Java's more controversial aspects--widely accepted at the time of its release but increasingly criticized today--is its incomplete object-orientation. Specifically, Java primitives such as
boolean, etc. are not objects, and require a completely different treatment from the developer: as
int is not a class, you cannot subclass and declare new methods on it, cannot pass it to a method that expects a generic
Object, and so on. The inclusion of primitives increases Java performance, but at the arguable expense of code clarity, as anyone who's had to work with the so-called "wrapper classes" (
Boolean) will attest. Java 5.0 introduces an "autoboxing" scheme to eliminate many uses of the wrapper classes, but in some ways it obscures what is really going on.
Philosophically, Java is a "fail early" language. Because of its syntactic restrictions, many programming failures are simply not possible in Java. With no direct access to pointers, pointer-arithmetic errors are non-existent. Using an object as a different type than what it was originally declared to be requires an explicit cast, which gives the compiler an opportunity to reject illogical programming, like calling a
String method on an
Many Java enterprise frameworks require the use of configuration files or deployment descriptors, typically written in XML, to specify functionality: what class handles a certain HTTP request, the order of steps to execute in a rule engine, etc. In effect, they have to go beyond the language to implement their functionality. Critics point out that this has the perverse effect of not only escaping Java's compiler checks, but also that a developer can no longer determine how a program will operate just by looking at its source code. Java 5.0 adds annotations to the language, which allows the tagging of methods, fields, and classes with values that can then be inspected and operated on at runtime, usually through reflection. Many programmers like annotations because they simplify tasks that might otherwise be addressed by deployment descriptors or other means. But again, they can make it difficult to understand Java code, as the presence or absence of an annotation may affect how the code is executed, in ways that are in no way obvious from the annotation.
Despite these criticisms, Java is generally understood to be the most popular general-purpose computing language in use today. It is a widely used standard in enterprise programming, and in 2005, it replaced C++ as the language most used by projects on SourceForge. What it has going for it is immense: free tools (on multiple platforms: Linux, Windows, Solaris, and Mac can all compile and execute Java apps), a vast base of knowledge, and a large pool of readily available developers.
The Java language hits a specific point in the tradeoff between developer productivity and code performance: CPU cycles keep getting cheaper, developers largely don't, so it is perhaps inevitable to accept another layer of abstraction between the developer and the execution of CPU opcodes, if it allows the developer to create better software faster. In fact, critics of Java's productivity, such as Bruce Tate in Beyond Java, may simply be observing this trend continuing past Java to a new sweet spot that further trades performance for developer productivity.