qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <aidan.skin...@gmail.com>
Subject Re: IKVMing the Java client for .Net
Date Mon, 02 Feb 2009 16:23:36 GMT
On Wed, Jan 28, 2009 at 8:01 PM, Robert Greig <robert.j.greig@gmail.com> wrote:

> 2009/1/23 Aidan Skinner <aidan@apache.org>:
>> Traditionally, the approach to writing the .Net client has been to
>> transliterate the Java client by hand and slap a random API on top of
>> that. That seems like a bit of a waste of effort to me. I was thinking
>> about using IKVM to load the Java client as a library for the
>> AMQP-level bits and write a native C# implementations of WCF etc. that
>> used that.
>> This has the benefit of using an existing, tested client
>> implementation, reducing the amount of work that needs done and would
>> help us seperate the AMQP specific bits of the Java client out from
>> the JMS specific bits. It also means that the whole client is running
>> in managed code, which is good.
>> What do people think?
> This is something we considered a while ago when pondering the very
> first .NET client. At the time it was scuppered because IKVM did not
> support NIO.
> I definitely think it's worth looking at again if IKVM now supports
> enough API to make it feasible.

IKVM should support all of the JDK 6 API now, it uses OpenJDK (nee GNU
Classpath), and ships java.nio in it's core package, so we might be
able to get away without too many extra bits and pieces.

> I tend to agree that we'd need to build .NET stuff by hand on top
> since in a raw Java API there will be things that are not idiomatic in
> .NET - e.g. no use of events, or capitalisation of method names etc.

Totally. Having something which feels natural is really important.

- Aidan
Apache Qpid - World Domination through Advanced Message Queueing

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message