Object Creation and Storage (Instantiation)

A class is only a blueprint. A blueprint for a house is not a house you can live in; someone has to build the house from it. In the same way, before your program can use a String holding your name or a Scanner reading the keyboard, an actual object has to be built from the class. How does a program ask Java to build one?

Every class comes with special blocks of code whose only job is to build objects of that class. Think of them as the construction crew that comes with the blueprint. You ask for a new object, the crew builds it, and you get back the object’s address.

That construction code is called a constructor: a block of code in a class that runs to create a new object of that class. Two facts make constructors easy to spot:

• A constructor has the same name as its class, capital letter and all. The String class has constructors named String; the Scanner class has constructors named Scanner.
• You call a constructor by writing the keyword new in front of it. new tells Java “build a brand-new object,” and the constructor call after it says which class to build and with what information.

Creating an object this way is called instantiation, because the result is a new instance of the class (the word “instance” from Topic 1.12).

String greeting = new String("Good morning");

String greeting = new String("Good morning");
System.out.println(greeting);

Good morning

Now change the class. You have used this line since Topic 1.4, perhaps without knowing what each word meant:

import java.util.Scanner;

public class KeyboardScanner
{
    public static void main(String[] args)
    {
        Scanner keyboard = new Scanner(System.in);
        System.out.println("A Scanner object is ready.");
    }
}

Line 7 follows exactly the same pattern. Scanner keyboard declares a variable that can refer to a Scanner. new Scanner(System.in) calls the Scanner constructor, passing it System.in, which stands for the keyboard. The constructor builds a Scanner object connected to the keyboard, and its reference is stored in keyboard. The program then prints its message:

A Scanner object is ready.

Nothing was typed, and nothing needed to be: creating the Scanner only sets it up to read. Reading happens later, when you ask it for input. The class changed (String to Scanner) and so did the information passed in, but the shape Type name = new Type(...); stayed the same.

(You have probably also written String name = "Ada"; without new. A string literal is a shortcut that String alone gets; Topic 1.15 covers it. For every other class, objects come from new.)

String greeting = String("Good morning");
System.out.println(greeting);

import java.util.Scanner;

public class ScannerNoNew
{
    public static void main(String[] args)
    {
        Scanner input = Scanner(System.in);
        System.out.println("Ready");
    }
}

Scanner input = new Scanner(System.in);

Building an object is only half the job. If the reference that new hands back is not stored anywhere, your program has no way to find the object again. So where does it go, and what type must that variable be?

Recall from Topic 1.12 that a variable of a reference type holds a reference, which you can think of as the memory address of an object, not the object itself. Picture the object as a house and the variable as a sticky note with the house’s address written on it.

The variable’s type must match the kind of object it will refer to. A String variable holds references to String objects; a Scanner variable holds references to Scanner objects. The type is the class name, so declaring the variable looks just like Topic 1.2, with a class name where a primitive type would go: Scanner keyboard;, String city;.

There is one more thing a reference variable can hold. Sometimes there is no object yet, or no object at all. For that, Java has the literal null (from Topic 1.4), a special value meaning “this variable does not refer to any object.” On the sticky-note picture, null is a note with no address on it. Where the picture stops working: a real sticky note can be blank because someone forgot; null is a deliberate value you can assign and print.

String city = new String("Denver");
String sameCity = city;
System.out.println(city);
System.out.println(sameCity);

Denver
Denver

Now vary the starting value. This time the variable starts with no object at all:

String nickname = null;
System.out.println(nickname);
nickname = new String("Sky");
System.out.println(nickname);

When println is given a variable holding null, it prints the word null. Line 3 then creates an object and stores its reference, replacing null just as any assignment replaces an old value.

import java.util.Scanner;

public class WrongVariableType
{
    public static void main(String[] args)
    {
        String keyboard = new Scanner(System.in);
        System.out.println("Ready");
    }
}

int count = null;
System.out.println(count);

String captain = null;
String backup = new String("Rosa");
System.out.println(captain);
captain = backup;
System.out.println(captain);
System.out.println(backup);

null
Rosa
Rosa

So far you have been given the right constructor call. When you meet a new class, though, how do you find out what to put in the parentheses? The same way you found out how to call a method in Topic 1.9: by reading its header in the documentation.

Here are two real constructor headers from the Java documentation, one for each class you know:

String(String original)
Scanner(InputStream source)

A constructor header looks a lot like a method header, with two differences. Its name is the class name. And there is no return type in front of it, not even void, because a constructor’s job is fixed: it builds an object of its own class.

