Example. The GuestList interface (Object version)

[comp1110-49]
  • Liam O'Connor, Fabian Muehlboeck

The original GuestList interface used String throughout. Replacing String with Object allows any type of value to be stored, since every Java class is a subtype of Object:

public interface GuestList { // record that a guest is coming void add(Object name); // record that a guest is no longer coming void remove(Object name); // query whether a guest is coming boolean isComing(Object name); }

Our implementations (both strict and lazy) can be easily adapted by replacing the type String with Object throughout. Because Object already specifies the equals method, we've gained a lot of flexibility for essentially no cost, which is great! The tricky part comes when we are also supposed to return values stored in our list.

Consider our previous extension of the above interface where we also return a list of everyone who is coming, this time with Object:

Object[] coming();

This method now returns an array of Objects, when our testing code would presumably expect an array of Strings. We can adjust our testing code to expect Object arrays, and we can explicitly cast the elements of the array to our expected type.

However, this approach sacrifices type safety. Nothing prevents a caller from adding a mix of unrelated types to the same list, and retrieving a value requires an explicit cast (e.g. (String) list.coming()[0]) that can fail at runtime with a ClassCastException. The compiler cannot catch such errors.

Context

    Making Our Types Generic

    [comp1110-8M]
    • Fabian Muehlboeck

    Construction. The Object type

    [comp1110-4A]
    • Liam O'Connor, Fabian Muehlboeck

    In Java, Object is the root of the class hierarchy: every class is a subtype of Object. This means a variable of type Object can hold a value of any class: a String, an Integer, a Person, and so on.

    Object x = "hello"; // fine Object y = 42; // fine Object z = new Person("Fabian"); // fine

    The Object type, among other things, defines a .equals() method, so values of type Object can be compared for equality, but very few other operations are available. Many classes provide override .equals() to perform a deep comparison, as we have seen for Strings.

    The downside is that the compiler knows very little about the value stored in an Object variable: to use it as its original type, an explicit cast is needed.

    Example. The GuestList interface (Object version)

    [comp1110-49]
    • Liam O'Connor, Fabian Muehlboeck

    The original GuestList interface used String throughout. Replacing String with Object allows any type of value to be stored, since every Java class is a subtype of Object:

    public interface GuestList { // record that a guest is coming void add(Object name); // record that a guest is no longer coming void remove(Object name); // query whether a guest is coming boolean isComing(Object name); }

    Our implementations (both strict and lazy) can be easily adapted by replacing the type String with Object throughout. Because Object already specifies the equals method, we've gained a lot of flexibility for essentially no cost, which is great! The tricky part comes when we are also supposed to return values stored in our list.

    Consider our previous extension of the above interface where we also return a list of everyone who is coming, this time with Object:

    Object[] coming();

    This method now returns an array of Objects, when our testing code would presumably expect an array of Strings. We can adjust our testing code to expect Object arrays, and we can explicitly cast the elements of the array to our expected type.

    However, this approach sacrifices type safety. Nothing prevents a caller from adding a mix of unrelated types to the same list, and retrieving a value requires an explicit cast (e.g. (String) list.coming()[0]) that can fail at runtime with a ClassCastException. The compiler cannot catch such errors.

    Construction. Casts

    [comp1110-4B]
    • Liam O'Connor

    A cast tells the compiler to treat a value as a more specific type than it currently knows about. The syntax is to write the target type in parentheses before the expression:

    Object x = "hello"; String s = (String) x; // cast from Object to String

    Casts are necessary when retrieving values from a collection that stores Object, since the compiler only knows the value is an Object, not what type it originally was when created.

    However, if the cast is wrong (for example, casting a String to an Integer), Java throws an exception called ClassCastException at runtime. The compiler cannot catch this mistake. This is one of the key motivations for type parameters, which avoid the need for casts entirely.

    Construction. Type parameters

    [comp1110-48]
    • Liam O'Connor, Fabian Muehlboeck

    A type parameter allows a class or interface to be written once and used with many different types, while retaining type safety (unlike Object). We write the type parameter in angle brackets after the class or interface name, and use it as a placeholder for a concrete type throughout. Referring to our GuestList example:

