anchor.diff:  }
   ----
   
  -Note that it is important for _getNextMessage_ to have a relatively short timeout (low seconds). Calls that get stuck in Java can cause the UI to become unresponsive and may require users to force close MATLAB without being able to save the workspace. Passing in a timeout of zero provides a non-blocking interface that returns empty if no messages are available.
  +Note that the _getNextMessage_ method expects a user settable timeout argument. In general it is important for blocking Java methods to have a timeout in order to prevent the main thread from getting permanently stuck inside Java. Otherwise this could cause the UI to become unresponsive and users may be forced to close MATLAB without being able to save their workspace. Being in a Java call also prohibits users from aborting an execution (ctrl-c), so timeouts should be reasonably short, i.e., in the low seconds.
  +
  +Passing in a timeout of zero served as a non-blocking interface that returned empty if no messages were available.
  +
  +The example below shows the Java Aggregator class being used from MATLAB. Note that primitive types are automatically translated between Java and MATLAB types, so there is no need to add an additional conversion layer.
   
   [source,matlab]
   ----
  
positive.code: 
  ----
  
  According to their http://gazebosim.org/haptix[documentation] the MATLAB API was generated from their C API. Investing time into code generators is a heavily recommended practice since maintaining four or more translation layers for every function can be very tedious and is extremely difficult to extend and maintain manually.
  
  Below is a copy of an http://gazebosim.org/tutorials?cat=haptix&tut=haptix_matlab[example] from their website.
  
  
negative.code: 
  == Technical Background
  
  The main limitation when trying to use MATLAB to interface with hardware is that the language is fundamentally single threaded. It has been designed to allow non-programmers to do complex math operations without needing to worry about programming concepts like multi-threading or synchronization.
  
  This poses a problem for real-time control because all communication with hardware is forced to happen synchronously in the main thread. For example, if we were to run a loop at 100Hz and it took a message ~8ms for a round-trip, the main thread would spend 80% of the available time budget waiting for a response without doing any actual work.
  
  A second hurdle is that while MATLAB is very efficient in the execution of math operations, it is not particularly well suited for byte manipulation. This makes it difficult to develop code that can efficiently create and parse binary message formats that the target hardware can understand.
  
  After having the main thread spend its time on waiting for and parsing the incoming data, there may not be any time left for performing interesting math operations. Pure MATLAB implementations do work for simple applications, e.g., interfacing with an Arduino to gather temperature data or blink an LED, but it is not feasible control complex robotic systems at reasonable rates.
  
  Fortunately, MATLAB does have the ability to interface with other programming languages that allow users to create background threads in order to offload the communications aspect from the main thread. Out of the box MATLAB provides two interfaces to other languages:  https://www.mathworks.com/help/matlab/matlab_external/introducing-mex-files.html[MEX] for calling C++ code and the https://www.mathworks.com/help/matlab/matlab_external/product-overview.html[Java Interface] for calling Java code. There are https://www.mathworks.com/help/matlab/calling-external-functions.html[other interfaces] as well, but those require additional setup steps.  
  
  There are some subtle differences between the capabilities of the MEX and Java interfaces, but both provide enough capabilities for developing sophisticated interfaces, and have orders of magnitude better performance than required. At the end of the day the choice mostly comes down to personal preference.
  
  There are generally two approaches to integrate MATLAB with hardware. The most common way is to setup a distributed system in which the actual hardware communication is done in a separate process, and data is exchanged with MATLAB through a messaging framework, e.g., ROS-messaging. This is often easier to develop and typically results in a relatively hardware agnostic interface. However, it does burden the users with setting up the rest of the system. The alternative approach is to create a standalone implementation that runs entirely within MATLAB.
  
  ////
  == Message Passing Frameworks
  