The part in parentheses is the parameter list. For each value the constructor needs, it lists the value’s type and a parameter name: String original means “give me a String; inside the constructor it will be called original.” InputStream source means “give me an InputStream” (the type of System.in, the keyboard).

From the header you can read off the constructor’s signature: the constructor’s name followed by the ordered list of parameter types. The parameter names are left out of the signature.

The last row is a constructor with an empty parameter list: it needs no information at all. Its signature is just the name with empty parentheses.

Why do the parameter names drop out? Because the caller never uses them. When you write new String("Hi"), all Java has to check is that you passed one String. Whether the constructor calls it original or text inside makes no difference from outside.

Ticket(String movie, int seat, double price)

Order is part of the signature. A constructor with header Ticket(int seat, String movie, double price) would have the signature Ticket(int, String, double), a different signature, even though it uses the same three types.

public class DuplicateSignature
{
    public static void main(String[] args)
    {
        Ticket myTicket = new Ticket("Dune", 14, 12.5);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.println(movie);
    }

    Ticket(String title, int row, double cost)
    {
        System.out.println(title);
    }
}

Why do constructors take parameters at all? Because a brand-new object has to start out holding something. A String object holds characters, but which characters? A Scanner reads text, but from where? The object cannot guess; the code that asks for it has to say.

That is the job of constructor parameters. When you call a constructor, the values you pass in become the object’s starting values: the initial values of its attributes (the data each object keeps, from Topic 1.12). Different values passed in mean different objects come out.

Here is what that means for the String(String original) constructor. Its documentation says the new object holds the same characters as the String it was given. So the argument decides the new object’s characters.

String first = new String("Ada");
String second = new String("Grace");
System.out.println(first);
System.out.println(second);

Ada
Grace

Now vary the class. Scanner has a constructor Scanner(String source) whose parameter sets the text the Scanner will read from, instead of the keyboard. That makes a handy, predictable example, because no one has to type anything:

import java.util.Scanner;

public class ScannerFromText
{
    public static void main(String[] args)
    {
        Scanner reader = new Scanner("85 92");
        int firstScore = reader.nextInt();
        int secondScore = reader.nextInt();
        System.out.println(firstScore);
        System.out.println(secondScore);
    }
}

Line 7 builds a Scanner whose starting text is 85 92. Line 8 calls nextInt, which (as in Topic 1.4) reads the next whole number, so firstScore gets 85; line 9 reads the next one, so secondScore gets 92. (Calling methods on an object, like reader.nextInt(), is taught fully in Topic 1.14.)

85
92

The argument "85 92" decided what this Scanner would read. Pass "60 75" instead, and the same lines would print 60 and 75.

String empty = new String();
String missing = null;
System.out.print("[");
System.out.print(empty);
System.out.println("]");
System.out.print("[");
System.out.print(missing);
System.out.println("]");

[]
[null]

import java.util.Scanner;

public class MinutesReader
{
    public static void main(String[] args)
    {
        Scanner times = new Scanner("40 15");
        String runner = new String("Jo");
        int warmUp = times.nextInt();
        int coolDown = times.nextInt();
        System.out.println(runner);
        System.out.println(coolDown);
        System.out.println(warmUp);
    }
}

Jo
15
40

You have now seen two String constructors, String() and String(String original), and two Scanner constructors, one taking System.in and one taking a String. Why would a class have more than one way to build an object?

Because people want objects that start out in different ways. Sometimes you want a String with given characters; sometimes you want an empty one. Sometimes a Scanner should read the keyboard; sometimes it should read text you already have. Rather than invent a different name for each, the class offers several constructors with the same name, each with its own parameter list. This is the same idea as overloaded methods in Topic 1.9.

Constructors are overloaded when a class has more than one constructor with different signatures. Since every constructor of a class has the same name, “different signatures” means the parameter lists differ: a different number of parameters, different types, or the same types in a different order.

How does Java know which one you mean? It compares your arguments to each signature and picks the one whose parameter list matches: same number, and compatible types in the same order. That is exactly why two constructors in one class may never share a signature: Java would have no way to choose.

import java.util.Scanner;

public class TwoScanners
{
    public static void main(String[] args)
    {
        Scanner keyboard = new Scanner(System.in);
        Scanner scores = new Scanner("70 88");
        int score = scores.nextInt();
        System.out.println(score);
    }
}

70

Now vary the number of arguments instead of the type. For String:

