>> 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.
>>
> It's ugly, but to use "int" (instead of java.lang.Integer) one will need
> to explicit specify it, so he will (must) be aware of this.

Rather oposite - int is more natural than java.lang.Integer and I do not
know how will it work with autoboxing. But anyway it is out of our
control, so we don't need to worry about it.

> And do you have something related to triggers? AFAIK, support for Java
> triggers in Oracle is inexistent. One need to write a PL/SQL trigger
> that calls an external procedure. This design limits everything good an
> external trigger may do, like working with all fields (old and new) from
> the table.

There is no standard there so we are free here.

We had some basic support for it, but it was not carefully designed - we
had an object that allowed to access to the trigger context information
(see that PDF in files section). It worked. I do not know whether Red
Soft kept it in their version now. In the discussions with Vlad and
Dmitry we have assigned a low prio to it.

From my Java developer POV I would feel good if:

a) there is some interface like TriggerContext that allows me to get the
name of the table, trigger action, new and old values, optionally access
to context (e.g. rdb$get_context, rdb$set_context, CURRENT_USER and so
on) and allows me to set the new values.

b) correctly handles throwing exceptions to cancel the action.

c) the method declaration is very simple, e.g.:

public static void
myLoggingTrigger(org.firebirdsql.jdbc.FirebirdTriggerContext ctx) {
someLog.debug("Trigger for table " + ctx.getTableName() + " action
" ...);
}

Roman