> Date: Tue, 11 Apr 2017 12:15:15 +0200 > From: Kevin Sapper <kevinsappe...@gmail.com> > > Hi James, > > the czmqjni wrapper is a very thin layer above the czmq API. So any > example in the > czmq README should work.
That's what I expected, but I think I'm missing a translation step between the java object reference to a void* that the Zframe/message calls could use as a sockish. > Though some APIs might not be available in the > wrapper > due to technical reasons. If you're not able to convert the C examples > in the README, > let me know then I'll try to create one later this week. I haven't had any luck yet, so I appreciate the offer. I'll let you know if I manage to figure anything out before you put anything together. > While the czmq API is stable the jni wrapper's API is not. So we are > happy to receive > improvements. Cool. I've started to take a look at the GSL/Zproject docs. Time will tell whether I'll be able to find any bandwidth to actually contribute. > APIwhise jzmq and jeromq are the same. Also those APIs a more javalike > and both > libraries have been more tested than czmqjni. But they don't support > encryption, > if I'm not mistaken, Last I heard/tried, it seemed like jzmq had that covered. And, with TweetNacl in java, I think it wouldn't be too hard to add to jeromq. > which would be your reason to use czmqjni instead. In this case, it's a lighter political/marketing lift. I already foisted the python czmq bindings as the most effective way for us to move our current tech stack (which is python up front and java at the bottom) from a slow brokered networking layer to using CLISRV. Since we're already building libzmq and czmq, adding this binding is less daunting than also adding something like jzmq. I know, it shouldn't be, but there you have it. Thank you, James > //Kevin _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev