Instructor Guide: Session Schedule (12h Lectures + 12h Labs)

Assumes the audience already knows C and standard data structures (arrays, linked lists, stacks, trees). The goal is fluency in Java specifically — its object model, its standard library idioms, and where it departs from C — not a first course in programming or in data structures. Time is spent where Java is genuinely different from what students already know, and compressed where it isn’t.

The course budget is roughly 12h of lecture and 12h of labs. The material below (10 lecture files, ~16.5h read end-to-end, plus 5 labs, ~11h) runs slightly over that on paper — in practice, deliver it as 6 lecture sessions and 6 lab sessions by pairing up the shorter chapters as shown below, rather than as one-file-per-session.

Lectures (6 sessions, ~2h each)

Session 1 — Course overview + OOP model (2h)

• Course Overview (0.5h) — quick, sets expectations.
• Basic OOP Concepts (2h, compress to ~1.5h) — skip straight past the struct/function recap (they know it), spend the time on classes, instances, messages, this, and a first look at inheritance.
• Goal by end of session: can read and write a plain Java class with fields, a constructor, and methods.

Session 2 — Java fundamentals (2h)

• Java Fundamentals in full — compile/run pipeline, primitives vs. objects, constructors, arrays (incl. bounds checking vs. C), String, static, enum.
• Goal: can explain what javac/java do, and write a class with a main method from scratch.

Session 3 — References and object identity (2h)

• References, Aliasing, and Object Identity in full — this is the session where C intuitions most often mislead, so it gets a dedicated slot rather than being folded into session 2.
• Live-code the aliasing and pass-by-value-of-reference examples; do the == vs. .equals() demo; write equals/hashCode/toString for a class together as a class exercise.
• Goal: can explain why a == b and a.equals(b) can disagree, and never ships a data class without overriding these three methods.

Session 4 — Advanced OOP: abstraction and polymorphism (2h)

• Advanced Concepts in full — abstraction, the Template Method pattern, the two kinds of polymorphism (override vs. overload), static vs. dynamic type, casting and instanceof.
• Goal: can decide whether a shared method belongs as concrete, abstract, or left to each subclass, and can predict which overridden method actually runs for a given static/dynamic type pair.

Session 5 — Exceptions + Collections (2h, brisk pace)

• Exceptions (2h, compress to ~1h) — the checked/unchecked split, try/catch/finally, custom exceptions, repair-locally-vs-propagate. This has no C equivalent at all, so don’t cut the core mechanics — compress by moving the “Common Pitfalls” discussion to reading.
• Collections (2h, compress to ~1h) — interfaces as cross-cutting contracts, the Collection/List/Set/Map hierarchy, Iterator vs. for-each, Comparable/Comparator. Explicitly tie the Set/Map custom-key gotcha back to session 3: a HashSet/HashMap misbehaving is almost always a missing equals/hashCode override.
• Goal: can choose between local recovery and propagation for a given failure; given a problem, can pick the right collection type and justify it by complexity.

Session 6 — Packages, persistence, and GUI (2h, survey pace)

• Packages and Visibility (1h) — package/import mechanics plus the visibility-modifier table and worked examples.
• Serialization (1h, compress) — why it exists, Serializable, transient, and the two common pitfalls. Treat the stream-fundamentals worked example as optional reading if time is short.
• GUIs (2h, compress to ~1h) — the model/view separation, the Composite pattern for components, event-driven programming as an application of Observer/polymorphism, and — importantly, since Lab #5 needs it — how to read and extend someone else’s partial GUI rather than only building one from scratch. Skip deep layout-manager detail in lecture; it’s better learned by doing in the lab.
• Goal: recognize these as applications of ideas already taught (packages = encapsulation at a coarser grain; serialization = objects crossing a boundary; GUI events = polymorphism you didn’t write yourself), not as new theory.

Explicitly out of scope for the lecture (mention only in passing if a question comes up): concurrency/threads, build tools (Maven/Gradle), streams beyond the lambda-as-listener example in the GUI chapter, generic variance/wildcards, unit testing frameworks. These are legitimate next steps after this course, not prerequisites for a “good grasp of Java.”

Labs (5 sessions, running project)

The five labs form one continuous project — a circuit simulator built from logic gates (AND/OR/NOT) wired to switches and a valve — so each session’s code is the direct starting point for the next. Budget roughly 2h for each of the first four and 3h for the last.

Lab #1 — Getting Started with Java: the Rectangle class (2h) JDK toolchain, a first non-trivial class (fields, constructor, toString()), static helpers, Scanner input, arrays of objects. Independent of the running project — a warm-up.

Lab #2 — A Class Hierarchy for Logic Components (2h) Starts the running project: the Component/Switch/Valve/Gate/Not/TwoInputGate/And/Or hierarchy, getId(), and a first polymorphic description() method.

Lab #3 — Simulating Circuits: Exceptions and Interactive Probes (2h) Adds getState() with a custom checked NotConnectedException; walks through the same exception handled three different ways (propagate/catch-centrally/catch-locally) to make catch placement concrete; factors TwoInputGate via the Template Method pattern from session 4; adds interactive Probe/LazyProbe components.

Lab #4 — Circuits as Objects: Collections and Comparable (2h) Wraps the loose component array into a real Circuit class backed by a List<Component>, sorted via Comparable; adds a ProbeTable using two synchronized Maps to whole-circuit probing.

Lab #5 — Packages, Serialization, and a Swing GUI (3h) Splits the project into circuits/test packages with a deliberate break-then-fix visibility exercise; adds save/load via serialization; wires a provided partial Swing GUI (gui.Tester, from the downloadable ihm.jar) to the finished domain model — the capstone, giving the project a visible, interactive result by the end of the course.