Lesson Overview
Understand how Java names code so programmers can use libraries without naming conflicts.
Portfolio focus: Use one fully qualified Java library class.
Starter: think before typing
Before running this code organisation example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `2026-06-13`; predict how the focus line helps produce that evidence.
Learning Objectives
- Explain why libraries need organised names.
- Use a fully qualified Java class name.
- Describe what an import saves you from typing.
- Avoid creating unclear or conflicting names.
Learning Outcomes
- By the end of the lesson, you can explain why libraries need organised names.
- By the end of the lesson, you can use a fully qualified Java class name.
- By the end of the lesson, you can describe what an import saves you from typing.
- By the end of the lesson, you can avoid creating unclear or conflicting names.
Why this idea exists
Packages and imports exist because real programs contain many classes, often written by different people. Names need structure so that one useful class does not collide with another class that happens to have the same short name.
As software libraries grew, languages needed namespace systems to organise code and make reuse manageable. Java packages connect source layout, library design and public naming into one convention.
This lesson fits the arc by moving from single-file programs to organised projects. It prepares learners to use standard libraries, separate their own code into meaningful areas and read unfamiliar project structures.
Deep dive
Mechanism in this example
The important mechanism is visible around `java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);`. Read it as a concrete move in the program, not as decorative syntax: identify what value, object, branch, call or boundary is being created at that point.
Design pressure
This lesson fits the arc by moving from single-file programs to organised projects. It prepares learners to use standard libraries, separate their own code into meaningful areas and read unfamiliar project structures.
Failure mode to watch
For Packages, Imports and Names, deliberately disturb the assumption behind `java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);`: use an awkward value, missing input, wrong order of calls or boundary case. The useful question is how that disturbance exposes a weakness in the code organisation design.
Extension step
Extend the example by doing this: Rewrite it with an import in your own editor. The point is to make one small change that forces you to revisit the concept, rather than adding unrelated features.
Portfolio standard
The portfolio note should not repeat the lesson wording. It should show the edited code, the run result, and your own explanation of this evidence: explain how the package name prevents confusion.
Lesson visual
Type this and run it
Create PackagesImportsAndNamesDemo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.
public class PackagesImportsAndNamesDemo {
public static void main(String[] args) {
java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);
System.out.println(lessonDate);
}
}Build and run it with:
javac PackagesImportsAndNamesDemo.java && java PackagesImportsAndNamesDemoExpected baseline: 2026-06-13
Run the code in your browser
Use the editor as an experiment surface. First run the checked version, then make one small change to the part of the program that demonstrates code organisation and compare the new behaviour with the reference output.
2026-06-13Line-by-line explanation
Read the code as a sequence of responsibilities. The focus line for this lesson is java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);; the surrounding lines prepare it, use its result or make the behaviour observable.
public class PackagesImportsAndNamesDemo {This names the runnable class for the Packages, Imports and Names example, giving the compiler and JVM one clear unit to build.
public static void main(String[] args) {This is the program entry point. In Packages, Imports and Names, it keeps the demonstration of code organisation in one traceable starting script.
java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);This introduces lessonDate as named state for Packages, Imports and Names. Later lines can read, update, pass or print that specific value as evidence.
System.out.println(lessonDate);This prints lessonDate as the observable evidence for Packages, Imports and Names. The output lets the learner check whether the code organisation idea behaved as predicted.
}This closes the innermost Packages, Imports and Names block, so the immediately preceding method, branch or loop has finished.
}This closes the outer Packages, Imports and Names structure, returning the reader to the surrounding class or file.
Worked example
From code to explanation
Problem: Use Packages, Imports and Names to complete a small portfolio-quality step: Use one fully qualified Java library class.
Method: Locate the line `java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);`, explain the exact role it plays, then decide what you would change to extend the example without changing the whole program.
Reveal worked answer
The checked run should produce `2026-06-13`. A strong answer links the result back to code organisation: what was created, selected, stored, called or protected, and why that matters for the portfolio task.
Trace the program
Before: Before the key operation, identify the relevant value, object, branch or resource that the code organisation concept depends on.
During: Trace `java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);` as the Packages, Imports and Names example executes. Say whether that operation creates data, checks a condition, calls behaviour, stores information or crosses a boundary.
After: Compare the run with the expected evidence: `2026-06-13`.
Change: Now rewrite it with an import in your own editor, run again, and explain the smallest reason the behaviour changed.
Common misconception
A common mistake in packages, imports and names is treating the example as a finished answer. For code organisation, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?
Quick checks
1. In this Packages, Imports and Names example, what is the best reason to focus on `java.time.LocalDate lessonDate = java.time.LocalDate.of(2026, 6, 13);`?
2. Which evidence is strongest after you edit and rerun this example?
How to study this lesson
For Packages, Imports and Names, predict how code organisation changes the run before you press Run.
Use the first portfolio task as your main edit: Use one fully qualified Java library class.
Use the second task as your variation: Rewrite it with an import in your own editor.
Finish with evidence, not a diary entry: Explain how the package name prevents confusion.
Portfolio Practice
- Use one fully qualified Java library class.
- Rewrite it with an import in your own editor.
- Explain how the package name prevents confusion.
Final self-check
Can you explain the key operation?
Explain the line identified in the quick check in one or two sentences. Your answer should say what it does before the output 2026-06-13 appears.
Can you justify the portfolio evidence?
Your evidence should include the original run, one edited run, and a short note explaining how the edit affected code organisation.
Study route
Practise code organisation by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.
Next, move into Requirements and User Stories and carry forward one improvement from this lesson into the next program.