    public interface GuestList<T> { void add(T name); void remove(T name); boolean isComing(T name); // note the additional argument here T[] coming(Function<Integer, T[]> arrayCreator); }

    When using the interface, the caller fills in the placeholder with a concrete type:

    GuestList<String> list = new ArrayGuestList<String>();

    The compiler then treats every occurrence of T as String for that particular instance of the class. This means list.add(42) is a compile-time error, since 42 is not a String. Whereas using Object, such mistakes are only caught at run time.

    This feature is also known as generics in Java, or more generally as parametric polymorphism.

    Example. Lazy Array Implementation of GuestList (generic version)

    [comp1110-4C]
    • Liam O'Connor, Fabian Muehlboeck

    Updating ArrayGuestList to match the generic interface requires adding the type parameter <T> to the class declaration and replacing Object with T in the method signatures. The internal storage remains Object[], however, due to type erasure:

    public class GuestArrayList<T> implements GuestList<T> { Object[] data = new Object[]{null, null}; int count = 0; @Override public void add(T name) { if(count == data.length) { Object[] old = data; data = new Object[count * 2]; for(int i = 0; i < count; i++) { data[i] = old[i]; } } data[count] = name; count = count + 1; } @Override public void remove(T name) { int i = 0; while(i<count) { if(data[i] != null && data[i].equals(name)) { data[i]=null; } i = i +1; } } @Override public boolean isComing(T name) { int i = 0; while(i<count) { if(Objects.equals(data[i],name)) { return true; } i = i +1; } return false; } @Override public T[] coming(Function<Integer, T[]> arrayCreator) { T[] result = arrayCreator.apply(count); int i=0; while(i < count) { result[i] = (T)data[i]; i = i + 1; } return result; } }

    Type erasure is also the reason why the coming method needs an additional argument. Because we are expected to return an array of T, but still cannot create one, we need to be given an object that can create such an array for us, given a size. Function is a generic interface with one method (called apply) that accepts two type arguments - the first one is the argument type of apply, the second is the return type. In this case, any object satisfying Function<Integer, T[] has an apply method that takes an integer (meant to be the intended size of the array) and returns an array (hopefully of the given size).

    A user of coming can of course pass any object satisfying the interface, but for any concrete array type, say, String[], we can simply write:

    String[] guests = myGuestList.coming(String[]::new);

    This special notation refers to the constructors of a given type, which for arrays always take an integer for the size of the array. We may talk about why this works at the end of the semester.

    Warning. Type erasure

    [comp1110-4D]
    • Liam O'Connor, Fabian Muehlboeck

    Java generics are implemented via type erasure: at runtime, the type parameter T is erased to Object, so the expression new T[n] is illegal: the Java runtime has no idea what T is. Any generic class that needs an array internally must therefore either allocate an Object[] and cast values out of it appropriately, or somehow get an object that knows what to create:

    // Inside a generic class with type parameter T: private Object[] data; // must be Object[], not T[] @Override public T[] coming(Function<Integer, T[]> arrayCreator) { T[] result = arrayCreator.apply(count); int i=0; while(i < count) { result[i] = (T)data[i]; i = i + 1; } return result; }

    The casts inserted here work in practice as long as only values of type T are inserted — and this should be maintained through encapsulation — but it is a genuine limitation of how Java implements generics.

    Subtyping with Generics

    [comp1110-8O]
    • Fabian Muehlboeck

    Generics introduced a new kind of type: instantiated generic types. These are class types (which we have seen before), but now with type arguments, e.g. List<String>. In Java, subtyping is largely based on the inheritance hierarchy. With generics, that is still true, and in most cases, the additional requirement is that the type arguments between two types are the same.

    For example, in the Java Collections API, there are concrete classes ArrayList<T> and LinkedList<T>, which both implement the generic list interface List<T>, which in turn extends the generic interface Iterable<T>, which is a supertype of almost all collection interfaces and classes.

    Without type arguments, it therefore holds that ArrayList and LinkedList are subtypes of List, and List is a subtype of Iterable (and so are, transitively, ArrayList and LinkedList). This gets preserved with type arguments if the type arguments are the same. Therefore:

