Java Magazine, Sept/Oct 2016

ORACLE COM JAVAMAGAZINE SEPTEMBER OCTOBER 2016 54 jvm languages system and standard library designed to support immutability Although immutable data structures are common in functional languages they typically arent built into mainstream object oriented languages Fields in Fantom may be marked const to guarantee that they are immutable const Point pt This snippet of code declares a field of type Point that has a compile time guarantee of deep immutability Deep immutability means that we not only guarantee that the pt reference is set only once but we also guarantee that everything the Point instance references is also immutable Contrast this with a Java final field that provides only shallow immutability the reference cannot be changed but there is no guarantee of immutability for the referenced objects Deep immutability is guaranteed by the type system using const classes const class Point new make Int x Int y this x x this y y const Int x const Int y In the preceding example the entire class is marked const which uses compile time checking to ensure that instances of the class are deeply immutable Specifically this means that all fields are marked const and set only in the constructor the method named make annotated with the new keyword The standard library provides many conveniences for using a mutable data structure to build up a collection and then freezing it as an immutable instance list create an empty list list add a add some items list toImmutable returns immutable copy of list The snippet above uses an immutable list to build up a result and then uses the toImmutable method to eficiently get an immutable copy of the list Similar APIs are available for other collection types in memory byte bufers and even functions Once we have immutable instances we can safely assign them to const fields and share them between threads Concurrency Fantoms approach to concurrency is built around this key concept make it impossible to share mutable state between threads Enforcing this restriction makes it much easier to reason about concurrency avoids deadlocks and race conditions and greatly increases robustness Fantom achieves this goal with a built in concurrency model based on actors There is no synchronized or volatile mechanism in Fantom there are only actors Actors are lightweight objects designed to asynchronously process work on a thread pool Interaction with actors is done via a message queue Client code sends a message to an actor and is returned a Future which the client can optionally use to block until the result is ready Messages sent to actors are queued Once the actor framework detects that an actor has pending messages the actor is scheduled to a thread to process its message queue via the receive method Actors are guaranteed to receive their messages in order and to safely execute within one thread Lets look at a simple example for an actor that receives integer messages and returns the mathematical square Here is our actor class const class SquareActor Actor