Lab 03 — Issue State Machine

Model the Apache JIRA issue lifecycle as an explicit state machine with validated transitions — the same lifecycle every Apache committer uses to track work from "reported" to "shipped in a release".

What you build

ClassResponsibility
IssueStateEnum: OPEN / IN_PROGRESS / IN_REVIEW / RESOLVED / CLOSED / REOPENED
IssuePriorityEnum: BLOCKER / CRITICAL / MAJOR / MINOR / TRIVIAL
IllegalTransitionExceptionThrown when an invalid state transition is attempted
IssueHolds issue metadata; enforces valid state transitions

Run the tests

mvn clean test

Expected: 11 tests, 0 failures.

Valid transitions

OPEN         → IN_PROGRESS, RESOLVED
IN_PROGRESS  → IN_REVIEW, OPEN
IN_REVIEW    → RESOLVED, IN_PROGRESS
RESOLVED     → CLOSED, REOPENED
CLOSED       → REOPENED
REOPENED     → IN_PROGRESS, RESOLVED

Key rules:

  • No direct CLOSED → IN_PROGRESS — must go through REOPENED.
  • OPEN → RESOLVED is valid (quick-close for duplicates / won't-fix).
  • The fixVersion field is set by the committer at RESOLVED time.

Interview talking points

  • "An explicit transition table prevents impossible states — the compiler (or the test) tells you when you skip a step."
  • "In Apache JIRA, fixVersion is how the release manager generates release notes — it's set at RESOLVED, not at CLOSED."
  • "REOPENED → IN_PROGRESS allows the assignee to pick it back up without going through the full triage cycle again."