matt ryall’s weblog

It has come to my attention recently that there is some confusion (even among quite knowledgeable technical people) about the correct usage of Java terms like JDK, JVM, etc. I think this springs from the fact that a lot of developers use them interchangeably, assuming that the other person will understand the meaning from the context. Some of the acronyms are even used commonly by developers in places where they don't even make sense.

I thought I'd make a public service blog defining some of these terms as I've seen and heard them used, to help others who might need this information for their work.

Who should read this? People who are not Java developers: marketing and sales people, technical writers, support staff, others without a lot of Java experience. This post intentionally skips over many technical details.

The Java Virtual Machine (JVM) is the piece of software that runs a Java application. All Java software runs "in" or "on" a JVM. All JVMs provide the same environment for your application to run in, which allows a Java application to run on Windows, Linux, Mac and many other platforms.

Sun develops the most popular JVM implementation and provides it for Windows, Linux and Solaris. The JVM for Mac OS X is developed by Apple. BEA and IBM have implementations of the JVM, and there are a few minor open source ones. Although it's not used often, the term Java Runtime Environment (JRE) means an implementation of the JVM and all the other stuff you need to run a Java application. You might hear people say "the Sun JRE" or "the BEA JRockit JRE" in reference to this.

Before we go much further, I should explain a bit more about how application programming interfaces (APIs) work and the word "implementation" actually means. API is a very vague term and basically means "someone else's code you run to do stuff". Because you might want to do the same stuff in different places (like on Windows and Mac), most APIs just standardise the way you ask for something to be done. An implementation of that API actually has the code that is executed when you ask for it to happen. This is how Java APIs work. There is a diagram on the right that shows this graphically.

As I mentioned above, it is because each JVM provides the same environment that Java applications can be run on different platforms. This environment is called the Java Platform, Standard Edition (Java SE), or informally, the JDK. It consists of a framework of about 3700 classes. These classes must be implemented according to this specification in every JDK. Sun defines this specification.

The Java Platform, or JDK, has evolved over time so there are several versions of it. The latest major version is Java SE 6 or JDK 6. Our applications are mostly written against either version 1.4 or 5, which are both still supported by Sun.

Even though the Java Platform is often called the JDK, the correct definition is very different. As originally defined, the Java Development Kit (JDK) is actually a combination of Java compilation tools and API implementation for a particular version of the Java Platform. It also typically includes a Java runtime (JRE), so that you can run the programs you compile.

It is in the usage of the term "JDK" that most of the confusion arises. For reasons I don't understand, it has become commonplace to hear the version of the platform one is running referred to as one's JDK. You can say "download the Sun JDK" to mean download the Sun Java compiler and associated tools, but it's also common to hear "Confluence requires JDK 5" which is about what version of the Java API that Confluence uses, not specifically related to the compiler itself. While the latter form is in common use, it would be better to say "Confluence requires Java 5", which is commonly used and also technically correct.

Java Enterprise Edition (JEE), formerly Java 2 Enterprise Edition or J2EE, is a collection of APIs which aren't included in the standard JDK but provide functionality which is useful for many server applications. One example is JavaMail, which is a standard way of accessing email from Java. This isn't available with the standard JDK, but Sun has provided a standard API and implementation for people to use in Java applications.

Application servers provide implementations of many of the JEE standards. Most important to Atlassian applications are the Java Servlet API, the Java Transaction API and the data source APIs in JEE. We also rely quite heavily on a front-end technology called JavaServer Pages (JSP). People talk about "JEE application servers" or just "application servers". You don't often hear JEE or J2EE mentioned when talking about versions or application requirements, except in the most technical discussions.

Examples

Because these terms can be used either correctly, informally or incorrectly, I've split the examples into three sections.

Correct usage

• "You need to install a JDK to compile a Java program"
• "You need to configure your JVM parameters to increase the memory allocation"
• "I don't understand why Java SE doesn't include support for email"
• "You need to be running Java 1.4 or later to use JIRA 3.10"
• "Bamboo uses the JEE APIs for database access and email notifications"
• "You need a JEE application server to run Atlassian applications"

Dubious common usage

• "You need to be running JDK 5 or later to use Confluence 2.9" – should use "Java 5"
• "IBM's JDK is supported for running JIRA, but we recommend using the Sun JDK" – technically correct would be "JVM" not "JDK"
• "You need a JEE server to run Crowd" – better to say "Java application server", or specify which JEE standards you need, e.g. "You need a servlet container ..."

Incorrect usage

• "You need to use Java SE 5 to run Confluence" – should just use "Java 5"
• "Which Java SE version are you using?" – should just use "Java"
• "I've installed the Java API" – you can only install an implementation of an API, not the API itself. You probably mean "the JRE" or "the JDK"
• "Which JEE are you using?" – say "Java version" or "application server" instead of "JEE"
• "Storm the Java" – err?

Of course, there are many ways to mash the terms together so they don't make sense at all. I'm sure I don't need to provide any examples of that.

Intentional simplifications

Some notes for the narky developers out there who will argue with my definitions on the basis of minor technical concerns. I have intentionally omitted the following details:

• There's an important distinction between programs written in Java and bytecode that can run on the JVM. However, explaining the difference between bytecode, machine code and Java code is too technical for this discussion.
• While the JVM specification defines the runtime environment, the API is in fact separate to this. This is mostly just a theoretical separation. You could run stuff on the JVM that doesn't use the Java API, but I can't imagine you'd be able to do much with it. Therefore, all JVMs include a Java API implementation, and other languages that use the JVM build on top of the Java API.
• The Java language specification is also separate to the Java API and the JVM specification. Discussing a language separate to its most common implementation is too technical for this post.
• J2ME has a so-called JVM which doesn't follow the JVM specification. Go figure. It also doesn't ship with a standard set of class libraries like the Java SE Platform.
• A JDK doesn't technically require a JRE to do its job, but almost all of them include one. Likewise, there are Java compilers written that ship without a API implementation, so a JDK doesn't technically require an API implementation. Some Java compilers can compile to machine code rather than bytecode, in which case an API implementation is necessary.
• Java 1.4 was called Java 2 SE 1.4 when it was released, but explaining Java's history of version numbering is overly complex and not necessary for this discussion. I'd actually prefer to call it Java 4, but retroactively applying the new version numbering system to old releases could be confusing. Java 5 is versioned internally as 1.5, and Java 6 is 1.6.

Thanks to the Atlassian developers who pointed out several edge cases I had missed, and to Chris Owen for reviewing an early draft. Please feel free to post any questions or criticisms in the comments.