[zeromq-dev] ZMQ_LINGER socket option

[Martin Sustrik]

On 10/18/2010 11:19 PM, gonzalo diethelm wrote:
> Ok, agreed. Minor thing: bindings for dynamic languages are usually done
> this way; in the Java world, you are supposed to have a single binding
> that can work with all versions of the underlying library.
>    
Sure. The bindings should adhere to the conventions of the particular 
language as much as possible. So if that's how java libraries are 
supposed to work, just go for it.

> Now, a request for suggestions: until now I am returning void / -1 for a
> Socket.setXXX / Socket.getXXX when the XXX is not supported by the
> underlying 0MQ library. But this makes it kind of hard to know if you
> are getting a -1 as an error flag or a real value; even harder for
> setXXX, where it will simply return. I guess I should really throw an
> exception to make it really obvious it is failing. The question is: what
> is the proper exception for these cases?
>    
Right now the error returned by 0MQ function (POSIX error code) is 
converted to the Java exception. Why not do it the same way with 
getsockopt and setsockopt? 0MQ returns EINVAL when option ID is invalid.
> And also: be advised that, should I change this, I would be changing the
> public interface for the Java binding (and I am not ready to split it
> into maint and master yet...). I know, a pain in the rear. Better now
> than later.
Ha. I have the same problem with the core library. Now it have hit the 
bindings :)

For the core the solution was to promise no API change in minor 
versions. I.e. next API change only in 0MQ/3.0.

However, in this particular case changing the API can be considered a 
bugfix rather than a change. Any Java users here to comment on the issue?

Martin