RobotnixAcademy
← Courses

Computing

Java Programming: From Code to Software Design

A self-paced Java 25 course that begins with small runnable programs and grows into disciplined software design. Learners trace how source code becomes JVM execution, reason about types and control flow, design methods and data structures, model systems with objects and interfaces, handle failure, test behavior, refactor safely, and defend a complete software capstone. The browser-first core uses the official Java Playground; an optional JDK lane adds multi-file projects, file I/O, and JUnit 6 without making a local development machine a prerequisite for conceptual mastery.

Structure
18 units
Audience
Grades 9-12
Entries
96
Pacing
Self-paced

Unit 01

  1. overviewUnit 1: How Java Actually RunsJava is not a magic box where text goes in and answers come out. A Java program moves through a chain: source code -> compiler -> bytecode -> JVM -> observable behavior.
  2. Lesson 1Source Code Is Not the Program the JVM ExecutesWhen you write Java, you create source code. The Java Virtual Machine does not directly execute that source text.
  3. Lesson 2Your First Java 25 Program Without the CeremonyFor years, many Java beginners met the language through a line like this:
  4. Lesson 3Predict Before You Press RunThe Run button is useful. It is also capable of training a terrible habit: edit randomly, run again, stare at output, repeat until something looks right.
  5. reflectionUnit 1 ReflectionChoose one idea that changed how you read a Java program.

Unit 02

  1. overviewUnit 2: Variables, Types, and Numeric BehaviorJava makes you state what kind of value a variable can hold. That constraint is not pointless ceremony. It lets the compiler reject impossible relationships early and gives numeric operations precise behavior.
  2. Lesson 1A Variable Has a Type, Not Just a NameA variable is a named storage location in the program's model. In Java, its declared type limits the values and operations that make sense for that variable.
  3. Lesson 2Integer Division Will Betray a Bad Mental ModelPredict this before running it:
  4. Lesson 3Overflow and Precision Are Program BehaviorTypes do more than decide what syntax compiles. Numeric representations have limits, and those limits can become visible program behavior.
  5. reflectionUnit 2 ReflectionChoose one numeric result that would have surprised you before this unit: integer division, narrowing conversion, overflow, or floating-point precision.

Unit 03

  1. overviewUnit 3: Input, Strings, State, and ErrorsPrograms become interesting when values are not all hard-coded. Input creates a new problem: the program receives data, but receiving characters does not prove those characters represent a valid age, score, command, or…
  2. Lesson 1Input Arrives as Data You Still Have to InterpretA user typing 42 sees a number. A line-oriented input system first gives your program text.
  3. Lesson 2Strings Are Objects, and Text Has StructureText processing is more than printing a sentence. Usernames, commands, file records, labels, messages, and identifiers all have structure.
  4. Lesson 3Compiler Error, Exception, or Wrong Answer?Debugging gets faster when you classify the failure before trying to fix it.
  5. checkpointCheckpoint 1: Program State and Failure TraceThis checkpoint is not a syntax quiz. Submit a small Java program whose behavior you can trace and defend.
  6. reflectionUnit 3 ReflectionWhich failure category is easiest for a beginner to overlook: compile-time, runtime, or logic?

Unit 04

  1. overviewUnit 4: Boolean Decisions and BranchingSoftware decisions begin as requirements written in ordinary language and end as expressions that evaluate to true or false.
  2. Lesson 1A Condition Is a Claim That Must Become True or FalseSuppose a requirement says:
  3. Lesson 2Branch Order Changes Which Rule WinsConditions often overlap. In an if / else if / else chain, the first matching branch wins.
  4. Lesson 3Short Circuiting Can Protect a BoundaryJava's && and || do not always evaluate both sides.
  5. reflectionUnit 4 ReflectionFind one decision in your Unit 4 work where two Java implementations could both compile but represent the requirement differently.

Unit 05

  1. overviewUnit 5: Loops, Termination, and Iteration InvariantsA loop is not "code that repeats." A useful loop has:
  2. Lesson 1Every Loop Needs a Reason to StopConsider:
  3. Lesson 2Choose for, while, or Enhanced for by the JobJava gives you more than one looping structure because iteration problems have different shapes.
  4. Lesson 3Off-by-One Errors Live at the BoundaryA loop can be almost correct and still process one too many or one too few values.
  5. reflectionUnit 5 ReflectionDescribe one loop from this unit without using the phrase "it repeats."

