There are two types of Java programming language application programming interfaces (APIs):

• The official core Java API, contained in the Android (Google), SE (OpenJDK and Oracle), MicroEJ (IS2T). These packages (java.* packages) are the core Java language packages, meaning that programmers using the Java language had to use them in order to make any worthwhile use of the Java language.
• Optional APIs that can be downloaded separately. The specification of these APIs are defined according to many different organizations in the world (Alljoyn, OSGi, Eclipse, JCP, E-S-R, etc.).

The following is a partial list of application programming interfaces (APIs) for Java.

APIs

Following is a very incomplete list, as the number of APIs available for the Java platform is overwhelming.

Rich Client platforms

• Eclipse Rich Client Platform (RCP)
• NetBeans Platform

Office_compliant libraries

• Apache POI
• Aspose
• JXL - for Microsoft Excel
• JExcel - for Microsoft Excel

Compression

• LZMA SDK, the Java implementation of the SDK used by the popular 7-Zip file archive software (available here)

JSON

• Jackson (API)

Game engines

• Slick
• jMonkey Engine
• JPCT Engine
• LWJGL

Real-time libraries

Real time Java is a catch-all term for a combination of technologies that allows programmers to write programs that meet the demands of real-time systems in the Java programming language.

Java's sophisticated memory management, native support for threading and concurrency, type safety, and relative simplicity have created a demand for its use in many domains. Its capabilities have been enhanced to support real time computational needs:

• Java supports a strict priority based threading model.
• Because Java threads support priorities, Java locking mechanisms support priority inversion avoidance techniques, such as priority inheritance or the priority ceiling protocol.

To overcome typical real time difficulties, the Java Community introduced a specification for real-time Java, JSR001. A number of implementations of the resulting Real-Time Specification for Java (RTSJ) have emerged, including a reference implementation from Timesys, IBM's WebSphere Real Time, Sun Microsystems's Java SE Real-Time Systems,^[1] Aonix PERC or JamaicaVM from aicas.

The RTSJ addressed the critical issues by mandating a minimum (only two) specification for the threading model (and allowing other models to be plugged into the VM) and by providing for areas of memory that are not subject to garbage collection, along with threads that are not preemptable by the garbage collector. These areas are instead managed using region-based memory management.

Real-Time Specification for Java

The Real-Time Specification for Java (RTSJ) is a set of interfaces and behavioral refinements that enable real-time computer programming in the Java programming language. RTSJ 1.0 was developed as JSR 1 under the Java Community Process, which approved the new standard in November, 2001. RTSJ 2.0 is being developed under JSR 282. A draft version is available at JSR 282 JCP Page. More information can be found at RTSJ 2.0

• Javolution

Windowing libraries

The windowing library is a set of classes available in the Streams Processing Language (SPL) Runtime C++ API and the SPL Java™ Operator API. The library is used to implement primitive operators that need windows following the SPL window semantics. Using the windowing library provides a consistent window policy semantic across operators, and simplifies the operator implementation.

SPL offers both tumbling and sliding windows. Both types of windows keep all the incoming data in memory until its tuple eviction policy triggers. Use the SPL support for windows when the functionality required by the primitive operator can be built using the semantics provided by SPL window constructs.

One example operator from the SPL Standard Toolkit that uses the windowing library and syntax is the Aggregate operator. An example operator that buffers recently received tuples but that does not use the windowing library and syntax is the DeDuplicate operator. This action occurs because this operator has different eviction and trigger semantics than the ones provided by SPL. This operator needs to maintain only unique tuples and discards all repeated tuples that are received within a time window.

With the windowing library, developers can specify different eviction and trigger policies but can implement the event handling actions independently of the window policy details. There are a few differences when implementing primitive operators in C++ and Java that take advantage of the SPL window clause.

In the C++ implementation, developers have no obligation to use the window library (the preferred practice is to use library). They are free to use the SPL Operator Code Generation API just to get the specified window policy for a given operator instance. Then, they can generate code using other containers. In addition, developers can check for valid window configurations during code generation time.

In the Java implementation, developers must use the window library. This action can be achieved by registering a class that implements com.ibm.streams.operator.window.StreamWindowListener<T> that handles events generated by a window (com.ibm.streams.operator.window.StreamWindow<T>). This use is required because Java operators are not based on code generation. As a result, windows are automatically managed by the runtime to guarantee SPL window semantics. Developers can check for valid window configurations during runtime by checking the window policy associated to a given input port.

• Standard Widget Toolkit (SWT)

Physics libraries

• JBox2D
• JBullet