    • LinkedList<String> is a subtype of List<String> is a subtype of Iterable<String>
    • ArrayList<String> is a subtype of List<String> is a subtype of Iterable<String>
    • LinkedList<Object> is a subtype of List<Object> is a subtype of Iterable<Object>
    • ArrayList<Object> is a subtype of List<Object> is a subtype of Iterable<Object>
    But:
    • LinkedList<String> is not a subtype of List<Object>
    • List<String> is not a subtype of Iterable<Object>
    • ArrayList<Object> is not a subtype of List<String>
    • List<Object> is not a subtype of Iterable<String>
    • ...

    The reason for this in principle is Behavioural Subtyping. Take, for example, LinkedList<String> and List<Object>. From the outer types, we know that if at all, LinkedList<String> would be a subtype of List<Object>. This works fine for reading from the list:

    //NOTE: not legal Java code LinkedList<String> strs = new LinkedList<String>(); strs.add("Hello"); List<Object> objs = strs; Object o = objs.get(0);

    Since a LinkedList<String> stores String values, and objs.get is supposed to return an Object, and every String is an Object, this code is not problematic (though illegal). The problem here comes in when we write to the list:

    //NOTE: not legal Java code LinkedList<String> strs = new LinkedList<String>(); List<Object> objs = strs; objs.add(new Person("Fabian", 38));

    A List<Object> should be able to contain arbitrary objects, so the call to add with a Person value is fine. But that would be a problem if the underlying list object is a List<String>, which is not supposed to contain Person values.

    The same argument works the other way around (that LinkedList<Object> is not a subtype of List<String>) - this time, the problem is reading from the list, as one would expect that a List<String> returns a String, but a LinkedList<Object> cannot guarantee that.

    Warning. 

    • Fabian Muehlboeck
     This argument would technically also apply to arrays. However, Java (and other languages) violates type safety here by treating String[] as a subtype of Object[]. You can write code that relies on this so long as you only read from those arrays - trying to write a value of a wrong type to them will throw an exception at run time. You still cannot treat an Object[] as an array of some other type (e.g. String[]). This will fail at the point where you cast the array to that other array type, even if you never read from the array. This is why we could not simply cast the array in implementing the coming function in the GuestList example.

    Backlinks

      Construction. Type parameters

      [comp1110-48]
      • Liam O'Connor, Fabian Muehlboeck

      A type parameter allows a class or interface to be written once and used with many different types, while retaining type safety (unlike Object). We write the type parameter in angle brackets after the class or interface name, and use it as a placeholder for a concrete type throughout. Referring to our GuestList example:

      public interface GuestList<T> { void add(T name); void remove(T name); boolean isComing(T name); // note the additional argument here T[] coming(Function<Integer, T[]> arrayCreator); }

      When using the interface, the caller fills in the placeholder with a concrete type:

      GuestList<String> list = new ArrayGuestList<String>();

      The compiler then treats every occurrence of T as String for that particular instance of the class. This means list.add(42) is a compile-time error, since 42 is not a String. Whereas using Object, such mistakes are only caught at run time.

      This feature is also known as generics in Java, or more generally as parametric polymorphism.

      Related

        Construction. Casts

        [comp1110-4B]
        • Liam O'Connor

        A cast tells the compiler to treat a value as a more specific type than it currently knows about. The syntax is to write the target type in parentheses before the expression:

        Object x = "hello"; String s = (String) x; // cast from Object to String

        Casts are necessary when retrieving values from a collection that stores Object, since the compiler only knows the value is an Object, not what type it originally was when created.

        However, if the cast is wrong (for example, casting a String to an Integer), Java throws an exception called ClassCastException at runtime. The compiler cannot catch this mistake. This is one of the key motivations for type parameters, which avoid the need for casts entirely.

        Construction. Class Definitions

        [comp1110-80]
        • Fabian Muehlboeck

