Communication between java and Go

[xavm]

Hello,

Go will have, as any language as to do, to interact with its
environment. Java is certainly the most part of this environment.
When we use Java in combination with C, we have JNI or JNA for
instance as a solution to solve this problem. In the case of Go, even
if we can make a C library calling Go code, it is not the most
effective way to do it.

It seems, as I read once in a discussion here about a plugin
architecture for Go, that the Go policy is to make communications
between processes instead of having to implement an OSGI-like approach
(but maybe I haven't well understood). So I imagine the way to make
Java and Go interacting would be to implement in Java a way to call or
to be called by Go channels to make communication easier.

Is there something like that planned for Go? If not, is there an
external project which could do that efficiently (not with JSON and
so on which are good for a quite big information granularity
exchange)?

best regards
Xavier

[SteveD]

On Nov 17, 10:58 am, xavm <xavier.meh...@gmail.com> wrote:
> Is there something like that planned for Go? If not, is there an
> external  project which could do that efficiently (not with JSON and
> so on which are good for a quite big information granularity
> exchange)?

CORBA? ;)

Jokes aside, I'd say that starting from go-rpc and writing tools that
can generate the Java client stubs would be one way of doing this.

Or just custom socket protocols.

steve d.

[roger peppe]

protobufs might be a useful exchange format, with implementations
for both java and Go.

[Archos]

I'd use MessagePack since it's simpler and faster than Protocol
Buffers and another ones.

http://msgpack.org/

On Nov 17, 12:14 pm, roger peppe <rogpe...@gmail.com> wrote:
> protobufs might be a useful exchange format, with implementations
> for both java and Go.
>

[roger peppe]

On 17 November 2011 12:23, Archos <raul...@sent.com> wrote:
> I'd use MessagePack since it's simpler and faster than Protocol
> Buffers and another ones.

not everyone agrees.

http://groups.google.com/group/msgpack/browse_thread/thread/db5e20aa64f3020d?pli=1

and from this group in August:

On Aug 5, 12:31 pm, David Symonds <dsymo...@golang.org> wrote:
> On Fri, Aug 5, 2011 at 10:13 PM, André Moraes <andr...@gmail.com> wrote:
> > Are any know drawbacks when using MessagePack RPC?
>
> MessagePack is dynamically typed, schemaless, has patchy documentation
> and highly uneven implementation completeness across languages. If it
> works for you, great, but you might want to do some thorough research
> first.
>
> Dave.

[André Moraes]

Go has support for network,unix sockets and file pipes (stdin/stdout)

Also it have messagepack, protocolbuffers, json, thrift (i guess).

With that you can communicate with anything in the world.

The easiest way to send messages across a communication media
(network, pipes, sockets)
is to prefix every message with a integer with the size of the message
and make the system
half-duplex.

You can also use ZMQ (bindings for almost every language today).

coordinate messages with zmq
encode messages with protocolbuff, message pack, json, yaml, etc...

--
André Moraes
http://andredevchannel.blogspot.com/

[André Moraes]

> On Aug 5, 12:31 pm, David Symonds <dsymo...@golang.org> wrote:
>> On Fri, Aug 5, 2011 at 10:13 PM, André Moraes <andr...@gmail.com> wrote:
>> > Are any know drawbacks when using MessagePack RPC?
>>
>> MessagePack is dynamically typed, schemaless, has patchy documentation
>> and highly uneven implementation completeness across languages. If it
>> works for you, great, but you might want to do some thorough research
>> first.

In that case I dropped the message-pack in favor of protocol-buffers.
And when I need something very easy to parse just use Json.

Also somebody could use Bson as a encoding for messages, Gustavo have
one very good implementation.
Just search for "mgo golang"

[xavm]

Thanks everybody for the answers ; I know we can do this by already
existing methods, but I spoke about a ready to use (auto-)standardized
solution for both sides (java and Go and maybe other languages),
efficient, simple...like channels :)
regards
xavier

[Kyle Lemons]

Thanks everybody for the answers ; I know we can do this by already
existing methods, but I spoke about a ready to use (auto-)standardized
solution for both sides (java and Go and maybe other languages),
efficient, simple...like channels :)

There isn't one.  There probably won't ever be one in the standard library, unless netchan makes the cut and someone implements gob and the netchan protocol in Java somehow.  You seem to also be talking about calling Java from Go (or vice versa), which is unlikely to ever be a "ready-made" solution, though which is certainly possible, given enough time, effort, and expertise.

[Salman Aljammaz]

On Thu, Nov 17, 2011 at 2:37 PM, xavm <xavier...@gmail.com> wrote:
> Thanks everybody for the answers ; I know we can do this by already
> existing methods, but I spoke about a ready to use (auto-)standardized
> solution for both sides (java and Go and maybe other languages),
> efficient, simple...like channels :)

Do you mean an analogue of JNI for Go? I find it hard to imagine
doing that without JVM modifications.

The various RPC mechanisms suggested here are good enough for all the
examples I can think of. Can you provide an example where such an
interface makes things inefficient?

Salman

[Xavier Mehaut]

yes kyle i thought of kind of netchan in local. on one hand (go) we would use locchan (my netchan local), and on the other hand (java) an actor (object with thread) with a locchan-like api.

regards

Envoyé de mon iPhone

[André Moraes]

What kind of problem are you trying to solve?

Inter process communication isn't that bad unless you are copying lots
and lots of memory every second.

[Kyle Lemons]

yes kyle i thought of kind of netchan in local. on one hand (go) we would use locchan (my netchan local), and on the other hand (java) an actor (object with thread) with a locchan-like api.

regards

For the record, netchan as it is today is going away (but may come back later), and this is exactly what has been suggested earlier about defining a network-based protocol (netchan uses gob); it just happens to have something of a Go-esque API (though channels are poor substitutes for network based operations because sending on a channel cannot fail).  Netchan also doesn't support synchronous channels.  You might as well just do what was suggested and use rpc or a socket with gobs.

[xavm]

It is actually the case ; I've to deal with h264 video streams...
regards
Xavier

[André Moraes]

> It is actually the case ; I've to deal with h264 video streams...
> regards
> Xavier

Well, in that case you maybe out of luck.

Just for curiosity, why do you want to process h264 on Go?
Most encoding libraries will work with that more easily and even use
hardware aceleration.

[SteveD]

On Nov 18, 9:56 am, xavm <xavier.meh...@gmail.com> wrote:
> It is actually the case ; I've to deal with h264 video streams...

Shared memory with some cross-process synchronization?

Will probably have to roll your own JNI shared memory access class.

But (as always) test a few candidate methods for throughput and
latency.

steve d.

[si guy]

Could you please clarify "going away" for me? Ie. How far away. Will the old/netchan be maintained? Will it be excluded form the mercurial repo, and when/which version of go do you expect to be the one that breaks it un-gofix-ably.

I ask because we are using it for our distributed game server and may have to re-evaluate that decision.

[Kyle Lemons]

Could you please clarify "going away" for me? Ie. How far away. Will the old/netchan be maintained? Will it be excluded form the mercurial repo, and when/which version of go do you expect to be the one that breaks it un-gofix-ably.

I ask because we are using it for our distributed game server and may have to re-evaluate that decision.

From the Go 1 plan document:

netchan - not in Go 1, move to old/netchan (in weekly.2011-10-18)

[si guy]

Ahh, thanks. I thought plans for netchan had changed.