Using Java Collections in Matlab

In this blog, I posted numerous articles showing how built-in Java functionality can greatly increase Matlab programming productivity and the resulting program power. While not really “undocumented” in the true sense (most of the material is actually documented separately in Matlab and Java), in practice, such Java gems are unfortunately often overlooked by Matlab programmers. Many of these tricks are GUI related, but Java has a lot to offer in non-GUI aspects. Today I will show how we can leverage Java’s extensive Collections classes in non-GUI Matlab programming.

Java Collections

Java contains a wide variety of predefined data structures (specifically Collections and Maps), which can easily be adapted to fit most programming tasks. It is unfortunate that the Matlab programming language does not contain similar predefined collection types, apart from its basic cell, array and struct elements. Matlab R2008b (7.7) added containers.Map, which is a much-scaled-down Matlab version of the java.util.Map interface, but is a step in the right direction. Some Matlab programmers prepared their own implementations of data structures, which can be found on the File Exchange.

Matlab’s limitation can easily be overcome with Java’s out-of-the-box set of predefined classes, as described below. Java collections have many advantages over hand-coded Matlab equivalents, in addition to the obvious time saving: Java’s classes are extensively debugged and performance-tuned, which is especially important when searching large collections. Also, these classes provide a consistent interface, are highly configurable and extendable, enable easy cross-type interoperability and generally give Matlab programmers the full power of Java’s collections without needing to program the nuts-and-bolts.

To start using Java collections, readers should first be familiar with them. These classes are part of the core Java language, and are explained in any standard Java programming textbook. The official Java website provides a detailed online tutorial about these classes, their usage and differences, in addition to a detailed reference of these classes.

Java Collections include interfaces and implementation classes. As of Matlab R2011b, Java interfaces cannot be used directly – only the implementation classes. Of the many Collection classes, the following are perhaps most useful (all classes belong to the java.util package, unless otherwise noted):

  • Set: an interface that is implemented by classes characterized by their prevention of duplicate elements. Some notable implementation classes: EnumSet, HashSet, LinkedHashSet, TreeSet.
  • List: an interface that is implemented by classes characterized by ordered elements (a.k.a. sequences), which may be duplicates of each other and accessed based on their exact position within the list. Specially optimized internal algorithms enable sorting, shuffling, reversing, rotating, and other modifications of the list. Some notable implementation classes: Vector, Stack, LinkedList.
  • Queue: an interface that is implemented by classes designed for holding elements prior to processing, in an ordered list accessible only at one (=head) or two (head and tail) positions. All classes include specialized insertion, extraction and inspection methods. Some notable implementation classes: LinkedList, ArrayDeque, PriorityQueue.
  • Map: an interface that is implemented by classes characterized by elements of unique keys paired with associated values. Early Java versions used the java.util.Dictionary abstract superclass, but this was subsequently replaced by the java.util.Map interface class. Maps contain specialized algorithms for fast retrieval based on a supplied key. Some of the notable implementation classes: EnumMap, HashMap, Hashtable, TreeMap, LinkedHashMap.

As noted, Matlab R2008b (7.7)’s new containers.Map class is a scaled-down Matlab version of the java.util.Map interface. It has the added benefit of seamless integration with all Matlab types (unlike Java Collections – see below), as well as the ability since Matlab 7.10 (R2010a) to specify data types. Serious Matlab implementations requiring key-value maps/dictionaries should still use Java’s Map classes to gain access to their larger functionality if not performance. Matlab versions earlier than R2008b have no real alternative in any case and must use the Java classes. The reader may also be interested to examine pure-Matlab object-oriented (class-based) Hashtable implementations, available on the File Exchange (example1, example2).

A potential limitation of using Java Collections is their inability to contain non-primitive Matlab types such as structs. To overcome this, either down-convert the types to some simpler type (using the struct2cell function or programmatically), or create a separate Java object that holds the information and store this object in the Collection.

Many additional Collection classes offer implementation of specialized needs. For example, java.util.concurrent.LinkedBlockingDeque implements a Queue which is also a LinkedList, is a double-ended queue (Deque) and is blocking (meaning that extraction operations will block until at least one element is extractable).

Programming interface

All the Java Collections have intentionally similar interfaces, with additional methods specific to each implementation class based on its use and intent. Most Collections implement the following common self-explanatory methods (simplified interface):

int size()
int hashCode()
boolean isEmpty()
boolean contains(Object element)
boolean containsAll(Collection c)
Iterator iterator()
boolean add(Object element)
boolean remove(Object element)
boolean addAll(Collection c)
boolean removeAll(Collection c)
boolean retainAll(Collection c)
void clear()
Object clone()
Object[] toArray()
String toString()

The full list of supported methods in a specific Collection class can, as any other Java object/class, be inspected using Matlab’s methods or methodsview functions (or my utilities, checkClass and uiinspect):

