Java (programming language)

Java

File:Java Logo.svg
Paradigm	Object-oriented, structured, imperative
Designed by	Sun Microsystems
First appeared	1990s
Typing discipline	Static, strong, safe, nominative
OS	Cross-platform
Website	http://www.java.com/
Major implementations
Numerous
Influenced by
Objective-C, C++, Smalltalk, Eiffel, C#
Influenced
C#, D, J#, PHP

Java is an object-oriented programming language developed by Sun Microsystems in the early 1990s. Java applications are designed to be compiled to bytecode, which is interpreted at runtime, unlike conventional programming languages, which either compile source code to native (machine) code or interpret source code at runtime.

The language itself borrows much syntax from C and C++ but has a simpler object model and fewer low-level facilities. JavaScript, a scripting language, shares a similar name and has similar syntax, but is not related to Java.

History

Java was started as a project called "Oak" by James Gosling in June 1991. Gosling's goals were to implement a virtual machine and a language that had a familiar C-like notation but with greater uniformity and simplicity than C/C++. The first public implementation was Java 1.0 in 1995. It promised "Write Once, Run Anywhere" (WORA), providing free runtimes on popular platforms. It was fairly secure and its security was configurable, allowing network and file access to be restricted. Major web browsers soon incorporated the ability to run secure Java "applets" within web pages. Java became popular quickly. With the advent of "Java 2", new versions had multiple configurations built for different platforms. For example, J2EE was for enterprise applications and the greatly stripped down version J2ME was for mobile applications.

In 1997, Sun approached the ISO/IEC JTC1 standards body and later the Ecma International to formalize Java, but it soon withdrew from the process. Java remains a proprietary de facto standard that is controlled through the Java Community Process . Sun makes most of its Java implementations available without charge, with revenue being generated by specialized products such as the Java Enterprise System. Sun distinguishes between its Software Development Kit (SDK) and Runtime Environment (JRE) which is a subset of the SDK, the primary distinction being that in the JRE the compiler is not present.

On November 13th 2006, Sun released parts of Java as Free/Open Source Software, under the GNU General Public License. The release of the complete sources under GPL is expected in the first quarter of 2007.

Releases

The Java project has seen many release versions. They are:

• JDK 1.1.4 (Sparkler) September 12, 1997
  • JDK 1.1.5 (Pumpkin) December 3, 1997
  • JDK 1.1.6 (Abigail) April 24, 1998
  • JDK 1.1.7 (Brutus) September 28, 1998
  • JDK 1.1.8 (Chelsea) April 8, 1999
• J2SE 1.2 (Playground) December 4, 1998
  • J2SE 1.2.1 (none) March 30, 1999
  • J2SE 1.2.2 (Cricket) July 8, 1999
• J2SE 1.3 (Kestrel) May 8, 2000
  • J2SE 1.3.1 (Ladybird) May 17, 2001
• J2SE 1.4.0 (Merlin) February 13, 2002
  • J2SE 1.4.1 (Hopper) September 16, 2002
  • J2SE 1.4.2 (Mantis) June 26, 2003
• Java SE 5 (1.5.0) (Tiger) September 29, 2004
• Java SE 6 (1.6.0) (Mustang) anticipated for Fall, 2006

Philosophy

Primary Goals

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

1. It should use the object-oriented programming methodology.
2. It should allow the same program to be executed on multiple operating systems.
3. It should contain built-in support for using computer networks.
4. It should be designed to execute code from remote sources securely.
5. It should be easy to use by selecting what was considered the good parts of other object-oriented languages.

To achieve the goals of networking support and remote code execution, Java programmers sometimes find it necessary to use extensions such as CORBA, Internet Communications Engine, or OSGi.

Platform independence

File:SwingSet.png

The look and feel of Java Swing GUIs is independent of the platform on which they are running

One characteristic, platform independence, means that programs written in the Java language must run similarly on diverse hardware. One should be able to write a program once and run it anywhere.

