Better performance of Java table routines

The existing Db2 interface for developing table functions in Java programming language is not designed for performance, because:
(a) It requires a separate native (JNI, e.g. Java-to-C) call for setting each field value for each output row
(b) It implies a separate C-to-Java call for each output row.
.
Java-to-C and C-to-Java calls are very expensive, and although it is not possible to completely avoid them, one of the important targets for performance tuning is to minimize the number of such calls.
.
The possible approach to minimize the expensive calls is to create the alternate to the current COM.ibm.db2.app.UDF base class, with the following improvements:
(1) Change all set(...) methods to non-native final, caching the data in some Java data structure (Map or ArrayList)
(2) Change all the get*() methods to non-native final, making the necessary data available in the Java data structures at the first call (e.g. if the data is not available, call the JNI method, otherwise use the cached copy).
(3) Add the method nextRow(), which will back the current row of values to some data structure (ByteArrayOutputStream?). If this structure exceeds the limit, push the pack of rows to private JNI method, which will send them for processing to the Db2 engine.
.
With those changes, small output tables in most cases will require only three expensive calls:
- the instantiation of UDF implementation class;
- actual call to the UDF implementation method;
- final call to the internal method returning the pre-packed set of rows.