Regarding point #1, you are right: the flags were assigned to a long variable, which was received in the C glue code as a jlong, which was finally cast to an int when being passed into zmq_send() and zmq_recv(). I changed them into int / jint and got rid of the cast.
Regarding point #3, I don't think we should introduce any changes, as per the discussion on the mailing list. Regarding point #2, could you propose a concrete interface for what you mention? I have also implemented the timeout handling in the poll() methods: poll() will behave depending on whether setTimeout() has been called: if yes, it will use that timeout value; if not, it will block indefinitely. poll(timeout) will always honor whatever timeout value it is explicitly receiving. [gs]etTimeOut() methods have been deprecated. Let me know of any comments or suggestions. Gonzalo Diethelm ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Scott Asher Sent: Wednesday, 24 November, 2010 14:30 To: [email protected] Subject: Re: [zeromq-dev] Regarding java binding of 0MQ. You should just break backwards compatibility. The binding should match the C/C++ behavior. BTW, I DID complain about the constants being made private and moved to Poller, but no one listened and it wasn't a big deal. Also, another couple of issues while we're on the Java bindings: 1) (minor) The send/receive flags (e.g. ZMQ.NOBLOCK) are defined as ints, but the functions expect longs. 2) (more annoying) Because the Poller class makes all of its underlying data structures (e.g. the Socket array) private, the only way to even CHANGE what events a socket is listening for is to recreate the Poller object and add sockets to it again. It would be nice to either expose the underlying structures so we can manipulate stuff ourselves or write a set of functions (e.g. deregister or an overloaded version of register which reregisters) that do everything for us. 3) (related to 2) You can register a socket twice because your register functions have no existence check. I don't know what the behavior is here (haven't tested it). On the Java side I basically have to do a lot of recreating pollers that I don't have to do on the C++ side. Scott
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
