There are two types of Java programming language application programming interfaces APIs:
The following is a partial list of application programming interfaces APIs for Java.
Following is a very incomplete list, as the number of APIs available for the Java platform is overwhelming.
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:
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, 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.
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
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.