Unit 06

  1. overviewUnit 6: Methods, Parameters, Return Values, and ScopeMethods are where a growing program begins to develop structure.
  2. Lesson 1A Method Is a Contract, Not a Code DrawerIt is easy to describe methods as a way to "avoid repeating code." Reuse matters, but it is not the most important idea.
  3. Lesson 2Parameters Cross a Boundary; Local Variables Stay LocalA method receives information through parameters.
  4. Lesson 3Decompose by Responsibility and Test the PiecesA longer program should not become a long main method merely because it still runs.
  5. checkpointCheckpoint 2: Control Flow and Method DesignBuild a small Java program that makes at least one decision, iterates over or toward a bounded state, and decomposes the work into meaningful methods.
  6. reflectionUnit 6 ReflectionPick one method you wrote this unit. Explain its contract in plain language without showing the body first.

Unit 07

  1. overviewUnit 7: Arrays and Indexed DataRepeated variables stop scaling quickly.
  2. Lesson 1An Array Gives Many Values One Indexed StructureSuppose a program stores five sensor samples.
  3. Lesson 2Index Boundaries Are Part of the Data ModelFor an array of length 5, valid indexes are:
  4. Lesson 3Aggregate Data Without Losing the EvidenceArrays become useful when one algorithm can operate across the whole dataset.
  5. reflectionUnit 7 ReflectionDescribe one problem where an array is a better model than repeated variables and one problem where a fixed-size array would be awkward.

Unit 08

  1. overviewUnit 8: Collections and Generic ContainersArrays are not the only way Java groups data.
  2. Lesson 1Use a List When Order and Growth MatterAn array's length is fixed after creation. A List can represent an ordered sequence whose size changes.
  3. Lesson 2Set and Map Encode Different QuestionsA collection choice should make an important rule easier to express.
  4. Lesson 3Choose the Structure From the OperationsA common beginner question is:
  5. reflectionUnit 8 ReflectionName one collection choice you changed after considering the required operations.

Unit 09

  1. overviewUnit 9: Classes, Objects, Records, and InvariantsObject-oriented programming becomes useful when a program contains concepts with related state, behavior, and rules.
  2. Lesson 1An Object Should Represent a Coherent ConceptSuppose a program tracks a competition team using separate variables:
  3. Lesson 2Records Make Value-Shaped Data ExplicitSome domain concepts are primarily immutable bundles of named values.
  4. Lesson 3Constructors and Encapsulation Defend InvariantsA class with public fields allows outside code to create impossible states whenever it wants.
  5. checkpointCheckpoint 3: Data and Object ModelDesign a small Java model that stores multiple domain values and makes invalid state difficult to create.
  6. reflectionUnit 9 ReflectionChoose one concept you modeled this unit and answer two questions:

Unit 10

  1. overviewUnit 10: Interfaces and Behavioral ContractsObject-oriented design becomes more flexible when one component can depend on a capability rather than the exact class providing it.
  2. Lesson 1An Interface Describes What a Collaborator Can DoImagine a program that needs to send a status message. The program should not need to know whether the destination is a console, memory buffer, classroom display, or another approved output mechanism.
  3. Lesson 2Program to the Contract, Not the Concrete ClassSuppose a report generator is written like this:
  4. Lesson 3A Contract Is Only Useful When Implementations Keep ItAn interface compiles when method signatures match. Software design still depends on shared behavioral expectations.
  5. reflectionUnit 10 ReflectionDescribe one interface you built as a capability sentence: "Anything used here must be able to..."

Unit 11

  1. overviewUnit 11: Composition and Collaborating ObjectsLarge behavior does not require one giant class or one giant inheritance hierarchy.
  2. Lesson 1Has-a Is Often More Useful Than Is-aSuppose a notification service needs two capabilities:
  3. Lesson 2Constructor Injection Makes Dependencies VisibleCompare two classes.
  4. Lesson 3Change One Component Without Rebuilding the SystemGood boundaries show their value when requirements change.
  5. reflectionUnit 11 ReflectionDescribe one has-a relationship from your system and the responsibility boundary it creates.

Unit 12

  1. overviewUnit 12: Inheritance, Overriding, and Dynamic DispatchInheritance is useful when a subtype can genuinely stand in for a broader type while preserving its promises.
  2. Lesson 1Inheritance Makes an Is-a ClaimConsider a broad type:
  3. Lesson 2Dynamic Dispatch Chooses the Runtime BehaviorJava can hold a subtype object in a variable typed as a broader type.
  4. Lesson 3Prefer the Relationship You Can DefendComposition and inheritance can sometimes solve the same immediate coding problem. Their long-term claims are different.
  5. checkpointCheckpoint 4: Polymorphic DesignDesign a small Java system in which multiple implementations collaborate through a stable contract.
  6. reflectionUnit 12 ReflectionName one place where inheritance would have been possible in your design but you chose composition or an interface instead.

