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

[gonzalo diethelm]

> > #3: If we go this route, #2 would be moot. But the two behaviors are
not
> > exactly the same. For Object, you specify a timeout of 0 if you want
to
> wait
> > indefinitely, and -1 is illegal. For Poller, -1 means wait
indefinitely
> and
> > 0 means "wait at most a very short time". We would also have to
define
> how
> > to deprecate Poller.[gs]etTimeout(). Ideas?
> 
> Why not have two branches of jzmq like with zmq itself?

My question was more "do we use Object's convention of 0 for indefinite
wait, or do we keep -1 for that?" But now I realize that this is defined
in 0MQ itself, so never mind.

> E.g. maint (tracking 0mq/maint, maven/ivy/etc version 2.0.10) and
> master (tracking 0mq/master, maven/ivy/etc v2.1.0). That way you could
> mark getTimeout/setTimeout as @Deprecated in maint and remove them in
> master.

The only reason for this is that I am too (git-) ignorant / lazy / both.

Perhaps, as Martin S. suggested, we could handle this with version
numbers. Alternatively, I am not really afraid of breaking backwards
compatibility.

In this case, what if we do this:

1. Initialize this.timeout to -2.
2. Deprecate [gs]etTimeout().
3. Only allow setting this.timeout to a value >= -1.
4. If poll() is called with no args and this.timeout is == -2, poll
indefinitely (new behaviour).
5. If poll() is called with no args and this.timeout is != -2, poll
using the value of this.timeout (old behaviour).
6. If poll() is called with args, use those args as the timeout value
and don't even touch this.timeout.

Opinions are welcome.

-- 
Gonzalo Diethelm