This is achieved by most Java compilers by translating the Java language code "halfway" to bytecode (specifically Java bytecode)—simplified machine instructions specific to the Java platform. The code is then run on a virtual machine (VM), a program written in native code on the host hardware that interprets and executes generic Java bytecode. Further, standardized libraries are provided to allow access to features of the host machines (such as graphics, threading and networking) in unified ways. Note that, although there's an explicit compiling stage, at some point, the Java bytecode is interpreted or converted to native machine instructions by the JIT compiler.

There are also implementations of Java compilers that translate the Java language code to native object code, such as GCJ, removing the intermediate bytecode stage, but the output of these compilers can only be run on a single architecture.

Sun's license for Java insists that all implementations be "compatible". This resulted in a legal dispute with Microsoft after Sun claimed that the Microsoft implementation did not support the RMI and JNI interfaces and had added platform-specific features of their own. Sun sued and won both damages (some $20 million) and a court order enforcing the terms of the license from Sun. In response, Microsoft no longer ships Java with Windows, and in recent versions of Windows, Internet Explorer cannot support Java applets without a third-party plugin. However, Sun and others have made available Java run-time systems at no cost for those and other versions of Windows.

The first implementations of the language used an interpreted virtual machine to achieve portability. These implementations produced programs that ran more slowly than programs compiled to native executables, for instance written in C or C++, so the language suffered a reputation for poor performance. More recent JVM implementations produce programs that run significantly faster than before, using multiple techniques.

The first technique is to simply compile directly into native code like a more traditional compiler, skipping bytecodes entirely. This achieves good performance, but at the expense of portability. Another technique, known as just-in-time compilation (JIT), translates the Java bytecodes into native code at the time that the program is run which results in a program that executes faster than interpreted code but also incurs compilation overhead during execution. More sophisticated VMs use dynamic recompilation, in which the VM can analyze the behavior of the running program and selectively recompile and optimize critical parts of the program. Dynamic recompilation can achieve optimizations superior to static compilation because the dynamic compiler can base optimizations on knowledge about the runtime environment and the set of loaded classes. JIT compilation and dynamic recompilation allow Java programs to take advantage of the speed of native code without losing portability.

Portability is a technically difficult goal to achieve, and Java's success at that goal has been mixed. Although it is indeed possible to write programs for the Java platform that behave consistently across many host platforms, the large number of available platforms with small errors or inconsistencies led some to parody Sun's "Write once, run anywhere" slogan as "Write once, debug everywhere".

Platform-independent Java is however very successful with server-side applications, such as Web services, servlets, and Enterprise JavaBeans, as well as with Embedded systems based on OSGi, using Embedded Java environments.

Automatic garbage collection

One idea behind Java's automatic memory management model is that programmers should be spared the burden of having to perform manual memory management. In some languages the programmer allocates memory to create any object stored on the heap and is responsible for later manually deallocating that memory to delete any such objects. If a programmer forgets to deallocate memory or writes code that fails to do so in a timely fashion, a memory leak can occur: the program will consume a potentially arbitrarily large amount of memory. In addition, if a region of memory is deallocated twice, the program can become unstable and may crash. Finally, in non garbage collected environments, there is a certain degree of overhead and complexity of user-code to track and finalize allocations. Often developers may box themselves into certain designs to provide reasonable assurances that memory leaks will not occur.

In Java, this potential problem is avoided by automatic garbage collection. The programmer determines when objects are created, and the Java runtime is responsible for managing the object's lifecycle. The program or other objects can reference an object by holding a reference to it (which, from a low-level point of view, is its address on the heap). When no references to an object remain, the Java garbage collector automatically deletes the unreachable object, freeing memory and preventing a memory leak. Memory leaks may still occur if a programmer's code holds a reference to an object that is no longer needed—in other words, they can still occur but at higher conceptual levels.

The use of garbage collection in a language can also affect programming paradigms. If, for example, the developer assumes that the cost of memory allocation/recollection is low, they may choose to more freely construct objects instead of pre-initializing, holding and reusing them. With the small cost of potential performance penalities (inner-loop construction of large/complex objects), this facilitates thread-isolation (no need to synchronize as different threads work on different object instances) and data-hiding. The use of transient immutable value-objects minimizes side-effect programming.

