Write Your Own Java Class, One Compiler Error at a Time

A draft that looks finished#

Somebody set out to model a car. They named the class, listed four attributes, commented every one, wrote a method that changes an attribute and a method that returns it, and reached for a Scanner at the end. This is a normal, honest first attempt:

public class MyCar {
    private int year;          //Year of vehicle
    private string make;       //Make of Vehicle
    private string model:      //Model of Vehicle
    private string color;      //Color of vehicle

    public void setYear(int year){
        year = 2026;
    }

    public int getYear(){
        return year;
    }

    Scanner Keyboard = new scanner(System.in);

How many things are wrong with it? Count them before you scroll. Most people find two or three. There are six, and the most expensive one compiles perfectly.

MyCar.java:4: error: ';' expected
    private string model:      //Model of Vehicle
                        ^
MyCar.java:16: error: reached end of file while parsing
    Scanner Keyboard = new scanner(System.in);
                                              ^
2 errors

Two errors, and neither one mentions string. That is the first thing worth understanding about javac: it cannot look for missing types until it has finished reading the shape of the file. A stray : and a missing } stop it at the parsing stage, so everything after that is still unexamined. Fix errors from the top down, and recompile after each one — the list you get next is a different list, not a shorter one.

Fix the syntax, and the next layer appears#

Change the : to a ;, close the class with a }, and compile again. Same file, otherwise untouched:

MyCar.java:3: error: cannot find symbol
    private string make;       //Make of Vehicle
            ^
  symbol:   class string
  location: class MyCar
MyCar.java:4: error: cannot find symbol
    private string model;      //Model of Vehicle
            ^
  symbol:   class string
  location: class MyCar
MyCar.java:5: error: cannot find symbol
    private string color;      //Color of vehicle
            ^
  symbol:   class string
  location: class MyCar
MyCar.java:15: error: cannot find symbol
    Scanner Keyboard = new scanner(System.in);
    ^
  symbol:   class Scanner
  location: class MyCar
MyCar.java:15: error: cannot find symbol
    Scanner Keyboard = new scanner(System.in);
                           ^
  symbol:   class scanner
  location: class MyCar
5 errors

Five errors from two mistakes, both of them about capital letters.

String is a class, and Java is case sensitive all the way down. string is not a misspelling that the compiler forgives — it is a name for a class that does not exist, which is exactly what cannot find symbol: class string says. The same goes for new scanner(...). Convention is not decoration here: class names begin with a capital letter, variables and methods begin with a lowercase one, and the compiler enforces the first half of that rule whether you meant it or not.

Scanner on line 15 fails for a different reason. It is spelled correctly, and the compiler still cannot find it, because Scanner lives in java.util and nothing has said so. That needs a line above the class:

import java.util.Scanner;

String never needs an import because it lives in java.lang, which is imported into every file automatically. That is the whole difference between the two.

The Scanner should not be here at all#

Adding the import would make line 15 compile. It would still be the wrong line to write, and this is a design point worth more marks than the spelling ones.

MyCar models a car. A car has a year, a make, a model and a colour. A car does not have a keyboard. A Scanner field describes how one particular program happens to collect information — and the moment it is inside the class, MyCar can only be used by programs that have a console attached. Not a test, not a GUI, not a file reader.

Input belongs in the class that runs the program, next to main:

import java.util.Scanner;

public class Garage {
    public static void main(String[] args) {
        Scanner keyboard = new Scanner(System.in);
        System.out.print("Year: ");
        int year = keyboard.nextInt();
        // ...and then hand the values to the class
    }
}

The useful test, whenever you are deciding whether something belongs in a class: is this a fact about the object, or a fact about this program? Year, make, model and colour are facts about the car. The keyboard is a fact about the program.

Now it compiles, and it is still wrong#

Capitalise the types, drop the Scanner, and the class finally compiles. Here it is, clean:

public class MyCar {
    private int year;
    private String make;
    private String model;
    private String color;

    public void setYear(int year){
        year = 2026;
    }