Here the count of arguments is enough to tell the two constructors apart.

String digits = new String(5);
System.out.println(digits);

Lamp()
Lamp(int brightness)
Lamp(String color, int brightness)

A signature tells you what a constructor needs. What exactly counts as giving it what it needs, and what happens if you get it slightly wrong?

As in Topic 1.9, an argument is a value passed in when the call is made: the values between the parentheses after new Ticket. The parameters are the variables in the header that receive them. Java pairs them up by position: the first argument goes to the first parameter, the second to the second, and so on. That pairing works only if three things line up:

• Number: exactly as many arguments as parameters.
• Order: the arguments come in the same order as the parameter types.
• Type: each argument is compatible with its parameter’s type, meaning it is that type or one Java converts to it automatically. From Topic 1.5, an int converts to a double automatically; a double never converts to an int on its own, because that could lose the decimal part.

Why so strict? Java pairs by position, not by meaning. It cannot tell that 14 “looks like” a seat number; it only knows the second parameter is an int.

public class TicketArguments
{
    public static void main(String[] args)
    {
        Ticket myTicket = new Ticket("Dune", 14, 12);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.println(movie);
        System.out.println(seat);
        System.out.println(price);
    }
}

Dune
14
12.0

Now vary the order and the count. Each of these calls is one small change from line 5 above, and none of them compiles:

The type mistake is the easiest to miss, so here it is as a full program:

public class TicketLossy
{
    public static void main(String[] args)
    {
        Ticket myTicket = new Ticket("Dune", 12.5, 14);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.println(movie);
    }
}

The third argument 14 going to double price would be fine. The problem is the second: 12.5 cannot go into an int without losing .5, so Java refuses.

public class TicketMissingPrice
{
    public static void main(String[] args)
    {
        Ticket matinee = new Ticket("Up", 4);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.println(movie);
    }
}

Ticket matinee = new Ticket("Up", 4, 8.5);

When you hand a value to a constructor and the constructor changes its parameter, does your own variable change too? It matters: if passing a variable could change it behind your back, you could never trust a variable’s value after a call.

Topic 1.9 answered this for methods, and constructors work the same way. Arguments are passed using call by value: each parameter starts out holding a copy of its argument’s value. The constructor works with its copy. Your variable and the parameter are two separate boxes that happen to start with the same value.

Picture it like photocopying a form before handing it over. Whatever the other person writes on the copy, your original stays as it was.

public class SeatCopy
{
    public static void main(String[] args)
    {
        int mySeat = 14;
        Ticket myTicket = new Ticket("Dune", mySeat, 12.5);
        System.out.print("Back in main, mySeat is ");
        System.out.println(mySeat);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        seat = seat + 100;
        System.out.print("Inside the constructor, seat is ");
        System.out.println(seat);
    }
}

Inside the constructor, seat is 114
Back in main, mySeat is 14

Now vary the argument: it does not have to be a variable. It can be any expression of a compatible type. Java evaluates the expression first, then passes a copy of the result.

public class SeatExpression
{
    public static void main(String[] args)
    {
        int row = 3;
        Ticket myTicket = new Ticket("Dune", row * 10, 12.5);
        System.out.print("row is ");
        System.out.println(row);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.print("seat is ");
        System.out.println(seat);
    }
}

On line 6, row * 10 is evaluated to 30 before the constructor runs, and seat starts as a copy of 30. Computing the argument does not change row, so the program prints:

seat is 30
row is 3

public class PriceCopy
{
    public static void main(String[] args)
    {
        double cost = 10.0;
        Ticket myTicket = new Ticket("Up", 8, cost);
        System.out.println(cost);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        price = price / 2;
        System.out.println(price);
    }
}

5.0
10.0

In the last example, the constructor’s line printed before main’s next line, even though it sits lower in the file. Why? Because of the order in which the statements actually run.

Back in Topic 1.1, statements ran one after another, top to bottom. Topic 1.9 added an exception: a method call jumps into the method, runs it, and comes back. A constructor call does the same thing. When Java reaches new Ticket(...), it pauses the current statement, runs every statement in the constructor in order, and once the last one finishes, control returns to the point right after the call: it finishes the paused statement (storing the reference) and moves on to the next line. The order in which statements run is called the flow of control.

It is like pausing a video to answer the door. You deal with the visitor completely, then resume the video exactly where you stopped, not from the beginning.

