[zeromq-dev] Initial support for zmq_poll() under Java

[Martin Sustrik]

Hi Gonzalo,

see my comments inlined:

>> I have completed initial support for zmq_poll() in the Java binding.
> For
>> now it only supports ZMQ sockets. I will send a reply to this e-mail
>> explaining the interface and implementation issues.
> 
> Now the details of this implementation...
> 
> The function is a member of org.zmq.Context and looks like this:
> 
>     public native long poll (Socket[] socket,
>                              short[] event,
>                              short[] revent,
>                              long timeout);
> 
> It receives four arrays (which must match in size) with the sockets to
> poll, the events to poll for in each socket, a place to receive the
> results and a timeout in microseconds.
> 
> Issue #1: it is difficult to pass a single array of structures because
> accessing such array from JNI is complex. I think it CAN be done, but I
> decided to work on a simpler way first and later improve things, after
> other eyes have had the chance to look at the code.

Right. Let's mark the poll function as experimental so that people are 
aware that the prototype may change in the future.

> Issue #2: I would have liked to use an interface such as Set instead of
> arrays, but accessing those from JNI seems to be even more complex or
> even impossible.

Same as above.

> Issue #3: adding Java / plain sockets to this method is not easy, may
> not be portable and may even be impossible. For one thing, if you have a
> java.net.Socket object, there is no portable way to access the
> underlying socket descriptor. The only way I found is a hack that works
> for Sun's JVM and is described here (post #2):
> 
> http://www.velocityreviews.com/forums/t140746-passing-java-socket-fd-to-
> c-hack.html
> 
> The second challenge is that Java has several different classes of
> Sockets; we might ignore some of them, but I think we would want to
> support at least java.net.Socket and java.net.ServerSocket.
> Unfortunately, these classes share no common ancestor, so it is not
> possible to pass them to Context.poll() in a single array, unless we use
> an Object array and do some casting. And the way to get at the
> underlying socket descriptor might vary across these classes too.
> 
> In summary, this is as far as I can get, for now, with poll under Java.
> I will submit the patch soon, but if anybody has comments, criticism or
> suggestions, they are welcome.

Integrating native sockets is not a priority IMHO. First let's get 
polling on 0MQ sockets functional, then care about native sockets.

However, AFAIU, what we'll need to do then is to make an decision 
(arbitrary one) on how to access underlying fds as there's no 
stadardised way to do this.

For example we can say: Any object that wants to be 0MQ-pollable has to 
have 'fd' property exposing underlying file descriptor.

Afterwards, people are free to submit patches to their favourite Java 
implementations/socket types etc.

Few more points:

1. You've added documentation to individual functions. These can be 
processed by javadoc, right? In case you choose to offload the binding 
from 0MQ project, generating the docs and placing them somewhere (we can 
upload it for you if needed) would make sense.

2. I still feel that Java API needs some beautification - especially 
when it comes to namespacing. Comapre Java and Ruby examples:

   org.zmq.Socket s = new org.zmq.Socket (ctx, org.zmq.Socket.REP);

   s = ZMQ::Socket.new(ctx, ZMQ::REP);

Thoughts?

Martin