    public int getYear(){
        return year;
    }
}

No errors. Not even a warning with javac -Xlint:all. So test it — make a car, set its year, read the year back:

public class Demo {
    public static void main(String[] args) {
        MyCar mine = new MyCar();
        mine.setYear(2020);
        System.out.println(mine.getYear());
    }
}

What prints?

0

Not 2020, and not 2026 either. Zero.

Two separate things went wrong in three lines of method body, and neither one is a typo.

1. The parameter hides the field

Inside setYear(int year) there are two things called year: the field belonging to the object, and the parameter belonging to the method. When a name is ambiguous, Java always resolves it to the closest one — the parameter. So the line

year = 2026;

assigns 2026 to the parameter, which stops existing the instant the method returns. The field is never touched, so it keeps the value it was born with: 0, the default for an int.

This is called shadowing, and it is the single most common bug in a first set of setters. The fix is the keyword this, which means the object this method was called on:

public void setYear(int year) {
    this.year = year;   // this.year is the field, year is the parameter
}

Read it left to right and it says what it does: put the parameter into the field. Nothing else in the method needs this., because nothing else is ambiguous — getYear can return a bare year and be perfectly clear, since there is no parameter competing with it.

2. A setter that ignores its own parameter

Even with this. in place, this.year = 2026; would be wrong. A mutator's job is to store the value it was handed, not a value chosen when the code was written. Hard-coding 2026 makes setYear a method that can only ever mean one year, and the parameter becomes decoration.

The shape almost never varies:

public void setThing(Type thing) { this.thing = thing; }
public Type getThing()            { return thing; }

Accessors, mutators, and what private buys you#

The two method names have formal words attached, and exams use them:

They only mean anything because the fields are private. Try to reach a private field from outside its class and the compiler stops you:

MyCar mine = new MyCar(2020, "Honda", "Civic", "blue");
mine.year = 1999;

P2.java:4: error: year has private access in MyCar
        mine.year = 1999;
         ^
1 error

That error is the feature. Because the only route to year runs through setYear, the class gets to have an opinion about what a year is allowed to be, and that opinion lives in exactly one place:

public void setYear(int year) {
    if (year >= 1886 && year <= 2100) {
        this.year = year;
    }
}

Make the field public and that check is unenforceable, because any line of code anywhere can walk straight past it. This is what encapsulation means in practice — not secrecy, but keeping the rules about an attribute in the same place as the attribute.

Java has four levels of access, and for a class like this one you only need the two ends:

The default choice for a class you are writing today: every field private, every method that the outside world is meant to call public. Deviate only when you can say why.

The constructor#

So far every MyCar is born empty and has to be filled in one setter at a time — four calls before the object is usable, and nothing stops you forgetting one. A constructor is the method that runs once, at creation, to put the object into a valid state immediately.

It has two distinguishing features and no others: its name is exactly the class name, and it declares no return type — not even void.

public MyCar(int year, String make, String model, String color) {
    this.year  = year;
    this.make  = make;
    this.model = model;
    this.color = color;
}

Same this. rule as the setter, four times over, and for the same reason. Now one line does what four did:

MyCar mine = new MyCar(2020, "Honda", "Civic", "blue");

There is a catch that surprises people, and it is worth meeting on purpose rather than at 2am. Until you wrote that constructor, new MyCar() worked — a class with no constructor gets a free no-argument one that leaves every field at its default. The moment you write any constructor, the free one disappears:

P3.java:3: error: constructor MyCar in class MyCar cannot be applied to given types;
        MyCar p = new MyCar();
                  ^
  required: int,String,String,String
  found:    no arguments
  reason: actual and formal argument lists differ in length

If you want both ways of making a car, write both — two constructors with different parameter lists is overloading, and it is normal:

public MyCar() {
    this(2026, "unknown", "unknown", "unpainted");
}

this(...) on the first line of a constructor calls another constructor of the same class, so the real work stays written once.

