[zeromq-dev] Java binding proposed changes

Martin Sustrik sustrik at 250bpm.com
Tue Mar 30 18:04:29 CEST 2010


Hi Gonzalo,

> I have been going over the guideline for 0MQ bindings
> (http://www.zeromq.org/guidelines:bindings) and I am convinced there are
> a few changes to be done on the Java binding to bring it into closer
> compliance. They are:
> 
> 1. The ZMQ namespace and 0MQ's constants: the current binding has
> constants under org.zmq.Context (POLL), org.zmq.Socket (lots of them)
> and org.zmq.Poller (POLLIN, POLLOUT and POLLERR). They should all be
> placed under a single ZMQ namespace; how do we do this? One way could be
> to create org.zmq.ZMQ as an empty class with just the constants. Anybody
> can suggest something else?

Wouldn't it be possible to have static ZMQ class with the constants 
_and_ subclasses Context and Socket?

Implementing subclass in JNI can be a bit tricky but I've already done 
it in 0MQ/1.0 Java binding (InboundData subclass) so you can get the 
idea here:

http://github.com/sustrik/zeromq1/tree/master/libjzmq/

> 2. I recently added destroy() methods to Context and Socket, but they
> will be renamed to term() and close(), respectively.
> 
> 3. I will add a socket() function to org.zmq.Context, so that sockets
> will be created by calling this function. They can also be created by
> creating a new org.zmq.Socket object, as it is now. I will also add a
> poller() function.

What will the poller function do?

> 4. I would like to review the use of assert() in the native functions; I
> am not sure whether they should stay the way they are, or they should be
> turned into raising exceptions, so that every single error condition in
> native code ends up being reported to the calling Java code.

The rule of the thumb is: When the problem shouldn't happen - i.e. 
there's a bug in 0MQ of Java binding - assert. If the problem can be 
caused by the user raise an exception.

Martin



More information about the zeromq-dev mailing list