Latest blog entries

Weird List Comprensions in Erlang

Some strange cases regarding List Comprenhensions

Jan 13 2015 : Brujo Benavides

How to automatically generate different production and staging builds

Use gradle to build different flavors of APKs

Dec 22 2014 : Henrique Boregio

Galgo Android Library

An android library to display logs as on screen overlays

Nov 20 2014 : Henrique Boregio

ErloungeBA @ Inaka

ErloungeBA meeting @ Inaka Offices.

Nov 14 2014 : Inaka

Shotgun: HTTP client for Server-sent Events

Show usage of Shotgun and how consuming SSE can be simple.

Oct 20 2014 : Juan Facorro

Metaprogramming in Erlang: Writing a partial application function

The joys of metaprogramming and Erlang's abstract format

Oct 14 2014 : Hernán Rivas Acosta

Implementing an Android REST Client using Retrofit

Quickly create REST Clients from a simple java interface

Oct 10 2014 : Henrique Boregio

Worker Pool (for Erlang)

Introducing one of our open-source tools: Worker Pool

Sep 25 2014 : Brujo Benavides

The Fork Workflow in iOS

A clear way to apply modifications to your project dependencies

Sep 19 2014 : Pablo Villar

Launching Android Activities in a Separate Task

Launching Android Activities in a Separate Task

Sep 09 2014 : Henrique Boregio

Getting the right colors in your iOS app

How to keep consistence when picking and applying colors

Sep 05 2014 : Pablo Villar

The King of Code Style

Introducing our erlang style guide and style-checking tool, Elvis

Sep 05 2014 : Iñaki Garay

Proud to announce our new home with Erlang Solutions

Inaka is proud to announce our new home with Erlang Solutions!

Aug 05 2014 : Chad DePue


IKJayma: A simple iOS Networking Library

Jul 21 2014 : Tom Ryan

Become an Erlang Cowboy and tame the Wild Wild Web - Part I

Erlang: From zero to coding a commenting system

Jun 23 2014 : Federico Carrone

Implementing a simple Rest Client in Android

How to create a simple Rest Client in Android

May 19 2014 : Henrique Boregio

Assisted Workflow: a CLI tool to speed up simple git workflows

Introducing the assisted_workflow gem, a cli tool with useful commands to integrate a simple git workflow with the story tracker and github pull requests

Mar 25 2014 : Flavio Granero

Cleaning Up Your GitHub Tree

How to clear all those stray branches

Feb 21 2014 : Pablo Villar

Friday Talks at Inaka

Lunch together, talk together

Dec 20 2013 : Inaka Blog

RubyConf Argentina 2013

Inaka represents at RubyConf 2013

Dec 18 2013 : Inaka Blog

Bounce Rate Bare-Bones Basics

An overview of bounce rate in broad strokes

Dec 05 2013 : Inaka Blog

Paintball: Inaka’s End-of-the-Year Party

Welts and bruises bring Inaka together

Nov 22 2013 : Inaka Blog

Inaka Product Review: Connection Minder

Making networking personal again

Nov 19 2013 : Inaka Blog

Canillita - Your First Erlang Server

Learn Erlang by example creating a simple RESTful server

Nov 06 2013 : Fernando "Brujo" Benavides

Landing Page Basics: What, How, and Why

The importance of a well-built landing page

Oct 29 2013 : Inaka Blog

Navigating Open Source Licensing

A comparison of common open source licenses

Oct 17 2013 : Inaka Blog

Git: Not Just for Devs

Sharing the Git love

Oct 07 2013 : Inaka Blog

Inaka Product Review: Go Dish

Go Dish brings good deals on good food

Oct 01 2013 : Inaka Blog

Reconsidering the Big Launch

Why big launches often disappoint, and what to do instead

Sep 23 2013 : Inaka Blog

Inaka Product Review: Whisper

Share secrets and meet new people with Whisper

Sep 16 2013 : Inaka Blog

Inaka Product Review: Ombu

Ombu combines the best of Bump and Scan to make sharing easy

Sep 11 2013 : Inaka Blog

Digitized Halloween Costumes

Morphsuits and Digital Dudz at your fingertips

Sep 09 2013 : Inaka Blog