Comparing Java and C++, it is possible in C++ to implement similar functionality (for example, a memory management model for specific classes can be designed in C++ to improve speed and lower memory fragmentation considerably), with the possible cost of extra development time and some application complexity. In Java, garbage collection is built-in and virtually invisible to the developer. That is, developers may have no notion of when garbage collection will take place as it may not necessarily correlate with any actions being explicitly performed by the code they write. Depending on intended application, this can be beneficial or disadvantageous: the programmer is freed from performing low-level tasks, but at the same time loses the option of writing lower level code.

Syntax

Main article: Java syntax

The syntax of Java is largely derived from C++. However, unlike C++, which combines the syntax for structured, generic, and object-oriented programming, Java was built from the ground up as an object oriented language. As a result, everything is an object and all code is written inside a class. The exceptions are the intrinsic datatypes (ordinal and real numbers, boolean values, and characters), which are not classes for performance reasons.

Hello world

For an explanation of the tradition of programming "Hello World" see: Hello world program.

Stand-alone application

This is a minimal usage of Java, but it does not demonstrate object-oriented programming well. No object is explicitly created since the keyword new is never used.

// Hello.java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, world!"); 
    } 
}

The above example merits a bit of explanation.

• Everything in Java is written inside a class, including stand-alone programs.
• Source files are by convention named the same as the class they contain, appending the mandatory suffix .java. A class which is declared public is required to follow this convention. (In this case, the class is Hello, therefore the source must be stored in a file called Hello.java).
• The compiler will generate a class file for each class defined in the source file. The name of the class file is the name of the class, with .class appended. For class file generation, anonymous classes are treated as if their name was the concatenation of the name of their enclosing class, a $, and an integer.
• The keyword void indicates that the main method does not return any value to the caller.
• The main method must accept an array of String objects. By convention, it is referenced as args although any other legal identifier name can be used. (Since Java 5, the main method can also use varargs (variable arguments), in the form of public static void main(String... args), allowing the main method to be invoked with an arbitrary number of arguments.)
• The keyword static indicates that the method is a static method, associated with the class rather than object instances.
• The keyword public denotes that a method can be called from code in other classes, or that a class may be used by classes outside the class hierarchy.
• All programs in Java begin execution with a public static void main(String[]) method. Stand-alone programs must declare this method explicitly.
• The printing facility is part of the Java standard library: The System class defines a public static field called out. The out object is an instance of the PrintStream class and provides the method println(String) for displaying data to the screen while creating a new line (standard out).
• Standalone programs are run by giving the Java runtime the name of the class whose main method is to be invoked. For example, at a Unix command line java -cp . Hello will start the above program (compiled into Hello.class) from the current directory. The name of the class whose main method is to be invoked can also be specified in the MANIFEST of a Java archive (Jar) file.

Applet

Main article: Java applet

Java applets are programs that are embedded in other applications, typically in a Web page displayed in a Web browser.

// Hello.java
import java.applet.Applet;
import java.awt.Graphics;

public class Hello extends Applet {
   public void paint(Graphics gc) {
      gc.drawString("Hello, world!", 65, 95);
   }    
}

The import statements direct the Java compiler to include the java.applet.Applet and java.awt.Graphics classes in the compilation. The import statement allows these classes to be referenced in the source code using the simple class name (i.e. Applet) instead of the fully qualified class name (i.e. java.applet.Applet).

The Hello class extends (subclasses) the Applet class; the Applet class provides the framework for the host application to display and control the lifecycle of the applet. The Applet class is an Abstract Windowing Toolkit (AWT) Component, which provides the applet with the capability to display a graphical user interface (GUI) and respond to user events.

The Hello class overrides the paint(Graphics) method inherited from the Container superclass to provide the code to display the applet. The paint() method is passed a Graphics object that contains the graphic context used to display the applet. The paint() method calls the graphic context drawString(String, int, int) method to display the "Hello, world!" string at a pixel offset of (65, 95) from the upper-left corner in the applet's display.

