7

I am currently building an LRU cache where I need to store the last N inserted items. Items will be inserted frequently (i.e. many write operations) and read operations will typically return a large number of events always strictly in sequence albeit starting at an arbitrary point in the cache. For example, suppose the cache contains events:

[1, 2, 3, 4, 5, 6]

A legal read operation would be to return an iterator over events [2, 3, 4].

Due to read operations potentially being long-lived I'd like to use a data structure where I can safely iterate over a logical copy of the sequence for each read attempt, thus preventing a cache read from holding up any subsequent writes. However, using a vanilla Java ArrayList or LinkedList implies a large overhead in making a full copy.

My question: Are there any 3rd party Java libraries that provide immutable data structures similar to Scala, whereby attempts to modify the data structure return a new immutable copy (which is in fact based on the original data structure and hence the copy operation is very fast)? Obviously the data structure could not conform to the Java Collections API as operations like add(T) would need to return the new collection (rather than void).

(Please no comments / answers citing this as a case of premature optimisation.)

Thanks in advance.

Note

Guava's ImmutableList nearly achieves what I need: It allows to you call copyOf where the copy typically references the original (avoiding performing an actual copy). Unfortunately you can't go the other way and add an item to the list and get back a copy that includes the new element.

Adamski
  • 54,009
  • 15
  • 113
  • 152
  • Why don't you want to create necessary Java interface and then implement it in Scala? – Roman Jul 07 '11 at 11:54
  • Roman - Fair point but the entire codebase is written in Java and I don't want to mix in a second language. – Adamski Jul 07 '11 at 11:56
  • @Adamski: Are you sure the Scala collections do anything "fancier"? (If they do, please report back). You could look at the source and replicate what they do in Java. – Thilo Jul 07 '11 at 12:20
  • I have read that a Scala "List is immutable and has constant-time prepend and linear-time append." http://stackoverflow.com/questions/1241166/preferred-way-to-create-a-scala-list/1241394#1241394 That sounds like a linked list with tail sharing (unfortunately Java's linked list does not allow that). – Thilo Jul 07 '11 at 12:25
  • Guava can meet your needs. When you want to update the cache, use the builder pattern to create a new cache from the old one, then delete the old cache. The new cache will reuse all the old objects, so this is a very lightweight operation. When someone wants an immutable copy of the cache (or one of its items), return copyOf(), and they'll get access to an immutable snapshot. Caveat, if you're working with threads, make sure you synchronize the cache access & update methods. – mstahl Dec 05 '14 at 16:20
  • Please edit the title as it is misleading and does not describe the actual issue of the Question. – Basil Bourque Oct 09 '17 at 14:52

7 Answers7

7

Functional Java comes in the form of a library (not a different language) and provides immutable collections. Not sure if it'll fit your needs but worth a try.

Sanjay T. Sharma
  • 22,857
  • 4
  • 59
  • 71
3

Google Guava has immutable collections.

Sanjay T. Sharma
  • 22,857
  • 4
  • 59
  • 71
Thilo
  • 257,207
  • 101
  • 511
  • 656
  • Thanks Thilo but as far as I can see the ImmutableList doesn't allow you to make a logical copy that includes additional elements. – Adamski Jul 07 '11 at 11:57
  • Do you only need to add to the end? Or all kinds of manipulations? That would be tricky to do in a general way without just copying the whole thing. – Thilo Jul 07 '11 at 12:03
  • Only to the end. The cache is conceptually a bounded queue (for write purposes). – Adamski Jul 07 '11 at 12:17
  • @Thilo: Nitpicking here: I'm Dutch, 15 years old. I want to verify: shouldn't it be "Google Guava **has** immutable collections."? – Martijn Courteaux Jul 07 '11 at 12:58
  • @Martijn. Maybe. I am German, what do I know. I was thinking of Guava as the group of people, not the product. So like "the police *have* found no evidence of foul play". – Thilo Jul 07 '11 at 23:24
  • @Thilo: Yeah, indeed, I saw that in school, the police is always plural. – Martijn Courteaux Jul 09 '11 at 11:21
  • The police *are* always plural ;-) – Thilo Jul 10 '11 at 02:31
2

Guava

Google Guava can meet your needs.

When you want to update the cache, use Guava's builder pattern to create a new cache from the old one, then delete the old cache.

To update the cache, create an ImmutableList.Builder() and initialize it with your existing ImmutableList. Modify the list through the Builder interface. Then call .build() to get a new ImmutableList, and delete the old cache. The new cache will reuse all the old objects, so this is a very lightweight operation.

When someone wants an immutable copy of the cache (or one of its items), return copyOf(), and they'll get access to an immutable snapshot.

