Every language covered so far — C, C++, Rust — compiles source directly to native machine code, tied to one specific OS and CPU. Java does something structurally different, and this chapter is about that difference before anything else.

The JVM — A New Compilation Model

C, C++, and Rust all compile in one step: source → machine code, specific to the target platform. Java compiles to bytecode instead — an intermediate, platform-independent format — and the Java Virtual Machine (JVM) then interprets or compiles that bytecode to real machine code at runtime, on whatever platform it's actually running on. A genuinely different, two-stage model.

"Write Once, Run Anywhere"

The practical payoff: the exact same compiled .class bytecode file runs unmodified on Windows, Linux, or macOS, as long as each has its own JVM installed. Compare this against C/C++/Rust, where the source can be portable, but the compiled binary is not — recompiling separately for each target platform is required. Java shifts the portability boundary from source code to compiled bytecode.

javac and java

A two-command workflow: javac compiles .java source into .class bytecode; java then runs the JVM against that bytecode. Genuinely a two-step process, like c1-1's own compile-then-link model — but with a different split: not compile-then-link, but compile-then-run-on-a-VM.

JIT Compilation, Briefly

The JVM doesn't just interpret bytecode slowly forever. A Just-In-Time (JIT) compiler inside the JVM identifies "hot" code paths — the parts actually executed frequently — and compiles those specific parts to real machine code at runtime, for near-native performance where it matters most. A genuine, real engineering answer to "isn't interpreting bytecode slow?"

The Smallest Java Program

A real, immediate ceremony worth naming directly: unlike C/C++'s free-standing main() function (c1-1, cpp1-1), Java requires every piece of code, even the entry point, to live inside a class. There is no such thing as a free function in Java at all — a genuinely different, stricter OOP-first philosophy from the very first line.

Compiling & Running

A real, Java-specific compiler-enforced rule: the class name must match the filename exactly, for any public class.

Coding Challenges

java1-1 showed every value living inside a class. This chapter shows the one deliberate exception — and the real trap it creates.

Primitive Types

Java has exactly eight primitives — byte, short, int, long, float, double, char, boolean — each with an exact, guaranteed size across every platform, per the JVM specification itself. This is genuinely Rust-like, not C-like: c1-2's own material established that C only guarantees a minimum size for int. Java's primitives agree with Rust here, not with C.

Reference Types

Everything else — objects, arrays, String — is a reference type, stored as a reference to heap-allocated data, not the raw value itself. Conceptually similar to C's own pointer/value distinction (c1-7), but Java references cannot be manipulated with pointer arithmetic at all — no c1-7-style arithmetic; dereferencing is always implicit.

Primitives vs. Objects — Why Both Exist

A real, practical reason: primitives are stored directly — on the stack, or inline within an object — avoiding the overhead a full object/reference would carry for something as simple as an int. A deliberate performance-vs-uniformity tradeoff; making everything a full object, as some "purer" OOP languages do, has real, measurable overhead.

Boxing & Unboxing

Integer is the object wrapper class for the primitive int. Autoboxing (a primitive silently becoming a wrapper object) and auto-unboxing (the reverse) happen automatically in many contexts since Java 5.

A Real Boxing Gotcha — Integer Caching

A genuinely surprising, real, documented JVM behavior: Java caches small boxed Integer values, -128 to 127. Trips up even experienced Java programmers, since small test values often happen to fall inside the cached range and hide the bug.

== vs. .equals()

