History
James Gosling, Mike Sheridan, and
Patrick Naughton initiated the Java language project in June 1991.
[11] Java was originally designed for interactive television, but it was too advanced for the digital cable television industry at the time.
[12] 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.
[13] Gosling aimed to implement a
virtual machine and a language that had a familiar
C/
C++ style of notation.
[14]
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. For example,
J2EE targeted enterprise applications and the greatly stripped-down version
J2ME for mobile applications (Mobile Java).
J2SE designated the Standard Edition. In 2006, for marketing purposes, Sun renamed new
J2 versions as
Java EE,
Java ME, and
Java SE, respectively.
On November 13, 2006, Sun released much of Java as
open source software under the terms of the
GNU General Public License (GPL). On May 8, 2007, Sun finished the process, making all of Java's core code available under
free software/open-source distribution terms, aside from a small portion of code to which Sun did not hold the copyright.
[17]
Sun's vice-president Rich Green has said that Sun's ideal role with regards to Java is as an "evangelist."
[18]
Following
Oracle Corporation's acquisition of Sun Microsystems in 2009–2010, Oracle has described itself as the "steward of Java technology with a relentless commitment to fostering a community of participation and transparency".
[19]
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 analogous to machine code, but are intended to be
interpreted by a
virtual machine (VM) written specifically for the host hardware.
End-users commonly use a
Java Runtime Environment (JRE) installed on their own machine for standalone Java applications, or in a Web browser for Java
applets.
Standardized libraries provide a generic way to access host-specific features such as graphics,
threading, and
networking.
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 executables would. Just-in-Time compilers were introduced from an early stage that compile bytecodes to machine code during runtime.
Implementations
Sun Microsystems officially licensed the Java Standard Edition platform for
Linux,
[21] Mac OS X,
[22] and
Solaris. In the past Sun licensed Java to Microsoft but the license expired without renewal.
[23] Because Windows does not ship with a Java software platform, a network of third-party vendors and licensees
[24] develop them for Windows and other operating system/hardware platforms.
Sun's trademark license for usage of the Java brand insists that all implementations be "compatible". This resulted in a legal dispute with
Microsoft after Sun claimed that the Microsoft implementation did not support
RMI or
JNI and had added platform-specific features of their own. Sun sued in 1997, and in 2001 won a settlement of US$20 million, as well as a court order enforcing the terms of the license from Sun.
[25] As a result, Microsoft no longer ships Java with
Windows, and in recent versions of Windows,
Internet Explorer cannot support Java applets without a third-party plugin. Sun, and others, have made available free Java run-time systems for those and other versions of Windows.
Performance
Programs written in Java have a reputation for being slower and requiring more memory than those written in
C.
[26] However, Java programs' execution speed improved significantly with the introduction of
Just-in-time compilation in 1997/1998 for
Java 1.1,
[27] 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.
[28] However, Java 5.0 has been shown to run at native speeds that sometimes match and occasionally beat the speed of
C and
C++.
[citation needed]
Some platforms offer direct hardware support for Java; there are microcontrollers that can run Java in hardware instead of a software JVM, and
ARM based processors can have hardware support for executing Java bytecode through its
Jazelle option.
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. Something similar to a
memory leak may still occur if a programmer's code holds a reference to an object that is no longer needed, typically when objects that are no longer needed are stored in containers that are still in use. If methods for a nonexistent object are called, a "null pointer exception" is thrown.
[29][30]
One of the ideas behind Java's automatic memory management model is that programmers can be spared the burden of having to perform manual memory management. In some languages, memory for the creation of objects is implicitly allocated on the
stack, or explicitly allocated and deallocated from the
heap. In the latter case the responsibility of managing memory resides with the programmer. If the program does not deallocate an object, a
memory leak occurs. If the program attempts to access or deallocate memory that has already been deallocated, the result is undefined and difficult to predict, and the program is likely to become unstable and/or crash. This can be partially remedied by the use of
smart pointers, but these add overhead and complexity. Note that garbage collection does not prevent "logical" memory leaks, i.e. those where the memory is still referenced but never used.
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.
As in
C++ and some other object-oriented languages, variables of Java's
primitive data types are not objects. Values of primitive types are either stored directly in fields (for objects) or on the
stack (for methods) rather than on the heap, as commonly true for objects (but see
Escape analysis). This was a conscious decision by Java's designers for performance reasons. Because of this, Java was not considered to be a pure object-oriented programming language. However, as of Java 5.0,
autoboxing enables programmers to proceed as if primitive types were instances of their wrapper class.
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.
[31]