Java project workshop

Build something outside the lesson

A real project combines the small ideas you have practised. Work through one milestone at a time, keep tests, and get someone else to review the result.

1. Get a repeatable starting point

Install a JDK version 17 or newer and Maven. Follow the Java learning and setup material and Maven installation guide for your system. A JDK includes the compiler; a runtime alone is not enough.

java -version
mvn --version

Both commands should report an installed version. Maven should be using a suitable JDK. If either command is missing, fix the installation before changing the project code.

Unzip the project, open a terminal in its expense-tracker folder, then run:

mvn test

The starter compiles but some tests intentionally fail. Read the first failing test and its assertion. Implement the missing behaviour in ExpenseBook before changing App. The included README walks through each milestone.

2. Make the domain work first

1. Add a valid expense without allowing invalid input to change the book.
2. Total integer minor units with a long accumulator. Explain why a total can exceed one int even when each entry fits.
3. Return an immutable snapshot of entries. Verify that an earlier snapshot does not change when the book grows.
4. Run the tests after each change. Add a case of your own that would catch a plausible bug.

Once the domain tests pass, package and run the application:

mvn package
java -cp target/classes learn.stride.App

3. Grow it into the command-line project

The starter App only prints guidance. Implement add, list and total commands. Write down how arguments and invalid numbers work, then add UTF-8 persistence. Use temporary files in tests. Decide how a failed save protects the previous data instead of quietly losing it.

Keep the command parser, expense rules and file storage separate. Your acceptance test is a clean checkout that can add an entry, restart, list it and calculate the correct total. A green starter test suite alone does not check those later features.

4. Continue into services and operations

In the later API project, reuse the domain rules behind a documented HTTP boundary. Add parameterised database access and migrations, integration tests, permission checks and finite timeouts. Keep the first version small: one complete request that you can trace is more useful than several unfinished features.

For the final project, demonstrate a dependency failure and recovery, measure a representative workload, document a consequential design choice and revise the system after review. Record what remains uncertain; do not label an untested assumption as a guarantee.

5. Get a review and keep evidence

Ask someone to run the project using only your README. Show the tests, a failed case, a fix and the next green run. Record a project reference, concrete feedback, revisions and unresolved issues in Stride’s project notes. Those notes are your self-review, not an automated professional qualification.

Use the official Java learning material, Maven build guide and JUnit guide when you need the full API or tool contract.