Unit 13

  1. overviewUnit 13: Exceptions and Defensive Failure HandlingExceptions are not random punishment from Java. They are runtime evidence that an operation could not satisfy an assumption or contract.
  2. Lesson 1An Exception Marks a Failed Runtime AssumptionYou have already seen runtime failures such as invalid integer parsing and invalid array indexes.
  3. Lesson 2Catch Where You Can Actually Decide What Happens NextA catch block is useful when that layer has enough context to make a meaningful decision.
  4. Lesson 3Preserve Context Instead of Swallowing FailureThis anti-pattern makes debugging harder:
  5. reflectionUnit 13 ReflectionDescribe one exception from your work as a failed assumption rather than as an error-message string.

Unit 14

  1. overviewUnit 14: Files, Parsing, and Resource BoundariesReal applications often persist or import data. The course keeps two responsibilities separate:
  2. Lesson 1Separate Reading Bytes From Interpreting RecordsSuppose a text file would contain:
  3. Lesson 2Path and Files Belong to the Full JDK LaneThe official Java Playground is excellent for language work, but a browser snippet environment is not your local operating system filesystem.
  4. Lesson 3Try-With-Resources Makes Ownership ExplicitSome Java APIs open resources that must be closed: files, streams, readers, sockets, database connections, and more.
  5. reflectionUnit 14 ReflectionSeparate one file-processing workflow into two boundaries: environment I/O and domain parsing.

Unit 15

  1. overviewUnit 15: Testing Behavior with JUnit 6Testing is not the final ritual after programming. A good test connects a requirement to an input, expected behavior, and observable result.
  2. Lesson 1A Test Case Starts With a Requirement, Not an AnnotationBefore you write @Test, decide what behavior must be true.
  3. Lesson 2JUnit Turns Expected Behavior Into Executable EvidenceFull JDK lane: this lesson's authentic JUnit execution requires a normal Java project environment with JUnit 6 available through your approved IDE/build tool. The browser core can still complete the same test-design…
  4. Lesson 3Regression Tests Guard What Already WorkedA bug fix can solve one failure and create another.
  5. reflectionUnit 15 ReflectionChoose the strongest test you wrote this unit.

Unit 16

  1. overviewUnit 16: Debugging, Refactoring, Packages, and Project StructureYou now have enough Java to create problems that syntax drills cannot solve.
  2. Lesson 1Debug From the First Divergence, Not the Last SymptomA bad output line may be the last visible symptom of a defect introduced much earlier.
  3. Lesson 2Refactoring Changes Structure, Not Required BehaviorRefactoring improves internal design without intentionally changing externally required behavior.
  4. Lesson 3Grow Into Packages and Multi-File Java DeliberatelyJava 25 compact source files let beginners start with behavior before class/file ceremony. They are an on-ramp, not the final architecture for every program.
  5. checkpointCheckpoint 5: Tested and Refactored ProgramTake a nontrivial Java program from an earlier unit and improve its structure without intentionally changing its required behavior.
  6. reflectionUnit 16 ReflectionIdentify the first meaningful divergence you found in one debugging exercise and explain why the final symptom appeared later.

Unit 17

  1. overviewUnit 17: Capstone Requirements, Architecture, and Test PlanThe final project begins before the final code.
  2. Lesson 1Start With a Problem You Can Turn Into Requirements"Make an app" is not a requirement.
  3. Lesson 2Architecture Assigns Responsibilities Before Files MultiplyA capstone architecture is not a screenshot of folders.
  4. Lesson 3Version 1 Must Be Testable, Not PerfectVersion 1 is the first integrated implementation you can evaluate against requirements.
  5. reflectionUnit 17 ReflectionWhich capstone decision reduced uncertainty the most before Version 1: a clearer requirement, data-structure choice, responsibility boundary, interface decision, or test case?

Unit 18

  1. overviewUnit 18: Validation, Failure Analysis, and Design DefenseThe final unit does not reward hiding the messy part of development.
  2. Lesson 1Turn One Failure Into a Root-Cause DossierChoose one Version 1 failure from your test matrix.
  3. Lesson 2Version 2 Needs Regression Evidence, Not ReliefA previously failing test turning green is necessary. It is not sufficient.
  4. Lesson 3Defend the System You Actually BuiltThe design defense is not a sales pitch.
  5. checkpointCheckpoint 6: Java Software Engineering CapstoneSubmit the complete Java capstone dossier. This checkpoint evaluates the chain from requirement through validation, not just the amount of source code.
  6. reflectionUnit 18 ReflectionWhat did your Version 1 failure reveal about your mental model, architecture, data assumptions, or test strategy?