Erlang port to the Java Virtual Machine

Yariv Sadan yarivvv@REDACTED
Wed May 31 20:36:40 CEST 2006

> Well, yes, of course it's possible. In order to avoid any stubs, it is
> not only that the API has to use static methods, but also only use as
> arguments and return values simple types or OtpErlang* ones. And in that
> case, the rpcs are very little more than the regular rpcs used with
> jinterface.

Why must stubs be avoided? Couldn't an Erlang->Java RPC mechanism support stubs?

Also, I think that if an RPC function call returns a serialized Java
object, and Erlang function could parse the response and return an
Erlang tuple representing the Java object. It's hackish, but may be
useful. The interface would be something like

java_serializer:deserialize(SerializedJavaObject) -> {ok, Tuple} | {error}

> Since Erlang is basically a server-oriented environment, my feeling is
> that the way to go would be the other way around: build a Java
> application that is only the presentation layer and let it do RPCs to
> the Erlang server. This way, no stubs are needed.

I think both RPC types (Erlang -> Java and Java -> Erlang) should be
supported  as they answer different needs. For instance, if you
already have an application with a presentation layer written in
Erlang, and you want to make use of some Java library for a small part
of the application (for example, CAPTCHA generation, for which I don't
think Erlang has a library), it would be advantageous to expose the
Java api to Erlang via an easy-to-use rpc wrapper.

Again, I hope I'm not horribly off track here given my limited
experience with Erlang and jinterface :)


More information about the erlang-questions mailing list