This package is a collection of types with immutable objects based on the RESOLVE specification language's mathematical models. An object is immutable if it has no time-varying state. The methods defined for objects of such types thus return other objects instead of making changes in place, as would occur for a mutable object. This package also contains enumerators (which are mutable) for the types of immutable collections in the package.

The types of the immutable objects in this package are all pure, meaning that none of their specified methods have any user-visible side-effects (although a few inherited from {@link java.lang.Object} do have side effects). Their pure methods, are designed for use in JML specifications. When using such methods you have to do something with the result returned by the method, as in functional programming. The original object's state is never changed by a pure method.

For example, to insert an element, e, into a set, s, one might execute s.insert(e), but this does not change the object s in any way; instead, it returns a set that contains all the old elements of s as well as e. Don't worry about the time and space used to do make such a set -- remember that specifications are not mainly designed to be executed. If you're worried about efficiency, you aren't using the right frame of mind.

The enumerator types are mutable objects and some of their methods are not pure. These impure methods can't be used in specifications in JML.


There are several kinds of types in this package. These are described below.

Kinds of CompareTo

The interface CompareTo and its subtypes (such as AntisymmetricCompareTo, PreorderedCompareTo, etc.) represent different assumptions about a type's compareTo operator.

Unlike the {@link java.lang.Comparable} interface, these interfaces have a compareTo operation that can throw an UndefinedException when the comparison between objects (of appropriate types) is undefined. This allows the specification of partial orders. On the other hand, the compareTo operation of the type TotalCompareTo and its subtypes cannot throw this exception.

The type TotallyOrderedCompareTo is essentially equivalent to {@link java.lang.Comparable}.

See the package tree diagram (in the generated javadocs) for the details of the relationships among these interfaces.


Perhaps the most useful model types are the various kinds of collections. (We use the term ``collection'' in a generic way, since these types do not implement the {@link java.util.Collection} interface, because that assumes collections are mutable objects.)

Primitive types

The type NaturalNumber models infinite precision natural numbers.

Object collections

The type StringOfObject models finite mathematical strings (i.e., sequences) of objects. The elements of a string are object references. When an object is inserted into such a string, it is not cloned. The equality test used by the has method uses Java's == operator to compare addresses of these objects.


The code relies heavily on the org.jmlspecs.models package, whenever possible.

In the test data classes (the files), we take advantage of the fact that the types are pure to speed up the JUnit-based testing. We also sometimes take advantage of the fact that other test data, particularly of type Object and JMLType are either not mutated by the tests or are actually immutable objects. (Note that new Object() produces a new immutable object!) Typically, the tests don't call any methods on the objects in the collections that would mutate them, so this is okay.

The source code for this package uses the GNU Lesser General Public License, since it is part of the JML runtime libraries.


These types were designed by Gary T. Leavens in collaboration with Stephen Edwards, Murali Sitaraman, and their students. The specifications are primarily based on the work of William Ogden, in particular his notes for CIS 680 at the Ohio State University.

This work was supported in part by the (US) National Science Foundation under grants CCR-0097907, and CCR-0113181.