How this course works

Almost every idea here is written two ways, and you choose which one you read. Textbook is the exact version, using the words Java programmers and Java's own documentation use. Plain English is written for a newcomer, in everyday words. It explains each new word the moment it shows up. Both versions say the same things; Plain English is not a cut-down copy. A switch above each explanation flips between them, and the course remembers your pick.

Some steps depend on your computer, like how to open a terminal (the typing window from the last page). Those steps come as tabs, one tab per kind of computer or app.

You tell the course about your computer once, in the My setup panel on the course page. It asks which operating system you use: Windows, macOS, or Linux. It also asks which app you'll write Java in. The choices are IntelliJ IDEA, Eclipse, VS Code, NetBeans, or just a terminal and a text editor. Chapters 1 and 2 help you pick. After that, every tabbed block opens on your choice. Click a different tab anywhere, and the course switches everywhere.

Most ideas are explained twice, side by side. The Textbook lane is precise: it uses the standard terms and states rules in full, the way Java's documentation or a job interview would. The Plain English lane covers the same ground for someone meeting it for the first time, in everyday words, explaining each new term where it appears. The two lanes make the same claims; neither is a summary of the other. A switch above each explanation flips between them, and your choice is kept as you move through the course.

Some instructions depend on your computer. Those appear as tabs, one per option, and they are grouped. You set each group once under My setup on the course page (or in Settings). One group is your operating system: Windows, macOS, or Linux. Another is your environment, the app you write and run Java in: IntelliJ IDEA, Eclipse, VS Code, NetBeans, or the plain command line. Two further groups matter only in later chapters, and each of those chapters says when to set them. Picking a tab in any lesson updates your setting everywhere. A tabbed block that doesn't offer your choice opens on its first tab and leaves your setting alone.

A new version of Java comes out twice a year, in March and September. This course uses Java 25, from September 2025. Not every feature exists in every version, though. So a feature that depends on the version, or that comes from outside Java, gets a short bold label where it's taught:

• Stable means finished, permanent, and part of Java for a long time. Any Java code you meet might use it.
• Recent means finished and in your Java 25, but new: it arrived in version 21 or later. Older code won't use it, and an older Java install won't accept it.
• Newer release means it only exists in versions after 25. Your Java 25 doesn't have it. You're told about it so you recognize it.
• Preview means it's in Java 25 but not finished. You have to switch it on with a special option, --enable-preview. It may still change or be removed.
• Library means the code doesn't come with Java at all. It's ready-made code, written by someone else, that you add to your own work.
• Framework-specific means it only works inside one big toolkit that organizes a whole app, such as one called Spring.

Java is about thirty years old, so you'll read much more old code than you write. When the course teaches a modern way of doing something, it often adds an example titled Legacy / existing code. That example shows the older way, so it won't confuse you when you see it. In your own code, use the modern way.

Java gets a new version every six months, each March and September. This course targets Java 25, released in September 2025, and labels any feature whose availability depends on a version or on something outside Java itself. A label sits in bold beside the feature where it is taught:

• Stable: final (finished and permanent) in Java 25 or earlier, and long established, so any Java code you meet may use it.
• Recent: also final in Java 25, but only since a version between 21 and 25. Code written for older versions won't use it, and an older installation won't accept it.
• Newer release: final only in a version after 25. Your Java 25 does not have it; it is named so you recognize it.
• Preview: present in Java 25 but unfinished. It works only when switched on with the option --enable-preview, it may change or disappear, and this course never teaches it as settled.
• Library: not part of Java at all, but ready-made code from other people that you add to your own (JUnit for tests and Jackson for JSON, for example).
• Framework-specific: works only inside one framework, a large body of ready-made code that shapes a whole application and calls your code, such as Spring.

Java has been in use for three decades, so you will read far more existing code than you write. Where a modern form replaces an older one, the lesson teaches the modern form and adds a worked example titled Legacy / existing code, showing the older form you will meet so you can read it. Write the modern form in your own code.

You'll meet two kinds of question set. A check sits in the middle of a lesson. It shows a few questions picked at random from a bigger pool, so a later visit gives you different ones. Checks are marked. The course also uses them to decide which topics to bring back later for review.

A practice set sits at the end of a topic. It's a short ladder of 4 to 6 problems that always come in the same order. The first asks about the idea itself. Then comes an easy one, a normal one, and one with a twist. The last one hides a trap. Practice isn't marked, because its job is to let you do the thing, not just read about it. Each chapter also ends with a wrap-up page with review problems from every section.

Some questions are about code. You might type what a program prints, drag lines into the right order, or fill in a missing word. A bug hunt gives you a short program with mistakes planted in it; a mistake in a program is called a bug. The task always says how many there are. Sometimes you just click the broken lines. Sometimes you edit the code and press Check. Then it tells you which mistakes you fixed, and whether the code is still correct Java.

A check, the question block inside a lesson, draws a few questions at random from a larger bank, so a later visit shows a different mix. Checks are graded, and the results feed your progress and the review schedule that decides what to show you again. A practice set is a fixed list of 4 to 6 problems in the same order every visit. It opens with a question about the idea, climbs through a basic case, a typical one, and a variation, and ends on the one with a catch. Practice is ungraded. Each chapter ends with a wrap-up page whose review practice covers every section.

Code questions come in four forms. Predict the output asks you to type exactly what a program prints; the others are put the lines in order, fill in the blank, and the bug hunt, a short program with planted mistakes whose task always states how many. A bug hunt has two modes. In spot mode you click the broken line or lines. In fix mode you edit the code in place and press Check, and the checker reports whether each planted mistake is gone and whether the code is still written as valid Java.

When you type code into a question on this site, the site never runs it. Your code goes to our server, and a Java parser reads it. A parser is a program that reads code the way a grammar checker reads a sentence. It can tell whether the code is written correctly, and whether you included the piece the question asked for. It cannot tell what your code would do if it ran. A grammar checker can't tell whether a sentence is true, either. The parser also can't tell whether a name you typed really exists.

So where do the outputs on the pages come from? Before the course went live, our build ran every example program with the real Java tools. That tool kit is called the JDK, short for Java Development Kit; it's free, and you'll install it in Chapter 1. The build then checked that each output on the page matched what really printed. If it didn't match, the page wasn't published. No person typed those outputs in.

Running your own code happens on your own computer. From Chapter 1, each lab gives you a small .java file, and you run it with one command, java Hello.java. From Chapter 6, labs come with tests: small extra programs, already written, that check whether yours works. One command runs them all. Watching a program run one line at a time, which you'll try in Chapter 2, happens on your computer too.

Code you type on a lesson page is never compiled or run. The course's server checks it with a Java parser: a program that reads source code and works out its structure (which parts are instructions, where each one begins and ends, which names it mentions) without translating or running it. The parser decides whether your code is written as valid Java and whether it has what the task asked for, such as a particular line. That makes checking fast and safe, and it also sets the limits. A parser knows the shape of your code, not what the code would do. It cannot tell that a name you used doesn't exist, and it cannot tell what the program would print.

So anything a page shows a program doing was produced ahead of time: the output under an example, the answer to a predict-the-output question, an error message quoted in a lesson. When the course is built, every one of those programs is compiled and run on a real JDK 25. A JDK (Java Development Kit) is the free set of Java tools you install in Chapter 1. The build fails if a page doesn't match what really happened.

Running is your machine's job. From Chapter 1, labs hand you a small .java file to run with java Hello.java. From Chapter 6, labs arrive as starter folders with tests already written (small programs that check your work), and one command runs them all. Pausing a running program to watch it one line at a time, met in Chapter 2, also happens on your machine.