        In Java, objects are instances of classes. A class definition is a kind of data definition, similar to what we have seen before for enums. However, classes are much more powerful, and they are used to model pretty much everything in our programs that cannot be modeled by a simpler data type. The core parts we will deal with for now are fields, which contain an object's data, and methods, which define an object's behaviour. The basic definition of a class consists of the keyword class and a class name, followed by curly braces, like so:

        class Person { //this is where the fields and methods of a class go }

        This does define a new type Person. To create a new instance of it (i.e. an object), you could write something simliar to what we did for arrays, using the keyword new:

        Person p = new Person();

        This is not very useful, because the Person class above has no data or behaviour, but you can add those.

        By convention, class names in Java should be nouns that start with a capital letter, and use capital letters to mark the start of any word internal to the name. For example: LectureNote .

        Construction. Fields

        [comp1110-81]
        • Fabian Muehlboeck

        Every class can have arbitrarily many fields. At the very least, each field has a type and name, just like a local variable. There are some other properties that fields can have, which we'll see later. To define a field, you declare it just like a local variable:

        String name;

        You can also give the field a default value, just like a local variable definitions:

        String name = "Unknown";

        By convention, in Java, field names are camelCased. That is, they start with a lower-case letter and otherwise contain only letters and digits, with uppercase letters indicating the start of a new combined word, as in sumOfAllParts.

        In principle, you can read and write the fields of an object similar to how you can read and write individual array elements, though the syntax is more like when you ask an array for its length:

        String oname = obj.name; if(oname.equals("Unknown")) { obj.name = "Timmy"; }

        Warning. 

        • Fabian Muehlboeck
        Note that array.length has the special property that you cannot assign values to it.

        Example. Fields

        [comp1110-82]
        • Fabian Muehlboeck

        Say we want our Person class from earlier to have two fields: one representing the name of the person, and one representing their age. Names would typically be represented as Strings, and in our case, we only care about completed years of age, so we use int as the type for that field.

        class Person { int age; String name; }

        We can then create a new Person value and write to its fields:

        Person p = new Person(); p.name = "Timmy"; p.age = 5;

        Warning. 

        • Fabian Muehlboeck
        This is not how you would typically do this; we'll learn about the right way to do this later.

        Construction. Methods

        [comp1110-83]
        • Fabian Muehlboeck

        So far, we have sometimes written code in separate functions from the main function. But in every case so far, we had to give those functions all the arguments that they were supposed to work with.

        Methods defined in a class implicitly have access to the fields defined in that class. This is because methods always need to be called on a specifc object, whose field values can then be used within the method.

        So in principle, writing a method is just like writing a function, except inside a class. Within the class, you can all other methods within the class just like we called functions before.

        By convention, in Java, method names are camelCased. That is, they start with a lower-case letter and otherwise contain only letters and digits, with uppercase letters indicating the start of a new combined word, as in sumOfAllParts.

        class MyClass { int myMethod() { return 42; } }

        Example. Methods

        [comp1110-84]
        • Fabian Muehlboeck

        Building on our example from Example [comp1110-82], imagine we want to just have a way to print a nice description for any of our basic Person objects.

        To do this, we'll add a printDescription method to the class:

        class Person { int age; String name; void printDescription() { IO.println(name + " (Age " + age + ")"); } }

        We can try this with the following main function:

        void main() { Person p = new Person(); p.name = "Timmy"; p.age = 5; p.printDescription(); }

        This will print:

        Timmy (Age 5)

        Have we seen Objects before?

        [comp1110-85]
        • Fabian Muehlboeck

        Yes! Every string and array is an object. When we wrote guess.charAt(5), we were calling a method of the String class on the particular String object referred to by guess.

        Similarly, the difference between arr.length for arrays and str.length() for strings is that the former is a field that we can access, and the latter is a method we have to call.

        Example. Encapsulation danger when returning internal arrays

        [comp1110-46]
        • Liam O'Connor, Fabian Muehlboeck

        Suppose we extend the GuestList interface with a method coming() that returns the current list of guests. This seems straightforward, but a naive implementation illustrates a common encapsulation hazard: returning a direct reference to the internal array.

        // DANGEROUS — exposes internal state public String[] coming() { return this.data; }

