Type Safe handlers and filters

[Brian McCallister <br...@skife.org>]

For the Java 5 dependent branches, it would be awfully nice if we were  
to make IoHandler and IoFilter type safe with regard to received  
messages.

This can be done two ways -- the first is mere decoration -- you add a  
type parameter for the message argument:

interface IoHandler<In> {
     messageReceived(IoSession session, In msg);
     ...
}

interface IoFilter<In, Out> {
     messageReceived(NextFilter<Out>, IoSession session, In msg);
}

In the "Decoration" approach the type is ignored at runtime and just  
becomes an implicit cast. This lets you type what comes in as  
documentation, at least.

A stronger approach would be to explicitly check the generic type via  
reflection and raise an exception at bind() or connect() time. In this  
case the In and Out types for the filter chain would be compared for  
compatibility, and the final out on the filter chain compared to the  
In on the handler. This would allow for raising an illegal state  
exception describing the message type problem as early as possible.  
Once running implicit casts are used for actual dispatch so as not to  
impact performance.

Thoughts?

-Brian

Re: Type Safe handlers and filters

[Brian McCallister <br...@skife.org>]

On Oct 24, 2007, at 8:42 PM, Trustin Lee wrote:

> Do we need Out parameter for IoFilter and NextFilter?  I thought we
> don't.  Please let me know if I am missing something.

Only needed for a check at chain modification time. The key would be  
that you need to know what comes out of a filter in order to test if  
it matches what goes into the next.

-Brian

Re: Type Safe handlers and filters

[Trustin Lee <tr...@gmail.com>]

Hi Brain,

Long time no talk!  And thanks for raising the forgotten yet important
issue.  :)

On 10/25/07, Brian McCallister <br...@skife.org> wrote:
> For the Java 5 dependent branches, it would be awfully nice if we were
> to make IoHandler and IoFilter type safe with regard to received
> messages.
>
> This can be done two ways -- the first is mere decoration -- you add a
> type parameter for the message argument:
>
> interface IoHandler<In> {
>      messageReceived(IoSession session, In msg);
>      ...
> }
>
> interface IoFilter<In, Out> {
>      messageReceived(NextFilter<Out>, IoSession session, In msg);
> }

Do we need Out parameter for IoFilter and NextFilter?  I thought we
don't.  Please let me know if I am missing something.

> In the "Decoration" approach the type is ignored at runtime and just
> becomes an implicit cast. This lets you type what comes in as
> documentation, at least.
>
> A stronger approach would be to explicitly check the generic type via
> reflection and raise an exception at bind() or connect() time. In this
> case the In and Out types for the filter chain would be compared for
> compatibility, and the final out on the filter chain compared to the
> In on the handler. This would allow for raising an illegal state
> exception describing the message type problem as early as possible.
> Once running implicit casts are used for actual dispatch so as not to
> impact performance.

Because a filter chain can be modified at any time, such kind of
sanity check must be done whenever filter chain is modified (i.e. when
a filter is added or removed.)

Moreover, if the Out parameter of IoFilter is just for checking type
safety, it should be removed IMHO because we can still rely on JVM for
type safety, which will be found very easily in integration test time.

Also, there was a similar discussion:

https://issues.apache.org/jira/browse/DIRMINA-372

No conclusion yet.  However, people seem to prefer to retain the
current IoHandler and IoFilter interface.  Instead, Niklas's idea is
gaining attraction.  WDYT?

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Type Safe handlers and filters

[peter royal <pr...@apache.org>]

On Oct 24, 2007, at 1:56 PM, Brian McCallister wrote:
> A stronger approach would be to explicitly check the generic type  
> via reflection and raise an exception at bind() or connect() time.  
> In this case the In and Out types for the filter chain would be  
> compared for compatibility, and the final out on the filter chain  
> compared to the In on the handler. This would allow for raising an  
> illegal state exception describing the message type problem as early  
> as possible. Once running implicit casts are used for actual  
> dispatch so as not to impact performance.
>
> Thoughts?

sounds great! and of course you know the drill... patches welcome! :)

-pete


-- 
proyal@apache.org - http://fotap.org/~osi