<!-- Hello.html -->
<html>
  <head>
    <title>Hello World Applet</title>
  </head>
  <body>
    <applet code="Hello" width="200" height="200">
    </applet>
  </body>
</html>

An applet is placed in an HTML document using the <applet> HTML element. The applet tag has three attributes set: code="Hello" specifies the name of the Applet class and width="200" height="200" sets the pixel width and height of the applet. (Applets may also be embedded in HTML using either the object or embed element, although support for these elements by Web browsers is inconsistent.[4][5])

The host application, typically a Web browser, instantiates the Hello applet and creates an AppletContext for the applet. Once the applet has initialized itself, it is added to the AWT display hierarchy. The paint method is called by the AWT event dispatching thread whenever the display needs the applet to draw itself.

Servlet

Main article: Java Servlet

Java Servlet technology provides Web developers with a simple, consistent mechanism for extending the functionality of a Web server and for accessing existing business systems. Servlets are server-side Java EE components that generate responses (typically HTML pages) to requests (typically HTTP requests) from clients. A servlet can almost be thought of as an applet that runs on the server side—without a face.

// Hello.java
import java.io.*;
import javax.servlet.*;

public class Hello extends GenericServlet {
    public void service(ServletRequest request, ServletResponse response) 
       throws ServletException, IOException {
       response.setContentType("text/html");
       PrintWriter pw = response.getWriter();
       pw.println("Hello, world!");
       pw.close();
    }
}   

The import statements direct the Java compiler to include all of the public classes and interfaces from the java.io and javax.servlet packages in the compilation.

The Hello class extends the GenericServlet class; the GenericServlet class provides the interface for the server to forward requests to the servlet and control the servlet's lifecycle.

The Hello class overrides the service(ServletRequest, ServletResponse) method defined by the Servlet interface to provide the code for the service request handler. The service() method is passed a ServletRequest object that contains the request from the client and a ServletResponse object used to create the response returned to the client. The service() method declares that it throws the exceptions ServletException and IOException if a problem prevents it from responding to the request.

The setContentType(String) method in the response object is called to set the MIME content type of the returned data to "text/html". The getWriter() method in the response returns a PrintWriter object that is used to write the data that is sent to the client. The println(String) method is called to write the "Hello, world!" string to the response and then the close() method is called to close the print writer, which causes the data that has been written to the stream to be returned to the client.

JSP

Main article: JavaServer Pages

JavaServer Pages (JSPs) are server-side Java EE components that generate responses, typically HTML pages, to HTTP requests from clients. JSPs embed Java code in an HTML page. A JSP is compiled to a Java servlet the first time it is accessed. After that the generated servlet creates the response.

// Hello.jsp
<%@ page import="java.util.*" %> 

<%
  String javaVariable = "Hello World";
%>

<%= javaVariable %>

The "<%@ page import="java.util.* %>" directive is converted to a Java import statement.

Java declaration between the two "<% ... %>" delimiters is executed during the response generation.

The content of the Java variable between the two "<%= ... %>" delimiters is embedded in the HTML response.

Swing application

Swing is the advanced graphical user interface library for the Java SE platform.

// Hello.java (Java SE 5)
import java.awt.BorderLayout;
import javax.swing.*;

public class Hello extends JFrame {
   public Hello() {
      super("hello");
      setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      setLayout(new BorderLayout());
      add(new JLabel("Hello, world!"));
      pack();
   }

   public static void main(String[] args) {
      new Hello().setVisible(true);
   }
}

The import statement directs the Java compiler to include all of the public classes and interfaces from the javax.swing package in the compilation.

The Hello class extends the JFrame class; the JFrame class implements a window with a title bar with a close control.

The Hello() constructor initializes the frame by first calling the setDefaultCloseOperation(int) method inherited from JFrame to set the default operation when the close control on the title bar is selected to JFrame.EXIT_ON_CLOSE—this causes the JFrame to be disposed of when the frame is closed (as opposed to merely hidden), which allows the JVM to exit and the program to terminate. Next a new JLabel is created for the string "Hello, world!" and the add(Component) method inherited from the Container superclass is called to add the label to the frame. The pack() method inherited from the Window superclass is called to size the window and layout its contents.

