4D Training & Consultancy

Software Development

Modernizing Legacy Java Applications

A migration and refactoring course for teams carrying a Java application older than the runtime it should be on. The programme covers the Java 8 to 21 upgrade path, the javax to jakarta namespace change, dependency and build modernization, and the incremental refactoring that keeps delivery running throughout.

4 daysIn-house, online, or customized deliveryCorporate teams and professional groupsLevel: Intermediate to Advanced

Overview

Practical learning for workplace transfer.

Legacy Java rarely fails outright. It stalls: the framework version blocks a security patch, the build works on exactly one machine, nobody will touch the payment module because unrelated things break, and every upgrade attempt is abandoned halfway through a quarter. This course supplies a sequence that holds up in practice. Participants inventory the system and rank its risks, write characterization tests to freeze current behaviour, modernize the build and dependency tree, carry out the jakarta namespace migration, and then extract modules one at a time with the strangler-fig pattern. The objective throughout is a system that stays deliverable while it is being changed.

Prerequisites

Experience maintaining a production Java application, with familiarity with Maven or Gradle and an application server or servlet container.

Objectives

  • Assess a legacy Java codebase for upgrade risk, dependency debt, and behavioural uncertainty.
  • Plan a staged migration from Java 8 to Java 17 or 21 that leaves a working system at every step.
  • Execute the javax to jakarta namespace change across code, configuration, and dependencies.
  • Modernize the build, dependency tree, and reproducibility of an inherited project.
  • Write characterization tests that pin existing behaviour before any refactoring starts.
  • Apply the strangler-fig pattern to replace modules without launching a rewrite programme.

Target audience

  • Engineering teams maintaining Java applications built before Java 11
  • Technical leads planning a runtime or application framework upgrade
  • Architects designing a route out of a long-lived monolith
  • Developers responsible for security patching and dependency updates
  • Delivery managers scheduling modernization alongside feature commitments
  • Consultants and contractors taking ownership of an unfamiliar Java system

Program outline

A clear structure for the learning journey.

Program outline

Outline points are grouped in one designed block instead of being treated as separate module cards.

Module 1: Assessing the System You Inherited

Building an inventory of modules, dependencies, runtimes, and entry points

Identifying unsupported versions, known vulnerabilities, and abandoned libraries

Mapping the areas of the system nobody will touch, and finding out why

Producing a risk-ordered modernization backlog with business input

Module 2: Freezing Behaviour Before Changing It

Characterization tests that record what the system currently does, not what it should

Finding seams in code written without any dependency injection

Approval testing for outputs too large to assert field by field

Establishing a baseline for build time, test time, and runtime behaviour

Module 3: The Java 8 to 21 Upgrade Path

Removed APIs, encapsulated internals, and the strong encapsulation change

Module system effects on class-path applications and reflective access

Language and library gains worth adopting during the upgrade itself

Staging the upgrade so the application still builds and ships at each step

Module 4: The javax to jakarta Namespace Migration

Where the namespace change reaches: code, descriptors, and generated sources

Aligning servlet, persistence, and validation API versions across the stack

Transformer tooling versus manual migration, and when each one fits

Third-party libraries that never migrated and the options that remain

Module 5: Build, Dependencies, and Reproducibility

Untangling a dependency tree carrying conflicts and duplicate classes

Maven or Gradle modernization: plugins, toolchains, and pinned versions

Reproducible builds and removing machine-specific configuration

Standing up continuous integration for a project that only ever built locally

Module 6: Incremental Architecture Change

Strangler-fig routing between the old and the new implementation

Extracting a module together with its data and defining the new boundary

Anti-corruption layers between modernized and untouched parts of the system

Sequencing the work so delivery never pauses for a rewrite

Materials provided

  • Course workbook, annotated code samples, and reference notes
  • Hands-on lab environment and starter repositories
  • Exercises, checklists, and reusable code templates
  • 4D Certificate of Completion
  • Post-course technical guidance

Training Options

Programs can be delivered in-house, online, or in a blended format depending on your team's schedule, location, and learning objectives. When an external certificate or exam is included, certification rules and fees remain under the relevant awarding body's policies, while 4D provides the training and preparation support.

Why choose 4D

4D treats modernization as a delivery problem rather than a technical wish list. Trainers help participants order the work by risk, wrap characterization tests around the modules everyone avoids, and rehearse the jakarta migration on a copy of a real application, so the plan that leaves the workshop already has sequence, dates, and named owners.

Speak to 4D

Plan the right training or consultancy path for your team.

Share a few details and 4D will help route your inquiry toward corporate training, consultancy, assessment, Phoenix-enabled support, or a tailored program.