Notes on Language Interoperability

While the ability to choose how they want to integrate with the Erlang VM should be left open, I think standardizing on the Erlang Port interface is a good idea. This means all an application designer has to do is utilize stdin/stdout to push/pull from the Port.

An example Java Sink could therefore be:

public class TestSink {
    private static Object state;
    public static void main(String[] args) {
        state = initialize();
        while( true ) {
            print(process(decode(listen(System.in))));
        }
    }
    private static String process(Object event) {
        ...
    }
}

The coupled Erlang code loader would be like this:

-module(java_testsink).
-behaviour(libemp_sink).
-export([setup/1,process/3]).
setup( _ ) ->
    Port = open_port({spawn, "java ./path/to/class/TestSink.class"},[{packet,2}]),
    {ok, Port}.
process( Event, _, Port ) ->
    erlang:port_command( Port, Event ),
    NewEvent = hang_for_response( Port ), % Not completely necessary.
    {next, NewEvent, Port}.

Some notes about this:

• Decode could be extremely simple if all Monitors were written in Java and just pushed events as serialized java objects. The Sink only needs to deserialize and process them as needed. I don't want to dictate the types of objects or the serialization framework needed here.
• The java process/1 should really be process/2 so that it can be passed its state. But really most ports could maintain there own (as shown here). It is only Erlang that requires its own, thus the wrapper Erlang process could just maintain the Port.
• Note in the Erlang code loader it makes not attempt to trap exits. This could be explicit so that the whole thing fails up to the Processor (which should trap_exit). Alternatively it could trap it and restart the connection if needed here.