[Home]Java API

HomePage | Recent Changes | Preferences

The Java API is an extensive collection of library routines (written in the Java programming language or in native code) that perform basic tasks such as GUI display and manipulation, sorting and countless others.

The libraries make it considerably easier to program in Java than in C++, according to some software development methodologists; however, other experts attribute the difference primarily to the presence of garbage collection because common libraries for other languages often have similar function to the Java API.

Sun holds complete legal control through the "Java Compatible" trademark over the APIs that all Java platforms must support. This helps insure high consistency between platforms, at the cost of decreased freedom. As of Java Development Kit v1.3, the various APIs are:

General APIs


Routines for normal input and output. This includes streams and filehandling.


Catch-all access to the internals of the language, as well as some information on the underlying native system. Classes in java.lang are always available to the programmer, without needing a special import declaration at the beginning of a sourcecode file.


Special routines for interacting with the garbage collector. For example, one can create a weak reference, which allows one to refer to an object, without preventing the garbage collector from cleaning it up. This is useful in caches, where if nothing else refers to an object held by the cache, the garbage collector may clean it up at whim.


Routines for using the [Reflection API]?. The main use of Reflection is to call classes and methods just by knowing their names. This supports very dynamic programming, at the cost of not having safe compile-time checks to see if the class actually exists.


Numerical routines.


Special IO routines for networks. This includes the ability to easily request files over HTTP, as well as other common transactions.


Parsing routines for strings. Support for different human-readable languages and locale-specific parsing is also included.


Routines for useful data structures. These data structures aggregate objects, with varying useful properties. Also includes the Collections API, which is a very organized way to handle data structures, influenced heavily by the Design Patterns community.

More specialized APIs


Routines to create applets. Applets allow applications to be downloaded over a network and run within a guarded sandbox. Security restrictions may be applied to applets, so they are not allowed to execute potentially hostile code from within the sandbox. A developer may apply a [digital signature]? to an applet to label it as "safe," removing most of the restrictions, but this typically requires the developer to pay hundreds of US dollars a year to a certificate issuing agency such as Thawte or Entrust.


Routines to call code dynamically, using the Reflection API.


The Abstract Windowing Toolkit contains routines to support basic GUI operations. These GUIs use basic windows from the underlying native system. Many independent implementations of the Java API (such as the GNU project's libgcj?) implement everything but AWT, as AWT is not at all necessary for most server-side applications of Java technology.


Swing is a collection of routines that build upon java.awt. It uses 2D drawing routines to exercise greater control over new windows than the underlying native platform normally allows. One cost of this flexibility is that Swing elements may not exist outside of java.awt windows.

Swing is a very rich system in its own right. There is support for "look and feels," so that widgets in the GUI can imitate those from the underlying native system (except when IP rights force workarounds, as noted in the Legal Issues section), or a completely fictional one. Also, design patterns permeate the system, especially a modified model-view-controller? pattern, so programming is done cleanly, with good seperation of function from appearance. However, one inconsistency is that (as of JDK 1.3) fonts are drawn by the underlying native system, and not by Java. This makes it difficult to have utter, complete control of text size, though workarounds exist such as drawing fonts as application-supplied bitmaps. In general, layouts should be used, which keep elements within a GUI aesthetically consistent despite minor variations between platforms.

Legal Issues

In the corporate programming culture, legal issues surrounding Intellectual Property often complicate technical issues. This fact of life is especially apparent with regard to the Java API.

For example, the Swing API often imitates the underlying native platform's GUI, using perfectly cross-platform code. This way, users (ideally) feel comfortable and unaware they're working on a non-native platform, without Sun needing to pollute Swing with native code. However, the native system's copyright or trademark owner may demand that the look be implemented in terms of the underlying native widgets, as in the case of the Aqua look and feel in Apple's Mac OS X. Apple considers Aqua to be a competitive advantage, and desires the look and feel to be confined to their operating system.

HomePage | Recent Changes | Preferences
This page is read-only | View other revisions
Last edited December 13, 2001 1:36 am by Forgotten gentleman (diff)