Misplaced Pages

Java (programming language)

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by Smyth (talk | contribs) at 11:57, 12 March 2006 (→Recent history: Rewordings). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 11:57, 12 March 2006 by Smyth (talk | contribs) (→Recent history: Rewordings)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Java
File:Java logo.gif
Paradigmobject-oriented
Designed bySun Microsystems
First appeared1990s
Typing disciplinestrong, static
Websitewww.oracle.com/java/
Major implementations
numerous
Influenced by
Objective-C, C++, Smalltalk
Influenced
C#

Java is an object-oriented programming language developed by James Gosling and colleagues at Sun Microsystems in the early 1990s. The language, which was designed to be platform independent, is a derivative of C++ with a simpler syntax, a more robust runtime environment and simplified memory management.

Java is not related to JavaScript, though they have similar names and share a C-like syntax.

History

Early history

Duke, Java's mascot

The Java platform and language began as an internal project at Sun Microsystems in December of 1990. Engineer Patrick Naughton had become increasingly frustrated with the state of Sun's C++ and C APIs (application programming interfaces) and tools. While considering moving to NeXT, Naughton was offered a chance to work on new technology and thus the Stealth Project was started.

The Stealth Project was soon renamed to the Green Project with James Gosling and Mike Sheridan joining Naughton. Together with other engineers, they began work in a small office on Sand Hill Road in Menlo Park, California. They were attempting to develop a new technology for programming next generation smart appliances, which Sun expected to be a major new opportunity.

The team originally considered using C++, but it was rejected for several reasons. Because they were developing an embedded system with limited resources, they decided that C++ demanded too large a footprint and that its complexity led to developer errors. The language's lack of garbage collection meant that programmers had to manually manage system memory, a challenging and error-prone task. The team was also troubled by the language's lack of portable facilities for security, distributed programming, and threading. Finally, they wanted a platform that could be easily ported to all types of devices.

Bill Joy had envisioned a new language combining the best of Mesa and C. In a paper called Further, he proposed to Sun that its engineers should produce an object-oriented environment based on C++. Initially, Gosling attempted to modify and extend C++, which he referred to as C++ ++ --, but soon abandoned that in favor of creating an entirely new language, which he called Oak after the tree that stood just outside his office.

The team worked long hours and by the summer of 1992, they were able to demonstrate portions of the new platform including the Green OS, the Oak language, the libraries, and the hardware. Their first attempt, demonstrated on September 3, 1992, focused on building a PDA device named Star7 which had a graphical interface and a smart agent called "Duke" to assist the user. In November of that year, the Green Project was spun off to become FirstPerson, Inc, a wholly owned subsidiary of Sun Microsystems, and the team relocated to Palo Alto. The FirstPerson team was interested in building highly interactive devices, and when Time Warner issued an RFP for a set-top box, FirstPerson changed their target and responded with a proposal for a set-top box platform. However, the cable industry felt that their platform gave too much control to the user and FirstPerson lost their bid to SGI. An additional deal with The 3DO Company for a set-top box also failed to materialize. Unable to generate interest within the TV industry, the company was rolled back into Sun.

Java meets the Internet

In June and July of 1994, after a three-day brainstorming session with John Gage, James Gosling, Joy, Naughton, Wayne Rosing, and Eric Schmidt, the team re-targeted the platform for the Web. They felt that with the advent of the Mosaic browser, the Internet was on its way to evolving into the same highly interactive medium that they had envisioned for cable TV. As a prototype, Naughton wrote a small web browser, WebRunner, later renamed HotJava.

That year, the language was renamed Java after a trademark search revealed that the name "Oak" was used by a manufacturer of video adaptor cards. The name Java was coined at a local coffee shop frequented by some of the members. It is not clear whether the name is an acronym or not; although some accounts claim that it stands for the names of James Gosling, Arthur Van Hoff, and Andy Bechtolsheim, or Just Another Vague Acronym, it is generally accepted that "Java" does not stand for anything. Lending credence to the idea that Java owes its name to the products sold at the coffee shop is the fact that the first 4 bytes (the so-called "Magic number") of any class file are, in hexadecimal, 0xCAFEBABE.

In October of 1994, HotJava and the Java platform was demonstrated for Sun executives. Java 1.0a was made available for download in 1994, but the first public release of Java and the HotJava web browser came on May 23, 1995, at the SunWorld conference. The announcement was made by John Gage, the Director of Science for Sun Microsystems. His announcement was accompanied by a surprise announcement by Marc Andreessen, Executive Vice President of Netscape, that Netscape would be including Java support in its browsers. On January 9th, 1996, the JavaSoft business group was formed by Sun Microsystems to develop the technology. Two weeks later the first version of Java was released.