7 Tactics to Build an App Without a Technical Cofounder: Part 3

Focusing on user experience through design

Sep 06 2013 : Inaka Blog

From Erlang to Java and Back Again: Part 1

My experience creating a Java/Erlang OTP application

Sep 05 2013 : Fernando "Brujo" Benavides

7 Tactics to Build an App Without a Technical Cofounder: Part 2

A realistic look at costs and business relations

Aug 30 2013 : Inaka Blog

7 Tactics to Build an App Without a Technical Cofounder: Part 1

Understanding the tools and processes of app development

Aug 28 2013 : Inaka Blog

Second-Screen App Round-Up

A round-up of network agnostic, network-based, and show-based apps

Aug 27 2013 : Inaka Blog

iOS Auto Layout

A review of Apple's Auto Layout technology

Aug 23 2013 : German Azcona

Core Data One-Way Relationships

Common design patterns in iOS applications

Mar 06 2013 : Tom Ryan

Everyday Erlang: Quick and effective caching using ETS

Using ETS for effective caching in Erlang

Mar 05 2013 : Marcelo Gornstein

Don't Under-Think It: SQL vs NoSQL

The effect of database choice on 'technical debt

Feb 26 2013 : Chad DePue

Erlang Event-Driven Applications

A thorough how-to on using events

Jan 21 2013 : Marcelo Gornstein

Don't Under-Think It: Making Critical Decisions When Building an iOS Application

How a few up-front decisions can make or break an app

Dec 06 2012 : Chad DePue

Some Erlang Magic for Beginners

Erlang tricks for beginners

Dec 03 2012 : Fernando "Brujo" Benavides

Inaka:Pong - DIY Sport

How to play Inaka:Pong, a new sport

Dec 03 2012 : Fernando "Brujo" Benavides

Every-day Erlang: Handling Crashes in Erlang

Handling crashes when calling gen_server:start link outside a supervisor

Nov 29 2012 : Marcelo Gornstein

Inaka Friday lunches

Team building at Inaka

Nov 02 2012 : Chad DePue

Inaka is a proud sponsor of Erlang DC

The largest Erlang event on the East Coast

Oct 23 2012 : Jenny Taylor

Inaka proud to be a sponsor of RubyConf Argentina

The largest Ruby event in South America

Oct 23 2012 : Jenny Taylor

Inaka client featured on LifeHacker

Big press for the Heroku-powered Rails-based Gmail plugin

Feb 28 2012 : Chad DePue

Scaling Erlang

Scale testing a sample Erlang/OTP application

Oct 07 2011 : Fernando "Brujo" Benavides

Memory Management Changes in iOS 5

A review of Apple's new ARC technology

Sep 05 2011 : German Azcona

My Year of Riak

Thoughts on using Basho's Riak database in production.

Aug 25 2011 : Chad DePue

From Erlang to Java and Back Again: Part 1

Fernando "Brujo" Benavides, Sep 05 2013


Not so long ago, I was required to write an Erlang application that uses some Java libraries through JInterface. I finally did it, and I learned a lot of things in the process. This article is the first one in a series describing the things I've learned along the way. As we walk through this series, we'll create an application like the one I wrote. It will be called fetjaba (as in From Erlang To Java And Back Again).

In This Article

One of my first goals was for this new application to be used as any other OTP Application, not requiring any Java knowledge from its users. For that, I needed to be able to:

  • compile its Java pieces along with the Erlang ones using rebar compile and, in general, be able to include the app as a regular rebar dependency
  • start the application with just application:start/1 on an Erlang shell, without any Java or shell commands to start the Java part
  • stop the application with application:stop/1 on an Erlang shell, not leaving any Java process(es) around when the application stops

In this article, I'll show you how I implemented that based on this library written by @fredlund.

Directory Structure

For this project I used the standard OTP directory structure, including the classical ebin, src and include folders, deps for the rebar dependencies (like lager), etc. I put the java code in a new java_src folder (in the root folder of the project) and I put all the external jars I needed in the priv folder. I also created a bin folder to place the compiled java classes.

Compiling Java Code

As I stated before, I wanted to be able to just rebar compile the project and have all the erlang and java code compiled at once. To do this, I added the following lines to my rebar.config:

