Introduction

James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991. The language was initially called Oak after an oak tree that stood outside Gosling’s office; it went by the name Green later, and was later renamed Java, from Java coffee, said to be consumed in large quantities by the language’s creators.

Sun Microsystems released the first public implementation as Java 1.0 in 1995. It promised “Write Once, Run anywhere” (WORA), providing no-cost run-times on popular platforms. Fairly secure and featuring configurable security, it allowed network- and file-access restrictions. Major web browsers soon incorporated the ability to run Java applets within web pages, and Java quickly became popular. With the advent of Java 2 (released initially as J2SE 1.2 in December 1998–1999), new versions had multiple configurations built for different types of platforms.

Principles

There were five primary goals in the creation of the Java language:

1. It should be “simple, object-oriented and familiar”.
2. It should be “robust and secure”.
3. It should be “architecture-neutral and portable”.
4. It should execute with “high performance”.
5. It should be “interpreted, threaded, and dynamic”.

Versions

Major release versions of Java, along with their release dates:

• JDK 1.0 (January 23, 1996)
• JDK 1.1 (February 19, 1997)
• J2SE 1.2 (December 8, 1998)
• J2SE 1.3 (May 8, 2000)
• J2SE 1.4 (February 6, 2002)
• J2SE 5.0 (September 30, 2004)
• Java SE 6 (December 11, 2006)
• Java SE 7 (July 28, 2011)

Java Platform

One characteristic of Java is portability, which means that computer programs written in the Java language must run similarly on any hardware/operating-system platform. This is achieved by compiling the Java language code to an intermediate representation called Java bytecode, instead of directly to platform-specific machine code. Java bytecode instructions are intended to be interpreted by a virtual machine (VM) written specifically for the host hardware.

A major benefit of using bytecode is porting. However, the overhead of interpretation means that interpreted programs almost always run more slowly than programs compiled to native executable would. Just-in-Time compilers were introduced from an early stage that compiles bytecodes to machine code during runtime.

Performance

Programs written in Java have a reputation for being slower and requiring more memory than those written in C. However, Java programs’ execution speed improved significantly with the introduction of Just-in-time compilation in 1997/1998 for Java 1.1, the addition of language features supporting better code analysis (such as inner classes, StringBuffer class, optional assertions, etc.), and optimizations in the Java Virtual Machine itself, such as HotSpot becoming the default for Sun’s JVM in 2000. Currently, Java 2.0 code had approximately half the performance of C code. However, Java 5.0 has been shown to run at native speeds that sometimes match and occasionally beat the speed of C and C++.

Automatic memory management

Java uses an automatic garbage collector to manage memory in the object lifecycle. The programmer determines when objects are created, and the Java runtime is responsible for recovering the memory once objects are no longer in use. Once no references to an object remain, the unreachable memory becomes eligible to be freed automatically by the garbage collector.

Garbage collection may happen at any time. Ideally, it will occur when a program is idle. It is guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new object; this can cause a program to stall momentarily. Explicit memory management is not possible in Java.

Java does not support C/C++ style pointer arithmetic, where object addresses and unsigned integers (usually long integers) can be used interchangeably. This allows the garbage collector to relocate referenced objects and ensures type safety and security.

Java contains multiple types of garbage collectors. By default, HotSpot uses the Concurrent Mark Sweep collector, also known as the CMS Garbage Collector. However, there are also several other garbage collectors that can be used to manage the Heap. For 90% of applications in Java, the CMS Garbage Collector is good enough.

Back to Index