>> methods('java.util.Hashtable')
Methods for class java.util.Hashtable:
Hashtable	containsKey	  equals	isEmpty   notifyAll	size 
clear		containsValue	  get		keyset    put		toString
clone		elements	  getClass	keys      putAll	values
contains	entrySet	  hashCode	notify    remove	wait

Collections example: Hashtable

A detailed Matlab example that utilizes Hashtable (actually, java.util.Properties, which is a subclass of java.util.Hashtable) for a phone-book application is detailed in Matlab’s External Interface/Java section. The following code snippet complements that example by showing some common characteristics of Collections:

>> hash = java.util.Hashtable;
>> hash.put('key #1','myStr');
>> hash.put('2nd key',magic(3));
>> disp(hash)  % same as: hash.toString
{2nd key=[[D@59da0f, key #1=myStr}
>> disp(hash.containsKey('2nd key'))
     1                        % = true
>> disp(hash.size)
>> disp(hash.get('key #2'))   % key not found
>> disp(hash.get('key #1'))   % key found and value retrieved
>> disp(hash.entrySet) % java.util.Collections$SynchronizedSet object
[2nd key=[[D@192094b, key #1=myStr]
>> entries = hash.entrySet.toArray
entries =
>> disp(entries(1))
2nd key=[[D@192094b
>> disp(entries(2))
key #1=myStr
>> hash.values  % a java.util.Collections$SynchronizedCollection
ans =
[[[D@59da0f, myStr]
>> vals = hash.values.toArray
vals =
    [3x3 double]
>> vals(1)
ans =
     8     1     6
     3     5     7
     4     9     2
>> vals(2)
ans =

Enumerators / Iterators

Java Iterators (aka Enumerators), such as those returned by the hash.keys() method, are temporary memory constructs. A common pitfall is to directly chain such constructs. While legal from a syntax viewpoint, this would produce results that are repetitive and probably unintended, as the following code snippet shows:

>> hash.keys
ans =
java.util.Hashtable$Enumerator@7b1d52    < = enumerator reference
>> hash.keys
ans =
java.util.Hashtable$Enumerator@127d1b4   < = new reference object
>> disp(hash.keys.nextElement)
2nd key   < = 1st key enumerated in the hash
>> disp(hash.keys.nextElement)
2nd key   < = same key returned, because of the new enumeration obj
>> % Wrong way: causes an endless loop since hash.keys regenerates
>> % ^^^^^^^^^  so hash.keys.hasMoreElements is always true
>> while hash.keys.hasMoreElements, doAbc();  end   % endless loop
>> % Correct way: store the enumerator in a temporary variable
>> hashKeys = hash.keys; 
>> while hashKeys.hasMoreElements,  doAbc();  end
>> hash.keys.methods
Methods for class java.util.Hashtable$Enumerator:
equals            hasNext    nextElement   remove
getClass          hashCode   notify        toString
hasMoreElements   next       notifyAll     wait
>> % And similarly for ArrayList iterators:
>> jList = java.util.ArrayList;
>> jList.add(pi); jList.add('text'); jList.add(magic(3)); disp(jList)
[3.141592653589793, text, [[D@1c8f959]
>> iterator = jList.iterator
iterator =
>> disp(; fprintf('hasNext: %d\n',iterator.hasNext)
hasNext: 1
>> disp(; fprintf('hasNext: %d\n',iterator.hasNext)
hasNext: 1
>> disp(; fprintf('hasNext: %d\n',iterator.hasNext)
     8     1     6
     3     5     7
     4     9     2
hasNext: 0

More on this topic and other non-GUI Java libraries that can be used in Matlab, can be found in Chapter 2 of my Matlab-Java Programming book.

Categories: Java, Low risk of breaking in future versions


Bookmark and SharePrint Print

18 Responses to Using Java Collections in Matlab

  1. Joao says:

    These are extremely useful. Are these deployable? If I compile the code into a Java library, will I be using a Java wrapper around a MATLAB wrapper around a Java class?

    • @Joao – yes, they are deployable. You do not need to do anything special to compile them – it works directly “out of the box”.

      As for the wrapper question, I’m not 100% sure, but I am almost sure that the Java objects will be called directly, without any intermediate Matlab wrapper.

      It is actually extremely efficient: Calls to Java Collection methods take microseconds, not even one millisecond.

  2. Quang says:


    I’ve noticed that it is not possible to add a Matlab object to a Java collection

    classdef Person
           function obj = Person(n, a)
      = n;
               obj.age = a;
    p = Person('MyName', 18);
    l = java.util.ArrayList;
    l.add(p) % Error message....

    Is there any workaround for this problem?


    • @Quang – as I’ve said in the article, Java containers can only contain simple objects, not Matlab structs or class objects. You need to either use containers.Map or to serialize (down-convert) your class object into simpler types that can be stored in Java.

    • Quang says:

      Thanks a lot for the quick response! And sry, yes you did mention that in the article. I was reading it too fast :) Is there any way to declare a Java class directly in Matlab instead of using its classdef syntax?

    • You can prepare a Java class in an external class (, compile it using a Java compiler (=> MyClass.class) and then load and use this class in Matlab (just like you load and use java.util.ArrayList. You cannot declare Java code from within Matlab like you would declare a Matlab class.

    • Quang says:

      Thanks a lot. It really helped! :)

  3. Rajpal says:

    How to call matlab fuction in java …
    Give the sollution fast..plz..

  4. Yola says:

    Can you please write something on how i can use java collections with user-defined types. How i can provide comparator for my type. Thanks!

    • To store a Matlab class object in a Java collection, you would need to first serialize the object into a byte array that can then be stored in the Java collection object (and deserialize it when it is extracted).

      Comparators, AFAIK, can only be specified in Java code. I don’t think you can specify a Matlab function to act as a comparator function that Java understands.

  5. Sepehr says:

    Hi Yair,
    Great article. I have tried your suggestion on serializing objects so they can be used as both keys and values in a hashtable. It does not work.
    Here a piece of code that shows hashtable fails at finding a byte array!

    >> hash = java.util.Hashtable;
    >> key = getByteStreamFromArray([1,2]);
    >> value = getByteStreamFromArray([2,3]);
    >> hash.put(key,value)
    ans =
    >> hash.containsKey(key)
    ans =

    Also, when I use strings as keys and byte arrays as values, the retrieved values are scrambled! e.g.

    >> hash = java.util.Hashtable;
    >> hash.put('mykey',getByteStreamFromArray([2,3]));
    >> getArrayFromByteStream(hash.get('mykey'))
    Error using getArrayFromByteStream
    The input must be a uint8 byte stream.

    Any suggestions?

    • @Sepehr – while Hashtable does indeed accept arrays as keys, the automatic conversion between Java and Matlab data types causes hash.get not to find the key. Instead, use a simpler data type such as a number or string.

      You also need to remember that all numeric data in Java is signed, unlike Matlab which uses uint8 for its serialization. Therefore, you need to first convert into a signed int16 before storing in the Java array, and then to convert back to uint8 when loading back into Matlab from the hash:

      >> data = int16(getByteStreamFromArray([2,3]));
      >> hash.put('mykey', data);
      >> data2 = getArrayFromByteStream(uint8(hash.get('mykey')))
      data2 =
           2     3
  6. Christopher Volpe says:

    Nice overview. Is there a reason why (Matlab’s interface to) java.util.LinkedList turns row vectors into column vectors? E.g.:

    >> dummyQueue = java.util.LinkedList
    dummyQueue =
    >> vecIn = [1,2,3]
    vecIn =
         1     2     3
    >> dummyQueue.add(vecIn)
    ans =
    >> vecOut = dummyQueue.remove()
    vecOut =
    • @Christopher – primitive Java arrays (e.g. double[]) are automatically converted into a column vector in Matlab.

      When you store your data in a Java object using automated Matlab-Java type-conversions, Java strips away any such meta-info. Matlab has no way of knowing whether the array should be a row or column array, because this meta-info is not stored by Java, so the decision to create a column Matlab array is just as valid as a decision to create a row array.

      If you wish to store the Matlab data including the meta-info, then you need to serialize your Matlab data before storing it, and deserialize it back when you read it:

  7. Jonathan Mathews says:

    Thank you for the tutorial. I found this resource for a java stacks queues tutorial. They cover an implementation through a linked list. Does it matter if you build it from scratch or through a linked list?


  8. Phil says:

    Is there any workaround to prevent Matlab from automatic converting scalar, numeric Java types into doubles? (described here

    See the following simple example:

    % initialize hashmap
    map = java.util.LinkedHashMap();
    % add a k/v pair with integer vector value
    map.put('key1', int32([5 6 7]));
    % add a k/v pair with integer scalar value
    map.put('key2', int32(5));
    % get the value for key1 - it's an int32, as one would expect
    % get the value for key2 - it's a double - Matlab automatically converted this
    % is there any way to get this value's type before it is converted?
    % conversion, so that I cam 
    • @Phil – as you discovered, this conversion is automatically done by Matlab. I am not familiar with a way to override it. The best choice is to store the scalar along with some dummy value, and only use the first item in the array when you fetch it back from the hashmap.

      >> map.put('key2', int32([5,0]));
      >> data = map.get('key2')
      data =
        2×1 int32 column vector
      >> data(1)
      ans =

Leave a Reply

Your email address will not be published. Required fields are marked *