(the above paragraph needs to be modified due to some changes in the code sample, see note 0001. once the paragraph is modified, please remove this text.)

The main() method is called by the JVM when the program starts. It instantiates a new Hello frame and causes it to be displayed by calling the setVisible(boolean) method inherited from the Component superclass with the boolean parameter true. Note that once the frame is displayed, exiting the main method does not cause the program to terminate because the AWT event dispatching thread remains active until all of the Swing top-level windows have been disposed.

Criticism

Main article: Java criticisms

Java was intended to serve as a novel way to manage software complexity. Java technology has delivered reasonably well on this promise. Java does not universally accommodate all programming styles or environments. See Java criticisms for a thorough analysis of common criticisms of the language.

Performance

Java can be perceived as significantly slower and more memory-consuming than natively compiled languages such as C or C++.

In general, interpreted languages require additional instructions to execute, and can potentially run several times slower than directly compiled machine code. There also is a significant overhead in both time and space, since many Java interpreters and runtimes take up many megabytes and take many seconds to start up. This arguably makes small Java utility programs uncompetitive with programs compiled in other compiled languages. To be fair, several tests have indicated that the Java overhead is less noticeable for sophisticated or large Java programs. Also, Java programs' execution speed can benefit from JIT compiler post-passes, but those add additional startup overhead in time and space.

Java's performance has increased substantially since the early versions, and performance of JIT compilers relative to native compilers has in some tests been shown to be quite similar. The performance of the compilers does not necessarily indicate the performance of the compiled code; only careful testing can reveal the true performance issues in any system.

Java programmers have developed technologies that allow Java applications to run faster and use less system resources, producing, as an example, the game RuneScape.

Look and feel

The default look and feel of GUI applications written in Java using the Swing toolkit is very different from native applications. It is possible to specify a different look and feel through the pluggable look and feel system of Swing. Clones of Windows, GTK and Motif are supplied by Sun. Apple also provides an Aqua look and feel for Mac OS X. Though prior implementations of these look and feels have been considered lacking, Swing in Java SE 6 addresses this problem by using more native widget drawing routines of the underlying platforms. Alternatively, third party toolkits such as wx4j or SWT may be used for increased integration with the native windowing system.

Lack of OO purity

Java's primitive types are not objects. Primitive types hold their values in the stack rather than being references to values. This was a conscious decision by Java's designers for performance reasons. Because of this, Java is not considered to be a pure object-oriented programming language. However, as of Java 5.0, autoboxing enables programmers to write as if primitive types are their wrapper classes, and freely interchange between them for improved flexibility.

Single-paradigm language

Java is predominantly a single-paradigm language. However, with the addition of static imports in Java 5.0 the procedural paradigm is better accommodated than in earlier versions of Java.

Resources

Java Runtime Environment

The Java Runtime Environment or JRE is the software required to run any application deployed on the Java Platform. End-users commonly use a JRE in software packages and Web browser plugins. Sun also distributes a superset of the JRE called the Java 2 SDK (more commonly known as the JDK), which includes development tools such as the Java compiler, Javadoc, and debugger.

Components

• Java libraries that are the compiled byte codes of source code developed by the JRE implementor to support application development in Java. Examples of these libraries are:
  • The core libraries, which include:
    • Collection libraries which implement data structures such as lists, dictionaries, trees and sets
    • XML Parsing libraries
    • Security
    • Internationalization and localization libraries
  • The integration libraries, which allow the application writer to communicate with external systems. These libraries include:
    • The Java Database Connectivity (JDBC) API for database access
    • Java Naming and Directory Interface (JNDI) for lookup and discovery
    • RMI and CORBA for distributed application development
  • User Interface libraries, which include:
    • The (heavyweight, or native) Abstract Windowing Toolkit (AWT), which provides GUI components, the means for laying out those components and the means for handling events from those components
    • The (lightweight) Swing libraries, which are built on AWT but provide (non-native) implementations of the AWT widgetry
    • APIs for audio capture, processing, and playback
