[zeromq-dev] Regarding java binding of 0MQ.

[gonzalo diethelm]

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: zeromq-dev-bounces at lists.zeromq.org
[mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Scott Asher
Sent: Wednesday, 24 November, 2010 14:30
To: zeromq-dev at lists.zeromq.org
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101125/6816bece/attachment.htm>