Caveat, if you're working with threads, make sure you wrap the list in an object and synchronize it's get() & insert() methods.

You can read more at the Guava site.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
mstahl
  • 353
  • 3
  • 6
2

JDK 9 has new of() method factories. E.g. you can have an immutable Set as

Set<Integer> intSet = Set.of(1, 2, 3);

You can do the same with a List, e.g.

List<String> stringList = List.of("A", "B", "C");

and a Map:

Map<String, String> doubleMap = Map.of("key1", "val1", 
                                       "key2", "val2");
JeanValjean
  • 17,172
  • 23
  • 113
  • 157
  • Valuable and handy, but these are for literals, passing specific objects. I do not recall being able to pass an existing collection to make it immutable. Correct me if I am wrong. – Basil Bourque Oct 06 '17 at 22:00
  • @BasilBourque sorry, I'm not sure that I got your point. If you need an immutable view of a collection can't you use ``Collections.unmodifiableMap``, ``Collections.unmodifiableList`` and ``Collections.unmodifiableSet``? – JeanValjean Oct 09 '17 at 11:05
  • The Question asked for something where "attempts to modify the data structure return a new immutable copy". This Answer, while interesting new info, does not address the Question. – Basil Bourque Oct 09 '17 at 14:49
1

Pure4J

Provides immutable collections via copies of the Clojure persistent collections classes. It might not be exactly what you are after, as it is about enforcing pure functional semantics on (subsets of) java programs.

On the other hand, it has immutability guarantees for both elements and collections. When you add/remove an element from a collection you get back a new collection and the original remains unchanged.

Rob Moffat
  • 465
  • 5
  • 11
1

Have you looked at the CopyOnWriteArrrayList? Each mutation to the list will copy all contents to a new backing array leaving the current array you may be iterating on uneffected.

Sanjay T. Sharma
  • 22,857
  • 4
  • 59
  • 71
John Vint
  • 39,695
  • 7
  • 78
  • 108
  • 1
    Yes I have but unfortunately this would be even worse than using say LinkedList because my write operations are so frequent I'd forever be taking copies of the list. If writes were infrequent I'd definitely take this approach (so have an upvote :-)). – Adamski Jul 07 '11 at 12:00
  • Oh I see. Good decision on your part then :) I talked to Doug about why the compare method throws an UnsupportedOperationException and it is because a sort would be ungodly slow. – John Vint Jul 07 '11 at 13:23
1

It looks like you want to implement a singly-linked list here, which can then be shared by different wrapper objects. Do you ever want to remove elements, or do you only append new ones?

If there is only adding and no removal, I suppose a simpler variant of CopyOnWriteArrayList, which only makes the copy whenever the old array is full, could do. The sublist() methods then would simply create a new wrapper object.

/**
 * A list which only supports appending objects.
 */
public class OnlyAppendingList<E> extends AbstractList<E> {

    private Object[] data;
    private int len;

    public int size() {
        return this.len;
    }

    public E get(int index) {
        if(index >= this.len)
           throw new IndexOutOfBoundsException(index + " >= " + this.len);
        @SuppressWarnings("unchecked")
        E res = this.data[index];
        return res;
    }

    public boolean add(E element) {
        if(len == data.length) {
             this.resize();
        }
        this.data[this.len] = element;
        this.len++;
        return true;
    }

    private void resize() {
        this.data = Arrays.copyOf(data, data.length * 2 +2);
    }

    public void add(int index, E element) {
       if(index > this.len) {
          throw new IndexOutOfBoundsException(index + " > " + len);
       }
       if(index < this.len) {
           throw new UnsupportedOperationException("we only support appending, not insertion!");
       }
       this.add(element);
    }


    /**
     * Returns an immutable sublist of this list.
     */
    public List<E> subList(final int fromIndex, final int toIndex) {
        // TODO: bounds checks
        return new SubList<E>(this.data, fromIndex, fromIndex - toIndex);
    }

    private static class SubList<E> extends AbstractList<E> {
        private Object[] data;
        private int start;
        private int len;

        SubList(Object[] data, int start, int len) {
            this.data = data; this.start = start; this.len = len;
        }

        public int size() {
            return this.len;
        }

        public E get(int index) {
            if(index >= this.len)
               throw new IndexOutOfBoundsException(index + " >= " + this.len);
            if(index < 0)
               throw new IndexOutOfBoundsException(index + " < 0");

            @SuppressWarnings("unchecked")
            E res = this.data[index + start];
            return res;
        }
        public List<E> subList(int from, int to) {
            // TODO: bounds check
            return new SubList(data, start + from, to - from);
        }
    }
}

If this is modified by multiple threads, you should make the add method synchronized and the len variable volatile, I think. (I did not completely check that it then is threadsafe.)

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210