Recent history

The ability of web browsers to run Java applets has ensured the continuing visibility of Java to the general public. While Flash is far more widespread for simple interactive animations, Java's power has been applied to more complex applications like Yahoo! Games and more recently, video players from multiple suppliers.

Although Microsoft ceased bundling Java with Windows starting with Windows XP in 2001, most computer manufacturers continue to include Java on their systems. It is also shipped as standard on Apple's MacOS X, as well as most Linux distributions.

On the server side of the Web, Java is more popular than ever, with many websites using JavaServer Pages and other Java-based technologies.

On the desktop, stand-alone Java applications remain relatively rare because of their large overhead. However, with the great advances in computer power in the last decade along with improvements in VM and compiler quality, several have gained widespread use, including the NetBeans and Eclipse Integrated development environments, and file sharing clients such as Limewire and Azureus. Java is also used in the Matlab mathematics program for rendering the user interface and for part of the calculation functionality. Java Swing desktop applications are being developed as an alternative to Microsoft .NET technology.

Version history

Java Web Start, first introduced for J2SE 1.3, allows provisioning applications over the Web by clicking a desktop icon or a link on a website.

The Java language has undergone several changes since JDK (Java Development Kit) 1.0 as well as numerous additions of classes and packages to the standard library. Since J2SE 1.4, the evolution of the Java Language has been governed by the Java Community Process (JCP), which uses Java Specification Requests (JSRs) to proposed and specify additions and changes to the Java platform. The language is specified by the Java Language Specification (JLS); changes to the JLS are managed under JSR 901.

  • J2SE 5.0 (September 30, 2004) — Codename Tiger. (Originally numbered 1.5, which is still used as the internal version number.) Developed under JSR 176, Tiger added a number of significant new language features: press release
    • Generics — provides compile-time (static) type safety for collections and eliminates the need for most typecasts. (Specified by JSR 14.)
    • Metadata — also called annotations, allows language constructs such as classes and methods to be tagged with additional data, which can then be processed by metadata-aware utilities. (Specified by JSR 175.)
    • Autoboxing/unboxing — automatic conversions between primitive types (such as int) and primitive wrapper classes (such as Integer). (Specified by JSR 201.)
    • Enumerations — the enum keyword creates a typesafe, ordered list of values (such as Day.MONDAY, Day.TUESDAY, etc.). Previously this could only be achieved by non-typesafe constant integers or manually constructed classes (typesafe enum pattern). (Specified by JSR 201.)
    • Enhanced for loop — the for loop syntax is extended with special syntax for iterating over each member of any Iterable, such as an array or Collection, using a construct of the form:
void displayWidgets (Iterable<Widget> widgets) {
    for (Widget w : widgets) {
        w.display();
    }
}

This example iterates over the Iterable object widgets, assigning each of its items in turn to the variable w, and then calling the Widget method display() for each item. (Specified by JSR 201.)

  • Java SE 6 — Codename Mustang. As of 2006 this is currently in development under JSR 270. A beta version was released on February 15, 2006 press release and is available at http://java.sun.com/javase/6/. Another beta is expected summer 2006 with the final release in autumn 2006. New builds including enhancements and bug fixes are released approximately weekly. As of this version, Sun replaced the name "J2SE" with Java SE and dropped the ".0" from the version number.
  • Java SE 7 — Codename Dolphin. As of 2006, this is in the early planning stages. Development is expected to begin in spring 2006, with release estimated in 2008.

In addition to the language changes, much more dramatic changes have been made to the Java class library over the years, which has grown from a few hundred classes in JDK 1.0 to over three thousand in J2SE 5.0. Entire new APIs, such as Swing and Java2D, have been introduced, and many of the original JDK 1.0 classes and methods have been deprecated.

Philosophy

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 and borrow the good parts of older object-oriented languages like C++.

Especially for the latter part, however, extensions are sometimes required, like CORBA or OSGi.

Object orientation

The first characteristic, object orientation ("OO"), refers to a method of programming and language design. Although there are many interpretations of OO, one primary distinguishing idea is to design software so that the various types of data it manipulates are combined together with their relevant operations. Thus, data and code are combined into entities called objects. An object can be thought of as a self-contained bundle of behavior (code) and state (data). The principle is to separate the things that change from the things that stay the same; often, a change to some data structure requires a corresponding change to the code that operates on that data, or vice versa. This separation into coherent objects provides a more stable foundation for a software system's design. The intent is to make large software projects easier to manage, thus improving quality and reducing the number of failed projects.

