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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