Those defaults matter, because they are what an uninitialised field holds: 0 for int, 0.0 for double, false for boolean, and null for every object reference — String included. A String field you forgot to set is not ""; it is null, and it will print as the word null.

toString: the method that describes everything#

Requirement five — a method that returns a String describing all of the attributes — already has a name in Java, and using that name is what makes it work everywhere. Print an object without it and you get this:

MyCar@2a139a55

That is not an error, and not a bug. Every class in Java inherits a toString from Object, and the inherited one prints the class name, an @, and the object's hash code in hexadecimal. It is a machine's answer. The number changes between runs, and it is not an address you can use for anything.

Give the class its own and the machine's answer is replaced by yours:

@Override
public String toString() {
    return year + " " + make + " " + model + " (" + color + ")";
}

The signature has to match exactly — public, returns String, named toString, no parameters. Name it describe() instead and it is a perfectly good method that Java will never call on your behalf.

And it does call it on your behalf, in two places you use constantly: System.out.println(mine), and any string concatenation such as "Repainted: " + mine. You never write mine.toString() in normal code.

The finished class#

Every fix, assembled. This compiles clean under javac -Xlint:all on OpenJDK 21:

public class MyCar {

    // Attributes — private, so only MyCar can change them directly.
    private int year;
    private String make;
    private String model;
    private String color;

    // Constructor — runs once, when the object is created.
    public MyCar(int year, String make, String model, String color) {
        this.year  = year;
        this.make  = make;
        this.model = model;
        this.color = color;
    }

    // Mutators — change an attribute.
    public void setYear(int year)      { this.year  = year;  }
    public void setColor(String color) { this.color = color; }

    // Accessors — report an attribute.
    public int    getYear()  { return year;  }
    public String getMake()  { return make;  }
    public String getModel() { return model; }
    public String getColor() { return color; }

    // Describes every attribute as one String.
    @Override
    public String toString() {
        return year + " " + make + " " + model + " (" + color + ")";
    }
}

And the class that uses it. main lives here, not in MyCar — one class models the thing, the other runs the program:

public class Garage {
    public static void main(String[] args) {
        MyCar mine = new MyCar(2020, "Honda",  "Civic",   "blue");
        MyCar hers = new MyCar(2017, "Toyota", "Corolla", "silver");

        System.out.println(mine);
        System.out.println(hers);

        mine.setColor("red");
        mine.setYear(2021);

        System.out.println("Repainted: " + mine);
        System.out.println("Year is now " + mine.getYear());
    }
}

2020 Honda Civic (blue)
2017 Toyota Corolla (silver)
Repainted: 2021 Honda Civic (red)
Year is now 2021

Look at the third and fourth lines against the second. Changing mine did nothing at all to hers, because new was called twice and each call built a separate object with its own copy of all four fields. The class is one description; the objects are independent things made from it. That is the whole idea, and printing two of them side by side is the cheapest way to see it.

The six requirements, checked off#

The assignment on the board is nearly always worded the same way. Against the finished code:

Where these go wrong#

• A setter without this.. Compiles, runs, warns about nothing, and does nothing. Symptom: a getter that always returns 0 or null.
• A setter that hard-codes a value instead of storing its parameter. The parameter list is the giveaway — if the body never mentions the parameter, the method is ignoring its own input.
• Lowercase string or scanner. cannot find symbol naming a class you did not think you wrote is nearly always a capitalisation problem.
• A colon instead of a semicolon, or any missing brace. These stop the parser, which is why the error list afterwards looks unrelated to the mistake and gets longer once you fix them.
• A Scanner field inside the model class. Compiles once imported, and welds the class to a console it should know nothing about.
• Writing a constructor and then calling new MyCar(). The free no-argument constructor is gone the moment you write one of your own.
• Naming the describe-everything method anything but toString. It works when you call it and never runs when println would have called it for you.
• Two classes, one file, both public. Only one public class per file, and the file must be named after it — MyCar.java and Garage.java, not both in one.

Frequently asked questions#

Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written — several of these exist because somebody asked.