{pre_hooks, [{compile, "mkdir -p bin"}]}.
{post_hooks, [{clean, "rm -rf bin priv/fejtaba.jar"},
              {compile, "javac -g -verbose -deprecation -sourcepath java_src 
                               -classpath ./bin:/usr/local/lib/erlang/lib/jinterface-1.5.6/priv/OtpErlang.jar:./priv/*
                               -d bin `find java_src -name *.java`"},
              {compile, "jar cf priv/fejtaba.jar -C bin ."}]}.

The pre_hook for compile basically just creates a folder where java will output the .class files. Then, I added 3 post_hooks: one for cleaning up by removing the jar generated when compiling, one for compiling the java sources into the bin folder, and the last one to put them all into a jar file in priv.

Starting the Java Node from Erlang

The next task was to be able to start the java node when the Erlang application starts, as well as detect if it goes down at some point. To do so, I wrote the following code:


On the Erlang side, I created a gen_server with the following init function:

init([]) ->
  %% First of all we need to have java installed
  case os:find_executable("java") of
    [] ->
      throw({stop, java_missing});
    Java ->
      %% We want to let the java node know who we are
      ThisNode = atom_to_list(node()), 
      %% We build a fancy name for the java node
      JavaNode =
        case string:tokens(ThisNode, "@") of
          [Name, Server] -> list_to_atom(Name ++ "_java@" ++ Server);
          _Node -> throw({bad_node_name, node()})
      %% Finding the priv dir is a tricky thing, this function does it for us
      Priv = priv_dir(fetjaba),
      %% In the same way, finding an otp lib dir is also tricky, hence otp_lib
      %% We build the classpath with our priv dir (where we put all the jars we need)
      %% and OtpErlang.jar from jinterface
      Classpath = otp_lib("/OtpErlang.jar") ++ [$: | Priv ++ "/*"],
      Port =
        erlang:open_port({spawn_executable, Java},
                         [{line,1000}, stderr_to_stdout,
                          {args, ["-classpath", Classpath, %% The classpath
                                 %% The class with the main method on our Java code
                                  %% The command line arguments
                                  %% including the node names and
                                  %% the cookie (you'll see how I use them on java side)
                                  ThisNode, JavaNode,
      %% Then we wait for a signal from the Java side that everything is ready
      wait_for_ready(#state{java_port = Port, java_node = JavaNode})

%% @doc Skips every console message until it finds the word "READY"
%%             Then starts monitoring the Java node
wait_for_ready(State = #state{java_port = Port}) ->
    {Port, {data, {eol, "READY"}}} ->
      true = erlang:monitor_node(State#state.java_node, true),
      {ok, State};
    Info ->
      case handle_info(Info, State) of
        {noreply, NewState} ->
        {stop, Reason, _NewState} ->
          {stop, Reason}

Since we are monitoring the Java node, we can handle 'nodedown' messages, and at least stop this gen_server, so its supervisor can act accordingly:

handle_info({nodedown, JavaNode}, State = #state{java_node = JavaNode}) ->
  lager:error("Java node is down!"),
  {stop, nodedown, State};


On Java side, I created a class called net.inaka.fetjaba.Node that, up to this point, just starts a node:

public class Node {
  /** This Erlang node */
  public static OtpNode   NODE;

  /** Peer node name */
  public static String    PEER;

  public static void main(String[] args) {
    String peerName = args.length >= 1 ? args[0]
        : "fetjaba@nohost";
    String nodeName = args.length >= 2 ? args[1]
        : "fetjaba_java@nohost";
    try {
      // Depending on whether there is a provided cookie or not…
      NODE = args.length >= 3 ? new OtpNode(nodeName, args[2])
          : new OtpNode(nodeName);
      PEER = peerName;

      do_our_stuff(); // Most likely, at least start a thread with an Erlang mbox

    } catch (IOException e1) {

Stopping the Java Node from Erlang

My last goal was to be able to stop the running Java node when I executed application:stop(fetjaba) on the Erlang side. There are many ways to do it, but since I already had a gen_server on the Erlang side, I decided to put an Erlang Mbox (which is almost equivalent to an Erlang process) on Java side and just link it to my gen_server. This way, when one dies, the other can take action. So, at some point inside what replaced that call to do_our_stuff() on the Java code, I started a Thread with a named Mbox and handled the exit signals like this:

    // We create an mbox to link
    final OtpMbox mbox = NODE.createMbox("fetjaba_server");
    new Thread(mbox.getName()) {
      public void run() {
        while(true) { // This thread runs forever
          try {
            OtpErlangObject msg = mbox.receive(); // Gets the message
            processMsg(msg); // … and deals with it, before getting the next one
          } catch (OtpErlangExit oee) { // Until it gets an exit signal
            System.exit(1); // And, this is a little bit violent, but it gets the job done.

Then, on the Erlang side, we change our wait_for_ready/1 function just a little bit…

wait_for_ready(State = #state{java_port = Port}) ->
    {Port, {data, {eol, "READY"}}} ->
      true = erlang:link(process()),
      true = erlang:monitor_node(State#state.java_node, true),
      {ok, State};
    Info ->
      case handle_info(Info, State) of
        {noreply, NewState} ->
        {stop, Reason, _NewState} ->
          {stop, Reason}

I coded the processMsg(msg) method on my Java class to handle stop and {pid, pid()} properly so that we could see the application in action:

  protected static boolean processMsg(OtpErlangObject msg, OtpMbox mbox)
      throws OtpErlangDecodeException {
    if (msg instanceof OtpErlangAtom
        && ((OtpErlangAtom) msg).atomValue().equals("stop")) {
      return false;
    } else if (msg instanceof OtpErlangTuple) {
      OtpErlangObject[] elements = ((OtpErlangTuple) msg).elements();
      if (elements.length == 2) {
        if (elements[0] instanceof OtpErlangAtom
            && ((OtpErlangAtom) elements[0]).atomValue().equals(
                "pid") && elements[1] instanceof OtpErlangPid) {
          OtpErlangPid caller = (OtpErlangPid) elements[1];
          mbox.send(caller, new OtpErlangTuple(new OtpErlangObject[] {
              elements[0], mbox.self() }));
          return true;
    throw new OtpErlangDecodeException("Bad message: " + msg.toString());

Trying Things Out For Real

Now let's try all this stuff out, shall we? Since, at this point, it's just a rebarized OTP Application, we can start it inside an Erlang node, like this:

1> application:start(fetjaba).

=INFO REPORT==== 17-Jul-2013::16:57:18 ===
Java node started


=PROGRESS REPORT==== 17-Jul-2013::16:57:18 ===
         application: fetjaba
          started_at: 'fetjaba@inaki.local'

We can then check that the java node is up, and responds to our messages:

2> net_adm:names().
3> fetjaba:process().

Now we should verify that both sides of the app die at once. Let's start by tearing down the Java node first:

4> fetjaba:stop().
=ERROR REPORT==== 17-Jul-2013::17:14:06 ===
Java node is down!

=ERROR REPORT==== 17-Jul-2013::17:14:06 ===
** Generic server fetjaba terminating

=INFO REPORT==== 17-Jul-2013::17:14:06 ===
    application: fetjaba
    exited: nodedown
    type: temporary

5> net_adm:names().
6> erlang:whereis(fetjaba).

So, when the Java process terminated, its node was torn down. Then, our gen_server noticed it and stopped our application. That's what we wanted. Now, what happens if we stop our application instead?

7> application:start(fetjaba).

=INFO REPORT==== 17-Jul-2013::17:20:27 ===
Java node started


=PROGRESS REPORT==== 17-Jul-2013::17:20:27 ===
         application: fetjaba
          started_at: 'fetjaba@inaki.local'
8> net_adm:names().
9> fetjaba:process().
10> application:stop(fetjaba).

=INFO REPORT==== 17-Jul-2013::17:21:42 ===
    application: fetjaba
    exited: stopped
    type: temporary
11> net_adm:names().
12> fetjaba:process().
** exception throw: timeout

As you can see, when we stop our application, the java process is stopped, too. Exactly what we wanted!

See For Yourself

The code for this application is hosted on Inaka's Github. You can clone that repo and try all this stuff out. We also accept pull requests! :)

What's next?

In the following articles on this series, I'll show you how to create and start some useful processes on the Java node, as well as how to communicate back and forth between them and the Erlang ones.