        A caller who receives this reference can write list.coming()[0] = "Intruder" and corrupt the guest list without going through add or remove, potentially breaking the data invariant. The correct fix is to return a defensive copy:

        // SAFE — caller gets their own array public String[] coming() { String[] copy = new String[this.count]; int i = 0; while (i < this.count) { copy[i] = this.data[i]; i = i + 1; } return copy; }

        Example. Lazy array implementation of GuestList

        [comp1110-42]
        • Liam O'Connor, Fabian Muehlboeck

        The first implementation of the GuestList interface stores names in a plain String[] array. It is called lazy because add does not check for duplicates before inserting. Duplicates are only resolved later, at remove time, by nulling out all occurrences.

        The lazy approach is simple but wastes space: the array may accumulate many nulls over time. When the array is filled up, we double its size (see Definition [comp1110-43]).

        public class GuestArrayList implements GuestList { String[] data = new String[]{null, null}; int count = 0; @Override public void add(String name) { if(count == data.length) { String[] old = data; data = new String[count * 2]; int i=0; while(i < count) { data[i] = old[i]; i = i + 1; } } data[count] = name; count = count + 1; } @Override public void remove(String name) { int i = 0; while(i < count) { if(data[i] != null && data[i].equals(name)) { data[i]=null; } i = i +1; } } @Override public boolean isComing(String name) { int i = 0; while(i < count) { if(Objects.equals(data[i], name)) { return true; } i = i + 1; } return false; } }

        Example. Strict array implementation of GuestList

        [comp1110-45]
        • Liam O'Connor, Fabian Muehlboeck

        This implementation of GuestList is called strict (as opposed to the lazy implementation) because it enforces uniqueness eagerly: add calls isComing first and returns immediately if the guest is already present.

        This implementation maintains the following data invariant: all non-null entries in data from 0 to count-1 are distinct. Because we are in the same package as GuestArrayList, we have access to its package-private fields and know about how its methods work. We also know that enforcing uniqueness changes nothing about the externally expected behaviour of the class. As such, we can make our new class a subtype of GuestArrayList, and use inheritance to reuse existing code, changing only what needs to be changed:

        public class GuestArrayUniqueList extends GuestArrayList { // Invariant: all non-null values in data[0..count-1] are unique @Override public void add(String name) { if(isComing(name)) { return; } super.add(name); } public void remove(String name) { int i = 0; while(i<count) { if(data[i] != null && data[i].equals(name)) { data[i]=null; return; } i = i +1; } } }

        The add method is overridden to the isComing check first. However, after this check, the code of the method is the same as before, and we can just call the superclass' implementation of that method instead of copying it into here.

        Because the invariant guarantees at most one copy exists, remove can stop after finding the first match. Contrast with the lazy implementation, where remove must scan the entire array to null out all copies. However, because this change to the code of remove is deep within the code of that method, we have to rewrite it fully, rather than calling the superclass' implementation.

        Example. The GuestList interface (String version)

        [comp1110-3X]
        • Liam O'Connor, Fabian Muehlboeck

        Our GuestList interface will represent a set of names. The interface exposes three operations:

        public interface GuestList { // record that a guest is coming void add(String name); // record that a guest is no longer coming void remove(String name); // query whether a guest is coming boolean isComing(String name); }

        The semantics are set-like: a guest is either coming or not; adding the same guest twice has the same effect as adding them once. The interface says nothing about how this is implemented — that is left to implementing classes.

        Construction. The Object type

        [comp1110-4A]
        • Liam O'Connor, Fabian Muehlboeck

        In Java, Object is the root of the class hierarchy: every class is a subtype of Object. This means a variable of type Object can hold a value of any class: a String, an Integer, a Person, and so on.

        Object x = "hello"; // fine Object y = 42; // fine Object z = new Person("Fabian"); // fine

        The Object type, among other things, defines a .equals() method, so values of type Object can be compared for equality, but very few other operations are available. Many classes provide override .equals() to perform a deep comparison, as we have seen for Strings.

        The downside is that the compiler knows very little about the value stored in an Object variable: to use it as its original type, an explicit cast is needed.

        bars magnifying-glass caret-down plus minus arrow-right xmark