Re: client API

From: Bill de hOra <>
Date: Mon, 20 Aug 2007 22:20:20 +0100

Patrick Mueller wrote:
> I searched the list for thoughts on 'client interfaces' concerning this
> JSR, and didn't see anything. The spec currently lists 'client' support
> as a non-goal.
> That's a little worrying to me. Because it seems like 'client' side
> interfaces should somehow be able to flow from the server side
> definition, and if there's noone thinking about this, that might end up
> being a harder job than it otherwise would be, once this JSR is baked.
> For example, if the service interfaces were annotated / described on
> Java interfaces, instead of classes, you could easily imagine that the
> interface could be used on the client as well. For instance, via Proxy.
> Things get tricky when wanting to describe a stream on either end of the
> message; and figuring out how to make an invocation asynchronous and
> cancellable on the client side might impact the method signatures in
> various ways (constraining the types further; addinging some kind of
> context/handler parameter).

I don't see tying up client and server APIs as being desirable for this
JSR. Perhaps I misunderstand, but isn't this a job for the current
RMI/Corba et al APIs?

> It won't be simple. But it would be quite valuable.
> Before you say "but Java is primarily used on the server; there aren't
> that many clients that will need this", I'll point out (per my previous
> note) J2ME. Sure would be nice to have a simplish RESTy framework for
> my phone-based apps.

Yes it would. But that doesn't mean the client APIs can't land later.