>> a) each public static method can be called;
>> b) input parameters are specified as usual having the desired type (and
>> there is type mapping defined);
>>
> I'm doing this stuff, see below.

Ok.

>> c) output parameters are specified as arrays of the desired type of size
>> 1; the routine itself assigns then the values to that very element of an
>> array and it is then returned into SQL layer.
>>
> Our output parameters (of stored procedures) are different from others
> DBMS. So I think we may use something (ResultSet, for example) different.

Sorry, it must be supported as well.

Like it or not, the SQL/J is supported by Oracle, IBM and Sybase at
least, so there is no other options. The ResultSet is somewhat different
and as extension should be supported too.

> In Oracle, you (always, AFAIK) need to specify the parameter types and
> return type. You can specify types as "int" or "java.lang.Integer".
>
> In the implementation I'm doing, if types are not passed, it
> automatically maps INTEGER to java.lang.Integer.

Correct.

> IMO, we should never
> transform NULL to 0.

It will happen automatically when you use "int" not "java.lang.Integer"
in method declaration and pass null into Java reflection call. So NULL
should always be passed as null and if developers on the other end are
clever enough, they will use java.lang.Integer to be notified about NULLs.

>> Second, the SQL/J tells how to do the database calls from within the
>> Java code. It postulates that using the JDBC URL
>> "jdbc:default:connection"
> In Oracle it's "jdbc:default:connection:" (not the ":" at end).

We can handle both - Jaybird's design allows it (at least it should).

>> one can obtain a database connection within
>> the same context in which the Java routine was called. Then developer
>> can use normal JDBC code to perform queries, etc.
>>
> Already working in my implementation. ;-)

Good :)

>> However, since these two cases looks quite important, we (Evgeny, Vlad
>> and myself) have "extended" the specification to support them. In case
>> of result set it looked obvious to use same JDBC interface as usual,
>> however it does not really matter.
>>
> I think we can support return of java.sql.ResultSet, but we should
> construct (derived from ResultSet) another class to make easy creation
> of selectable procedures that produce rows, like ExternalResultSet from
> FirebirdExternalApi.h. It's very difficult and non-sense to implement
> ResultSet methods to return values.

Yup, this was also implemented in our code, probably there is something
similar in RedSoft's code as well.

Roman