The general rule this gotcha is an instance of: == compares references for objects (are these the same object in memory) but compares values for primitives (since there's no reference to compare at all). .equals() is the method for genuine value comparison between objects.

Coding Challenges

java1-2 covered the eight primitives and the reference/value split. This chapter puts them to work — most of it will feel immediately familiar coming from C, C++, or Rust, with two genuine exceptions worth slowing down for.

Standard Operators

Arithmetic (+ - * / %), relational (== != < > <= >=), logical (&& || !), and compound assignment (+= -= *= /=) all behave exactly as they do in C/C++. Nothing new to learn here — genuinely shared syntax across all four languages this site has covered.

Integer Division & the Common C-Style Trap

Division between two int values truncates toward zero, exactly the same trap c1-3 covered for C. Java doesn't fix this — it's the same behavior, inherited from the same C-family lineage, and it requires the same explicit cast to force floating-point division.

Traditional switch — Fallthrough, the Same Footgun

Java's traditional switch falls through by default, identical to C's own switch statement covered in c1-3 — omitting break is a genuine, real bug class in both languages, not just a Java quirk.

Switch Expressions — Java's Real Fix

Java 14 introduced switch expressions: the arrow form (->) has no fallthrough at all — each branch is isolated — and the whole expression can produce a value directly, assigned straight into result. Multi-statement branches use a block with yield to supply the value.

Pattern Matching — A Light Touch

Since Java 16, instanceof can bind the checked-and-cast value directly to a new variable in one step, removing the old two-step check-then-cast pattern. Java 21 extends this into switch itself, matching directly on an object's type. This course won't go deep on pattern matching — it's flagged here mainly so the syntax isn't a surprise when it appears in later chapters.

Coding Challenges

Every program since java1-1 has lived inside a class out of necessity. This chapter explains why — fields, constructors, methods, and the access-control model that governs who can touch what.

Fields & Constructors

A constructor shares the class's exact name, has no return type, and runs once when new Account(...) is called. this refers to the current instance — needed here specifically because the parameter names shadow the field names.

Java's Four Access Levels

Where C++ has three access levels (public, protected, private), Java has a genuine fourth: package-private, the default when no modifier is written at all. A member with no modifier is visible to any class in the same package, but nowhere else — a level of granularity C++ has no direct equivalent for.

Why a Fourth Level Exists

C++ has no built-in concept of a "package" the way Java does, so it has nothing to attach a package-scoped access level to in the first place. Java's package system gives classes in the same package a middle ground: more open than private, but without exposing a member to every caller everywhere the way public does. It's a genuinely different granularity, not just a naming difference.

Instance Methods vs. Static Methods

main, back in java1-1, was already static — this is why: a static method belongs to the class itself, not to any particular instance, which is exactly why the JVM can call main without ever constructing an object first.

Coding Challenges

java1-4 built one class in isolation. Real programs build hierarchies — this chapter covers how, and where Java deliberately draws a harder line than C++ ever did.

extends & Single Inheritance

A Java class can extends exactly one other class. This is a hard rule, not a convention — where C++ allows a class to inherit from several base classes at once (the exact mechanism behind cpp3-1's diamond problem), Java simply never lets that ambiguity arise in the first place.

super — Reaching Into the Parent

super(...) calls the superclass's constructor and must be the first statement in a subclass constructor if written explicitly. super.methodName() calls the superclass's version of an overridden method from inside the override itself.

Method Overriding — Virtual by Default

A genuine, real difference from C++: every Java instance method is virtual by default — dynamically dispatched based on the object's actual runtime type — unless explicitly marked final, private, or static. cpp1-7's own material required the explicit virtual keyword in C++ for this exact behavior; Java simply never offers a non-virtual instance method as the default at all.

Why Single Inheritance of Classes

Java's restriction to one extends per class is a structural choice, not a limitation nobody thought to lift — it's the same underlying goal cpp3-1's own virtual-inheritance fix pursued for C++, achieved here by never allowing a class to inherit state from more than one place to begin with. Behavior from multiple sources is still possible in Java — through interfaces, covered next chapter — but state never comes from more than one superclass.

Coding Challenges

java1-5 closed with a promise: state can only ever come from one superclass, but behavior can still come from multiple sources — through interfaces. This chapter delivers on that.

Interfaces — The Contract

An interface declares method signatures with no body and no instance fields — a pure contract. A class implements it and must supply real bodies for every abstract method it declares.

A Class Can implements Many Interfaces

This is exactly where "multiple sources of behavior" comes back from java1-5. extends is capped at one superclass; implements has no such cap at all — a single class can satisfy as many interface contracts as it genuinely needs to.

Default Methods (Java 8+)

Since Java 8, an interface method can carry a default body — implementing classes inherit it automatically and may override it if they need different behavior. This is a genuine convergence point with Rust: rust2-2's own trait default methods work the same way, behavior supplied by the contract itself without requiring every implementer to repeat it.

Abstract Classes

Unlike an interface, an abstract class can hold real fields, constructors, and fully concrete methods alongside abstract ones. It still follows java1-5's own single-inheritance rule — a class extends at most one abstract class, exactly the same as any other class.

Interface vs. Abstract Class — When to Use Which

An interface answers "can this do X?" with no shared state at all. An abstract class answers "is this genuinely a kind of Y?" and gets to share real implementation and state across every subclass. A class can implement many interfaces but extend only one abstract class — the choice usually follows from that asymmetry directly.

The Diamond Problem, Returning For Behavior Alone

Two interfaces can both supply conflicting default implementations of the same method — a real, narrow reappearance of cpp3-1's diamond problem, scoped to behavior only, since interfaces never carry state. Java doesn't guess which one wins: the implementing class is required to override the method itself and resolve the conflict explicitly, or the code simply fails to compile.

Coding Challenges

Every prior chapter assumed things go right. This one covers what Java does when they don't — and a genuinely distinct position between two approaches already covered on this site.

try/catch/finally — The Basics

Code that might fail goes in try; a specific exception type is handled in catch; finally runs unconditionally, whether an exception was thrown or not.

The Exception Hierarchy

Every exception is a Throwable. Below that: Error (serious JVM-level problems, not meant to be caught) and Exception, which splits again into RuntimeException and everything else — that split is exactly where checked and unchecked diverge.

Checked Exceptions — Compiler-Enforced Acknowledgment

A checked exception — anything that's an Exception but not a RuntimeException, like IOException — must be either caught or declared with throws in the method signature. The compiler enforces this and refuses to compile otherwise. This is genuinely new territory versus C++: cpp2-6's own C++ exceptions carry no compiler-enforced acknowledgment requirement at all — a function that throws can be called with zero handling and zero declaration, compiling cleanly, only to crash at runtime if the exception is never caught anywhere up the call stack.

Unchecked Exceptions

RuntimeException and its subclasses — NullPointerException, ArrayIndexOutOfBoundsException, ArithmeticException — carry no such requirement. They can be thrown and left completely unhandled, compiling fine, just like every exception in cpp2-6's C++ model. Unchecked exceptions are typically reserved for programming errors — bugs — rather than expected, recoverable failure conditions.

The Real Middle Ground vs. Rust's Result<T, E>

Rust encodes failure directly in a function's return type — the signature itself says "this can fail," and the caller must handle the Result via match, ?, or an explicit unwrap() or the code won't compile clean. Java's checked exceptions force a genuinely comparable acknowledgment, but through a side-channel — the throws clause — rather than the return type itself. It's a real middle position: more compiler enforcement than C++ ever offers, but less structurally integrated into the type system than Rust's approach.

try-with-resources

Any resource implementing AutoCloseable can be declared in the try(...) parentheses — its close() is called automatically once the block exits, exception or not. It's Java's own answer to the resource-cleanup problem cpp1-5's RAII solves via destructors and Rust's Drop solves automatically — genuinely less automatic than either, since it still requires the explicit try(...) syntax rather than firing on scope exit alone.

Coding Challenges

Fundamentals closes with the tool used constantly in real Java code: growable, generic collections — starting with List, the interface Course 2's own Collections Framework II picks up from with Map/Set/Queue.

ArrayList — A Growable Array

A plain Java array's size is fixed the moment it's created. ArrayList is backed internally by an array too, but resizes itself automatically as elements are added — the size a caller actually deals with is never fixed at all.

Generics in Collections

List<String> tells the compiler exactly what type this list holds, catching a type mismatch at compile time rather than at some later runtime cast. Before generics existed, Java collections held plain Object references, requiring an explicit, unchecked cast on every read — a real source of runtime ClassCastExceptions generics eliminate outright. Course 2's own Generics In Depth chapter goes further into how generics work themselves; this chapter only needs the collection-facing side.

Programming to the Interface

The variable is declared as List<String>, not ArrayList<String>, even though an ArrayList is what's actually constructed. This mirrors java1-6's own interface-vs-implementation split directly: code written against the List interface keeps working unchanged if the concrete implementation is later swapped for a LinkedList or any other List.

Iterating — for-each, Iterator, and Safe Removal

The for-each form is the everyday choice for read-only iteration. Removing an element while iterating requires the explicit Iterator and its own remove() — removing directly from the list during a for-each is not safe, covered next.

Java's Own Answer to the STL Containers

ArrayList is directly comparable to cpp2-2's own std::vector — both are growable, contiguous, general-purpose sequence containers. The real difference traces straight back to java1-2's boxing material: a C++ std::vector<int> stores raw int values directly, no wrapping required, since C++ templates generate real code specialized for the exact type. Java generics can't hold a primitive int at all — List<int> doesn't compile — so List<Integer> is required instead, and every element is autoboxed on the way in.

Coding Challenges