Another primary goal of OO programming is to develop more generic objects so that software can become more reusable between projects. A generic "customer" object, for example, should in theory have roughly the same basic set of behaviors between different software projects, especially when these projects overlap on some fundamental level as they often do in large organizations. In this sense, software objects can hopefully be seen more as pluggable components, helping the software industry build projects largely from existing and well tested pieces, thus leading to a massive reduction in development times. Software reusability has met with mixed practical results, with two main difficulties: the design of truly generic objects is poorly-understood, and a methodology for broad communication of reuse opportunities is lacking. Some open source communities want to help ease the reuse problem, by providing authors with ways to disseminate information about generally reusable objects and object libraries.

Platform independence

File:SwingSet.png
The look and feel of Java Swing GUIs is independent of the platform on which they are running

The second 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 compiling 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 compile 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 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. More sophisticated VMs use dynamic recompilation, in which the VM can analyze the behavior of the running program and selectively recompile and optimise 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 Java Beans, as well as with Embedded systems based on OSGi, using Embedded Java environments.

Automatic garbage collection

One possible argument against languages such as C++ is the burden of having to perform manual memory management. In C++, memory is allocated by the programmer to create an object, then deallocated to delete the object. If a programmer forgets or is unsure when to deallocate, this can lead to a memory leak, where a program consumes more and more memory without cleaning up after itself. Even worse, if a region of memory is deallocated twice, the program can become unstable and will likely crash.

In Java, this potential problem is avoided by automatic garbage collection. Objects are created and placed at an address on the heap. The program or other objects can reference an object by holding a reference to 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, however, can 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. But on the whole, Java's automatic garbage collection makes creation and deletion of objects in Java simpler, potentially safer, and often faster than in C++.

Garbage collection in Java is virtually invisible to the developer. That is, developers may have no notion of when garbage collection will take place as it is not necessarily a function of the code they themselves write.

Criticism

Java was intended to serve as a novel way to manage software complexity. Most consider Java technology to deliver reasonably well on this promise. However, Java is not without flaws, and it does not universally accommodate all programming styles, environments, or requirements.

  • Not all projects or environments require enterprise-level complexity, such as stand-alone websites or sole-proprietorship programmers. Some individuals find Java's self-enforcing complexity management to be overkill.
  • Java is often a focal point of discontent for those who are not enthusiastic about object-oriented programming.
  • Java can be considered a less pure object-oriented programming language than for instance Ruby or Smalltalk because it makes certain compromises (such as the fact that not all values are objects) for performance reasons.
  • Java programs may have lower performance than those written in other languages that are compiled directly into machine code for the following reasons:
    • Java byte code must either be interpreted at run time by a virtual machine instead of running directly on the computer's hardware, or must be compiled at load time or runtime into machine code. Interpretation is slower than native exectution, and compilation at load time or runtime has an initial performance penalty for the compilation.
    • Java byte code is not optimized to the same extent as the machine code produced by compilers that produce object code targeted to run on a single platform, except when compiled using a JIT compiler or a dynamic compiler which compiles, optimizes, and produces object code targeted to run on a single platform.
    • Java does not support manual inlining of method calls, although many JIT compilers perform this optimization at load time. Dynamic recompilation performed by some JVMs such as Sun's HotSpot JVM provide more inlining than is possible with static manual inlining.
    • The use of a garbage collector to automatically decide when to delete objects adds overhead compared to maunual deallocation. However, with the modern generational garbage collectors used in many JVMs, many applications actually experience performance improvements due to the greater efficiency of the underlying memory management algorithms.
  • As an established technology, Java inevitably invites comparison with contemporary languages such as C++, C#, Python, and others. Commenting upon Java's proprietary nature, supposed inflexibility to change, and growing entrenchment in the corporate sector, some have said that Java is "the new COBOL". Many consider this to be a somewhat hyperbolic assertion, although it does allude to some legitimate concerns with Java's prospects for the future. An appropriate comparison would be ALGOL60, the Java of its day back in the mainframe era, which lost its way after it over-inflated into ALGOL68.

