Package com.ibm.streams.function.model
See: Description
-
Annotation Types Summary Annotation Type Description Function Declare an SPL Java native function.
Package com.ibm.streams.function.model Description
The typical steps to create an SPL Java native function in an SPL toolkit are:
- Annotate a method with the
Functionannotation. - Optionally, annotate the containing class with the
ToolkitLibrariesannotation. - Compile the Java class containing the method.
- Package the class and its nested classes in a jar file in
liborimpl/libwithin the toolkit. - Index the toolkit.
Methods annotated with @Function define SPL Java native
functions in an SPL toolkit. The native functions are created
when the toolkit is indexed, which occurs by running spl-make-toolkit.
Toolkit indexing may be explicit, by executing spl-make-toolkit,
or implicit through the SPL compiler sc or Streams Studio.
A Java method annotated with @Function defines one or more
SPL native functions during toolkit indexing
if its class file is in one of these locations relative to the root directory
of the toolkit (the value passed as the -i argument to spl-make-toolkit):
- Contained in a jar file within
liborimpl/lib. The jar file must have the suffix.jaror.JAR. - The class directory
impl/java/bin(in its correct package based sub-directory).
The class must have been compiled with annotation processing enabled using
the annotation processors defined by the jar file com.ibm.streams.operator.jar.
This annotation processing occurs automatically when using a Java compiler or Streams Studio.
The annotation processing creates a nested class for the class containing the annotated
method, with the class name addition being $StreamsModel. When creating a jar file
containing classes for annotated methods, these nested classes must be included.
Toolkit indexing creates SPL native function definitions from these nested classes.
This is similar to including nested classes created by anonymous inner classes.
Typically creating a jar file includes all classes within a package and thus no
special action is required.
Toolkit indexing creates SPL artifacts under the native.function
directory of the directory for the SPL namespace of the native function. The namespace
for a native function is defined according to the namespace() element or
the package annotation Namespace.
The generated artifacts include:
- The model file
javaFunction.xmlfor the SPL Java native functions in the namespace. - A C++ header file containing code to call the Java methods from SPL
The
native.function directory may also contain manually generated SPL C++ native functions,
represented by the function model file function.xml.
A single ClassLoader is created for each toolkit. It contains:
- Jar files in
libandimpl/libthat contain a class with a method annotated with@Function. - The class directory
impl/java/binif it contains a class with a method annotated with@Function. - Jar files and class directories added with
@ToolkitLibraries.
impl/java/bin within the class loader is not defined.
Classes containing SPL Java native functions are loaded using this class loader. If additional jars are required in the class search path, they can be specified by using one of the following methods:
- Use the
ToolkitLibrariesannotation to annotate the class and specify the required paths. - Package the class in a jar file where the jar file has
a
Class-Pathmanifest entry that references the required jars.
opt and a jar file
in lib would reference them using a relative path starting
with ../opt/.
The Java Operator API classes and the dependent jars are available
to SPL Java native functions at runtime.
Methods may use the SPL logging facilities of the Java Operator API,
using Java platform logging or Apache Log4j.
Methods do not have access to the processing element or operator context.
- Since:
- InfoSphere® Streams Version 3.2