> It shouldn't be. The abstract class ResultSet specifies only the
> API, not the mechanism behind it. An Java implementation of
> external procedures would probably return an implementation of
> ResultSet that navigated the corresponding Java objects with JNI.
> In all likelihood, the Java ResultSet would itself be a Java wrapper
> around the C++ InternalResultSet (also implementation of ResultSet).
> This would give the Java procedure code full access to internal
> engine SQL in the context of the client database attachment.

By requiring this you say one of the following:

- External Java SP gets less featured JDBC implementation (something
like JDBC 1.2 level)

- Two versions of Java accessibility components will have to be kept
in sync - one for public API (currently our lovely ibase.h) and one
for internal API.

I am not sure that I accept any of the above. So, the only possibility
is to have same API for the client and for the server (or you're going
to upgrade your internal JDBC-like interface to be JDBC 3.0 and soon
JDBC 4.0 compatible).

Didn't we agree that public OO API is a nice thing, but is not
applicable to all situations?

How are we going to convince all connectivity component developers to
throw away everything they did till now and to recode the components
for a new API?

Or we are going to maintain a C and C++ APIs for next Firebird versions?

Roman