Discussing the design, decisions and discovery involved in developing Mutability Detector, an open-source analysis tool for Java.

Sunday, 13 March 2011

Lightning Talk Introducing Mutability Detector

Here's a video of a lightning talk I gave at work, introducing Mutability Detector to my colleagues. I had to cut it short so as not to break the rules of a maximum 5 minute duration, but I think it gives a good overview. If you find my Scots accent tough to understand, you might prefer to check out a couple of the previous blogs, particularly the introduction to the first version released, and an overview of a more recent release.

The Mutability Detector from youdevisetech on Vimeo.


  1. Hi, this is to let you know that I appreciate your work very much.

    I myself am working on a compiler for "Frege" a pure, non-strict functional language very much like Haskell, but Frege is designed to run on the JVM, i.e. the compiler emits Java code.

    In Frege, one can use any Java class as an abstract data types, and this means that the compiler should know whether instances of this type are going to be mutable or not (up to now, I have to trust that it is declared correctly).

    I have the impression that your tool could answer such questions, and I'll try it out next time. Yet, I am interested not so much in technical immutability, but in "observational" immutability - think java.lang.String. To put it differently, I don't care if the implmentation of a class mutates private state that is never exposed to client code - as long as the public methods behave like pure functions. Feel free to drop me a mail if you'd like to discuss this further.

  2. Hey Ingo, thanks for your thanks :)

    Observational immutability is what I'm trying to aim for as well, but it turns out this is quite hard. For instance, taking String, automatically detecting that the reassignment of the hashCode field is a benign data race is not trivial. Couple this with a design tradeoff of "false positives over false negatives" (since detecting threading problems is hard enough) and the problem becomes more complex. Looking at the other tools in this area (FindBugs, Javari) they are very strict about what they allow, I'm hoping to be more... (for want of a better word) useful.

    There have been inroads in certain circumstances to strive for observational immutability: for instance, you can have setter methods which reassign a field, as long as they're only called from the constructor.

    I'd be interested to hear more about your use case, if Mutability Detector can help, and if not, what can I do to make it useful for you. If you have anything particular in mind, please post an issue to the google project page, and we can take it from there :-)

    Kind regards,