• A platform dependent implementation of Java virtual machine (JVM) which is the means by which the byte codes of the Java libraries and third party applications are executed
• Plugins, which enable applets to be run in Web browsers
• Java Web Start, which allows Java applications to be efficiently distributed to end users across the Internet
• Licensing and documentation

APIs

Sun has defined three platforms targeting different application environments and segmented many of its APIs so that they belong to one of the platforms. The platforms are:

• Java Platform, Micro Edition (Java ME) — targeting environments with limited resources,
• Java Platform, Standard Edition (Java SE) — targeting workstation environments, and
• Java Platform, Enterprise Edition (Java EE) — targeting large distributed enterprise or Internet environments.

The classes in the Java APIs are organized into separate groups called packages. Each package contains a set of related interfaces, classes and exceptions. Refer to the separate platforms for a description of the packages available.

The set of APIs is controlled by Sun Microsystems in cooperation with others through the Java Community Process program. Companies or individuals participating in this process can influence the design and development of the APIs. This process has been a subject of controversy.

Licensing

In 2004, IBM and BEA publicly supported the notion of creating an official open source implementation of Java. On November 13, 2006, Sun announced that all of the Java source code will be released entirely under a free software license, the GNU General Public License, by March 2007 . The javac compiler and the hotspot java VM (but not the class library) were released under the GPL on 11 November 2006 .

Extensions and related architectures

The extensions to standard Java are typically in javax.* packages. They are not included in the JDK or JRE. Extensions and architectures closely tied to the Java programming language include:

• Java EE (previously J2EE) (Java Platform, Enterprise Edition—for distributed enterprise applications)
• Java ME (previously J2ME) (Java Platform, Micro Edition—for PDAs and cellular phones)
• JMF (Java Media Framework)
• JNDI (Java Naming and Directory Interface)
• JSML (Java Speech API Markup Language)
• JDBC (Java DataBase Connectivity)
• JDO (Java Data Objects)
• JAI (Java Advanced Imaging)
• JAIN (Java API for Integrated Networks)
• JDMK (Java Dynamic Management Kit)
• Jini (a network architecture for the construction of federated distributed systems)
• Jiro
• Java Card (Java for smart cards)
• JavaSpaces
• JML (Java Modeling Language)
• JMI (Java Metadata Interface)
• JMX (Java Management Extensions)
• JSP (JavaServer Pages)
• JSF (JavaServer Faces)
• JNI (Java Native Interface)
• JXTA (Open Protocols for Peer-to-Peer (P2P) Virtual Network)
• Java 3D (A high level API for 3D graphics programming)
• JOGL (Java OpenGL—A low level API for 3D graphics programming, using OpenGL)
• LWJGL (Light Weight Java Game Library—A low level API providing access to OpenGL, OpenAL and various input devices)
• OSGi (Dynamic Service Management and Remote Maintenance)

See also

• .properties
• C to Java Virtual Machine compilers
• Classpath (Java)
• Comparison of C# and Java
• Comparison of Java and C++
• Comparison of programming languages
• Java applet
• Java Community Process
• Join Java programming language
• Java keywords
• Java platform
• Java Platform, Standard Edition (Java SE, J2SE)
• Java syntax
• Java User Group
• Java virtual machine
• JavaOne
• JavaOS
• Javapedia

Lists

• Java development tools
• Java platform software
• List of Java IDEs
• List of Java virtual machines
• List of Java APIs
• List of Java scripting languages

References