public class ConstructorFlow
{
    public static void main(String[] args)
    {
        System.out.println("A: before the constructor call");
        Ticket myTicket = new Ticket("Dune", 14, 12.5);
        System.out.println("D: after the constructor call");
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.println("B: constructor starts");
        System.out.println("C: constructor ends");
    }
}

A: before the constructor call
B: constructor starts
C: constructor ends
D: after the constructor call

Now vary the number of calls. Each new makes its own jump, and each jump returns to just after its own call:

public class TwoTickets
{
    public static void main(String[] args)
    {
        Ticket first = new Ticket("Dune", 14, 12.5);
        System.out.println("Between tickets");
        Ticket second = new Ticket("Up", 3, 9.0);
        System.out.println("Done");
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.print("Printing ticket for ");
        System.out.println(movie);
    }
}

Line 5 jumps into the constructor (printing the ticket for Dune), comes back, and line 6 runs. Line 7 jumps in again with different arguments, comes back, and line 8 runs.

Printing ticket for Dune
Between tickets
Printing ticket for Up
Done

public class MovieNight
{
    public static void main(String[] args)
    {
        System.out.println("Line up");
        Ticket mine = new Ticket("Up", 5, 9.0);
        System.out.println("Buy popcorn");
        Ticket yours = new Ticket("Up", 6, 9.0);
        System.out.println("Find seats");
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.print("Ticket ");
        System.out.println(seat);
    }
}

Line up
Ticket 5
Buy popcorn
Ticket 6
Find seats

A box-office program reads a seat number and price from a Scanner and books a ticket. It uses every idea from this chapter. (A text-based Scanner stands in for the keyboard so the output is always the same.)

import java.util.Scanner;

public class BoxOffice
{
    public static void main(String[] args)
    {
        Scanner order = new Scanner("14 12");
        String movie = new String("Dune");
        int seatNumber = order.nextInt();
        int dollars = order.nextInt();
        Ticket booked = null;
        System.out.println("Booking...");
        booked = new Ticket(movie, seatNumber, dollars);
        System.out.print("Done. seatNumber is still ");
        System.out.println(seatNumber);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        System.out.print("Ticket for ");
        System.out.println(movie);
        seat = seat + 1;
        System.out.print("Seat ");
        System.out.println(seat);
        System.out.print("Price ");
        System.out.println(price);
    }
}

Booking...
Ticket for Dune
Seat 15
Price 12.0
Done. seatNumber is still 14

Three objects were created, one per new: a Scanner, a String, and a Ticket.

• An object is created by writing new followed by a call to one of the class’s constructors, which always have the same name as the class. The result is a reference to the new object.
• A reference variable must be declared with the object’s class as its type. It holds a reference to an object of that type, or null when there is no object.
• A constructor’s signature is its name plus the ordered list of parameter types; parameter names are not part of it. A class can have several overloaded constructors with different signatures, and Java picks the one whose parameter list matches the arguments.
• Constructor parameters receive values that set the new object’s starting values. The arguments must match the parameter list in number and order and be compatible in type.
• Arguments are passed call by value: parameters get copies, so changing a parameter never changes the caller’s variable. A constructor call jumps into the constructor, runs all its statements, then returns to just after the call.

import java.util.Scanner;

public class ReaderMistakes
{
    public static void main(String[] args)
    {
        String reader = Scanner("5 9");
        int first = reader.nextInt();
        System.out.println(first);
    }
}

Scanner reader = new Scanner("5 9");

public class Matinee
{
    public static void main(String[] args)
    {
        int seat = 20;
        System.out.println("Start");
        Ticket early = new Ticket("Up", seat, 7.0);
        System.out.println(seat);
        Ticket late = new Ticket("Dune", seat + 1, 7.0);
        System.out.println(seat);
    }
}

class Ticket
{
    Ticket(String movie, int seat, double price)
    {
        seat = seat * 2;
        System.out.print(movie);
        System.out.print(" ");
        System.out.println(seat);
    }
}

Start
Up 40
20
Dune 42
20

• I can create an object using new and a constructor, and say why the constructor has the class name. Reread
• I can declare a variable of the right type for an object, and explain what null means. Reread
• I can write the signature of a constructor from its header. Reread
• I can explain how constructor arguments set a new object’s starting values. Reread
• I can tell which overloaded constructor a call will use. Reread
• I can check whether a call’s arguments match in number, order, and type. Reread
• I can explain why changing a parameter does not change the caller’s variable. Reread
• I can trace the order of output when a constructor call jumps into the constructor and back. Reread