Sheesh, straight into the deep questions.

I think I've answered all but the last of these here.

The last question has an easy answer: I like writing code. Some people like knitting. Other people like shooting animals with high-powered rifles. I like code. A lot. If you're still not happy then I'm not sure what you expect me to say.

This may seem like a strange question. Java's cross-platform, right?

Unfortunately NIO implementations have been plagued with bugs and (in some cases this is worse) inconsistencies across different implementations and platforms. This makes it difficult to write code based on NIO and be sure it works (never mind performs decently) across a range of platforms. There are a range of guidelines scattered throughout the developer community if you're prepared to spend the time digging. RoX does its best to avoid all of the problems I've come across in both testing and general reading.

But to answer the original question, RoX has been tested on Windows XP SP 2 and on Redhat's Fedora Core 4 Linux distro.

You're right, but try coming up with a pronouncable acronym for that lot.

Recently I've spent a lot of time wandering through the quagmire that is the average Java project these days. Write a little SOAP oriented code in Java and you'll understand what I'm talking about. I resent needing 20 to 30 Java libraries in my classpath before my code will even run, never mind do anything useful. I really wanted to keep the set of libraries you needed to use RoX as small as possible.

Log4J is a particular bug-bear. I don't want to suggest it isn't useful, or that there's anything seriously wrong with it. But I do resent having to drag it into each and every project I build. I also don't have a tremendous amount of faith that interfaces will remain compatible from release to release (long experience has taught me how hard it is to do this properly). So when every second library you need in a project requires Log4J, and often different versions of it, you soon run the risk of an incompatibility in the needs of two libraries. Then you either have to roll your own ClassLoader and whip out some hefty black magic, or find a way to replace one of the offending libraries.

The HTTP implementation is motivated by the same requirement, but there was also a fun aspect to it. It was interesting to implement a part of the HTTP spec. And it was a good, real world use-case for the NIO libraries.

In an ideal world, I would have. But I wanted a project that wouldn't drag on forever. I could easily see an XML parser stretching out into weeks of work. And there'd be very little to show for it. Starting with a working XML parser it doesn't take very long before you have a working XML-RPC implementation. I also had very little interest in writing an XML parser. So I conceded this one dependency.

I'm a little paranoid. Life has taught me that gung-ho just doesn't cut it in most production environments. I suspect it will be some time before 1.5 represents the standard Java platform within most production environments. There's also vendor support. It took long enough for 1.4 to be supported by other JVM vendors (and hence on other platforms) that I expect a similar delay for 1.5 (especially given the changes that happened in 1.5). I figure targeting 1.5 limits the usefulness of a library at the moment so that it's not (yet) worth the added "benefits" of developing on 1.5.

To be honest, I haven't really done any significant testing. The testing I have done suggests that RoX performs acceptably. But don't expect it to be blindingly fast.

However, a little thought backed up by some profiling has suggested a few areas might be worth a closer look. In particular work is currently ongoing on a SAX based marshaller (the current marshaller is DOM based which simplifies things considerably at the cost of performance). In addition, a few ideas have been tossed around which might be implemented if the profiler suggests the gains would be worthwhile. However, RoX should scale to large numbers of connections easily. This was the only explicit performance criterion I imposed on this project. RoX's main focus as been ease-of-use rather than speed. If you're that concerned about speed you may want to check the XML in at the door.

I've been involved in a lot of work recently using Ruby. YAML's pretty natural within Ruby. It tends to be a little easier than XML for humans to read and write. It also tends to be somewhat more concise. A close friend and colleague has written a simple YAML library for Java and the intention is to support plugging that library in as a marshalling implementation, making it possible to use RoX as a client-server library that uses YAML as its wire format instead of XML-RPC.

The shorter answer is "because I can".

• There's the Apache XML-RPC library.
• Marquée XML-RPC seems to provide some of what RoX provides (like proxying POJOs) but their async stuff still seems to be based on blocking IO.
• I haven't really looked closely at this implementation but it seems to suggest there's an XML-RPC library lurking in there somewhere.

JavaWorld has a reasonably decent write-up describing how to accomplish some of what RoX gives you. Unfortunately I only discovered this after I'd finished most of RoX but better late than never?