• Jon Byous, Java technology: The early years. Sun Developer Network, no date [ca. 1998]. Retrieved April 22, 2005.
• James Gosling, A brief history of the Green project. Java.net, no date [ca. Q1/1998]. Retrieved April 22, 2005.
• James Gosling, Bill Joy, Guy Steele, and Gilad Bracha, The Java language specification, third edition. Addison-Wesley, 2005. ISBN 0-321-24678-0 (see also online edition of the specification.
• Tim Lindholm and Frank Yellin. The Java Virtual Machine specification, second edition. Addison-Wesley, 1999. ISBN 0-201-43294-3 (see also online edition of the specification).

External links

Sun

• Official Java home site for IT, developers, etc
• Official Java home site non-technical / home-use
• The Java Language Specification, Third Edition Authoritative description of the Java language (also available online)
• Java SE 19 API Javadocs
• Sun's tutorial on Java Programming
• Original Java whitepaper, 1996
• Test your Java VM
• Free and Open Source Java

Java Specification Requests

There are several JSRs related to the Java Language and core API packages.

• JSR 14 Add Generic Types To The Java Programming Language (J2SE 5.0)
• JSR 41 A Simple Assertion Facility (J2SE 1.4)
• JSR 47 Logging API Specification (J2SE 1.4)
• JSR 51 New I/O APIs for the Java Platform (J2SE 1.4)
• JSR 59 J2SE Merlin Release Contents (J2SE 1.4)
• JSR 121 Application Isolation API (not yet included)
• JSR 133 Java Memory Model and Thread Specification Revision (J2SE 5.0)
• JSR 166 Concurrency Utilities (J2SE 5.0)
• JSR 175 A Metadata Facility for the Java Programming Language (J2SE 5.0)
• JSR 176 J2SE 5.0 (Tiger) Release Contents (J2SE 5.0)
• JSR 201 Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import (J2SE 5.0)
• JSR 203 More New I/O APIs for the Java Platform ("NIO.2") (Java SE 7)
• JSR 204 Unicode Supplementary Character Support (J2SE 5.0) – support for Unicode 3.1
• JSR 270 Java SE 6 ("Mustang") Release Contents (Java SE 6)
• JSR 275 Physical Units/Quantities Support (Java SE) (reference implementation from JScience)
• JSR 308 Annotations on Java Types (Java SE 7)
• JSR 901 Java Language Specification (J2SE 5.0)

Resources

• developerWorks Java Zone—Java resource community
• JavaAlmanac.com The Java Developers Almanac 1.4.
• Javapedia project
• The Java.net Wiki
• JSourcery - Java Source Code Search Engine and Javadocs
• Computer-Books.us A collection of Java books available for free download
• JavaRSS.com Portal of Java websites
• JavaWhat.com Java resource directory, Java API Specifications, Articles, Tutorials, latest Java News.
• Barry Wagner's site A Java tutorial
• Java at CodeCodex A wiki collection of Java source code
• JavaRanch - Articles and discussion forums
• KickJava - Java API by Examples
• JavaWorld (how-to articles, tutorials, news)

History

• Java™ Technology: The Early Years
• A Brief History of the Green Project
• "Java: The Inside Story" (SunWorld article by Michael O'Connell)
• Java Was Strongly Influenced by Objective-C
• The Java Saga
• The Java Platform: Five Years in Review
• A history of Java

Java Implementations

Proprietary:

• IBM JDK from IBM
• BEA Systems JRockit JVM from BEA Systems
• Blackdown Java for Linux, includes Mozilla plugin

Open source:

• SUN JDK from SUN
• GNU Classpath from GNU - currently being merged with libgcj of the GNU Compiler for Java
• Apache Harmony (see Harmony) an Apache Software Foundation proposed implementation of the Java programming language, starting with J2SE 5.0

Criticism

• Free But Shackled—The Java Trap, by Richard Stallman, April 12, 2004. (James Gosling's response)
• Is Java the language you would have designed if you didn't have to be compatible with C?, by Bjarne Stroustrup
• Softpanorama Java Critique Page: Java vs Scripting Languages, by Nikolai Bezroukov
• Java's Cover by Paul Graham, April 2001
• The Perils of JavaSchools by Joel Spolsky (criticism of the use of Java to teach computer science in college)
• How Java’s Floating-Point Hurts Everyone Everywhere, by W. Kahan and Joseph D. Darcy at the ACM 1998 Workshop on Java for High–Performance Network Computing