[zeromq-dev] Initial support for zmq_poll() under Java

gonzalo diethelm gdiethelm at dcv.cl
Thu Feb 25 13:51:32 CET 2010


Find attached the patch, MIT-licensed, for adding poll support under
Java. This patch does NOT include my logging functions; I hand-edited
it, so if you have any problems applying the patch, let me know.

> > Issue #1: it is difficult to pass a single array of structures
because
> > accessing such array from JNI is complex. I think it CAN be done,
but I
> > decided to work on a simpler way first and later improve things,
after
> > other eyes have had the chance to look at the code.
> 
> > Issue #2: I would have liked to use an interface such as Set instead
of
> > arrays, but accessing those from JNI seems to be even more complex
or
> > even impossible.
> 
> Right. Let's mark the poll function as experimental so that people are
> aware that the prototype may change in the future.

Ok.

> > Issue #3: adding Java / plain sockets to this method is not easy,
may
> > not be portable and may even be impossible. For one thing, if you
have a
> > java.net.Socket object, there is no portable way to access the
> > underlying socket descriptor.
> 
> Integrating native sockets is not a priority IMHO. First let's get
> polling on 0MQ sockets functional, then care about native sockets.

Ok.

> However, AFAIU, what we'll need to do then is to make an decision
> (arbitrary one) on how to access underlying fds as there's no
> stadardised way to do this.
> 
> For example we can say: Any object that wants to be 0MQ-pollable has
to
> have 'fd' property exposing underlying file descriptor.
> 
> Afterwards, people are free to submit patches to their favourite Java
> implementations/socket types etc.

Even this may not work. Objects of type java.net.Socket have three
layers of private members (SocketImpl, FileDescriptor, FD) hiding the
socket handle; you can hack your way through this in JNI only, because
JNI does not follow the private access restrictions. Other sockets may
be different.

> 1. You've added documentation to individual functions. These can be
> processed by javadoc, right? In case you choose to offload the binding
> from 0MQ project, generating the docs and placing them somewhere (we
can
> upload it for you if needed) would make sense.

If you mean the documentation in the Java classes, then yes; as far as I
know, javadoc can process those without any problems.

> 2. I still feel that Java API needs some beautification - especially
> when it comes to namespacing. Compare Java and Ruby examples:
> 
>    org.zmq.Socket s = new org.zmq.Socket (ctx, org.zmq.Socket.REP);
> 
>    s = ZMQ::Socket.new(ctx, ZMQ::REP);
> 
> Thoughts?

Two thoughts:

1. You usually import the specific classes you use. So your example can
today be written as:

  import org.zmq.Socket;
  ...
  Socket s = new Socket (ctx, Socket.REP);

2. We could also have one big public class called ZMQ, with nested
public classes:

  Implementation:

  package org.zmq;

  public class ZMQ {
    public class Context {...}
    public class Socket {...}
    ...
  }


  Usage:

  import org.zmq.ZMQ;
  ...
  ZMQ.Socket s = new ZMQ.Socket (ctx, ZMQ.REP);

This is an API change, though. If you want to go this route, I can
prepare a patch after the poll support has been committed.

-- 
Gonzalo Diethelm





----------------------------------------- 
Declaración de confidencialidad: Este Mensaje esta destinado para
el uso de la o las personas o entidades a quien ha sido dirigido y
puede contener información reservada y confidencial que no puede
ser divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena. 
Si usted ha recibido este correo electrónico por error, le pedimos
eliminarlo junto con los archivos adjuntos y avisar inmediatamente
al remitente, respondiendo este mensaje. 

"Before printing this e-mail think if is really necesary".
Disclosure: This Message is to be used by the individual,
individuals or entities that it is addressed to and may include
private and confidential information that may not be disclosed,
made public nor used in any way at all. Unauthorized use of the
information in this electronic mail message may be subject to the
penalties set forth by Chilean law. 
If you have received this electronic mail message in error, we ask
you to destroy the message and its attached file(s) and to
immediately notify the sender by answering this message. 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-java-poll.txt
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100225/daba9992/attachment.txt>


More information about the zeromq-dev mailing list