Language

  • The distinction between reference types and primitive types may be viewed as artificial by programmers who are familiar with languages such as Smalltalk, Python and Ruby, where everything is an object.
  • Conversely, C++ programmers can become confused with Java because in Java primitives are always automatic variables and objects always reside on the heap, whereas C++ programmers are explicitly given the choice in both cases by means of operator new.
  • Java code is often more verbose than code written in other languages. This is due in part to its frequent type declarations and manual casts. It is also due to the lack of operator overloading (see below) and the relatively simple syntax. However, J2SE 5.0 introduced Generics which addresses the issue of manual casts, as well as new syntax for for-loops which also reduces verbosity.
  • Unlike C++, Java does not support user-definable operator overloading; however, this is a deliberate design decision, seen by many as a plus because of the well-known readability and maintenance problems experienced with operator overloading.
  • Java is predominantly a single-paradigm language. Historically, it has not been very accommodating of paradigms other than object-oriented programming. As of J2SE 5.0, the procedural paradigm is somewhat better supported in Java with the addition of the ability to import static methods and fields so that they can be used globally as one could do in, for example, C.
  • Java's support of text matching and manipulation is not as strong as languages such as Perl, Ruby, or PHP, although regular expressions were introduced in J2SE 1.4.

Library

The look and feel of GUI applications written in Java using the Swing platform is often different from native applications. While programmers can choose to use the AWT toolkit that displays native widgets (and thus look like the operating platform), the AWT toolkit is unable to meet advanced GUI programming needs by wrapping around advanced widgets and not sacrificing portability across the various supported platforms, each of which have vastly different APIs especially for higher-level widgets. The Swing toolkit, written completely in Java, avoids this problem by reimplementing widgets using only the most basic drawing mechanisms that are guaranteed available on all platforms. The drawback is that extra effort is required to resemble the operating platform. While this is possible (using the GTK+ and Windows Look-and-Feel), most users do not know how to change the default Metal Look-And-Feel to one that resembles their native platform, and as a result they are stuck with Java applications that look radically different from their native applications. Of note however, Apple Computer's own optimized version of the Java Runtime, which is included within the Mac OS X distribution, by default implements its "Aqua" Look-And-Feel, giving Swing applications a similar appearance to native Mac software.

Some parts of the standard Java libraries are considered excessively complicated, or badly designed, but cannot be changed due to the need for backward compatibility.

Performance

It is misleading to make any generalization about the performance of Java programs in general, because runtime performance is affected much more by the quality of the compiler or JVM than by any intrinsic properties of the language itself.

There are a few language requirements which incur an unavoidable time penalty, although these features are not unique to Java. Among these are array bounds checking, run-time type checking, and virtual function indirection. Garbage collection can have a positive or negative impact, or no discernable impact at all, on performance depending upon the garbage collector implementation and the characteristics of the application's use of objects.

Relative performance of JIT compilers as compared to native compilers can be quite close, and is often a subject of debate. The JIT stage may be time-consuming, which is inconvenient for applications that are short-lived and/or contain large amounts of code. Once this is done, however, the performance of the program can be comparable to that achieved by a native compiler, even on numerical tasks. In addition, JITs can exploit information from the runtime environment to guide more effective transformations, such as profile-directed inlining. Dynamic recompilation, as provided by Sun's HotSpot JVM, can exceed the performance of the static compilation available in most other languages by exploiting information that is only available at runtime.

Java was designed with an emphasis on security and portability, and does not support direct access to the machine architecture and address space. Applications can drop down to native code to access these features using the Java Native Interface (JNI).

Syntax

Main article: Java syntax

The syntax of Java is largely derived from C++. But unlike C++, which combines the syntax for procedural and object-oriented programming, Java was built from the ground up to be fully object-oriented. Everything in Java is an object (with a few exceptions), and everything in Java is written inside a class.

Hello world

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

Stand-alone application

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

The above example merits a bit of explanation for those accustomed to languages with inherently relaxed security, weak typing, and weak object orientation.

  • 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.
  • Programs to be executed as stand-alone must have a main() method.
  • The keyword void indicates that the main method does not return anything.
  • 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.
  • The keyword static indicates that the method is a class method, associated with the class rather than object instances. Main methods must be static.
  • 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. Main methods must also be public.
  • 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 (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

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);
    }    
}

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

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) in the applet's display.

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.)

Servlet

Java servlets are server-side Java EE components that generate responses to requests from clients. 

// 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.

Swing application

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

// Hello.java
import javax.swing.*;

public class Hello extends JFrame {
    Hello() {
        setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
        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 WindowConstants.DISPOSE_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 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, exitting 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.

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

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:

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.

In 2004, IBM and BEA publicly supported the notion of creating an official open source implementation of Java but as of 2006, Sun Microsystems has refused that.

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
  • 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

Lists

References

Notes

  1. The device was named Star7 after a telephone feature activated by *7 on a telephone keypad, which enabled users to answer the telephone anywhere.

External links

Sun

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 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 901 Java Language Specification (J2SE 5.0)

Tutorials

Resources

History

Alternatives

Criticism

Template:Major programming languages small

Categories: