WGU D387: Advanced Java

What D387 Advanced Java Is and Where It Fits in Your Degree

WGU D387, Advanced Java, is the final course in the Java sequence, worth 3 competency units. It sits in term 8 of the B.S. Software Engineering (Java track) standard path and in term 6 of the B.S. Computer Science standard path, so students in both programs meet it late in their degree. By the time you get there you have already worked through Java Fundamentals, Java Frameworks, and Back-End Programming. WGU's official course description is blunt about the entry bar, noting that the course "requires intermediate expertise in object-oriented programming and the Java language," and its two stated competencies are writing multithreaded object-oriented code with Java frameworks and determining how to deploy software applications using cloud services.

Direct answer: To pass D387, clone the provided project repository early, work through the tasks in order, and treat the rubric as your literal checklist. The code changes themselves are modest in size — the real challenge is understanding multithreading, localization, and containers well enough to explain what you did — so budget most of your energy for concepts and documentation, not typing.

D387 matters because it is where WGU stops treating Java as an academic exercise and starts treating it like a job. Modifying an existing codebase you did not write, wiring a back end to a front end, containerizing the result, and planning a cloud deployment is a compressed version of what junior developers actually do. Finish this course comfortably and you have concrete evidence that you can work inside someone else's architecture rather than only building from scratch.

The Performance Assessment: What You Actually Build

D387 is assessed by a Performance Assessment (PA) — a hands-on project, not a proctored multiple-choice exam. The assessment hands you an existing Spring application with a Java back end and an Angular front end and asks you to extend it. Based on WGU's published task description and consistent public accounts from students who have completed it, the work breaks into these areas:

• Multithreaded language translation. Implement concurrent code so the application presents a message in multiple languages. Students commonly reach for Java's executor framework together with resource bundles.
• Time zone handling. Display a message correctly across different time zones using Java's date-time APIs.
• Currency exchange display. Extend the front end so prices appear in additional currencies alongside the existing one.
• Containerization. Write a Dockerfile, build a Docker image of the modified application, and run it locally to prove it works.
• Cloud deployment planning. Produce a clear, step-by-step plan describing how you would deploy the containerized application to a cloud provider.
• Version-control evidence. Students report working in a course-provided Git repository and submitting branch history, so your commits form part of what gets evaluated.

That last point deserves emphasis: evaluators expect incremental commits, not one giant "finished everything" push. If your Git habits are rusty, the D197 Version Control guide covers the workflow fundamentals that D387 quietly assumes you already have. Always confirm the current requirements against your own course page and rubric — WGU refreshes task wording periodically, and the rubric you are graded against is the only authoritative version.

How Hard Is D387, and How Long Does It Take?

Students commonly place D387 in the middle of the difficulty range for the Java sequence — more demanding than Java Fundamentals, but less punishing than the framework-heavy courses before it, largely because the volume of code you write is small. Public student accounts most often describe finishing in one to four weeks: developers who already know threads and containers sometimes wrap up in a matter of days, while students newer to concurrency tend to need several weeks of steady evening work.

The difficulty is unevenly distributed. The conceptual core — multithreading — is genuinely tricky if it is new to you, and it is also the part you must be able to explain in your documentation. Meanwhile, a surprising share of lost time goes to logistics rather than code: getting the repository and build pipeline working, resolving local environment quirks, and getting Docker running on your machine. Plan for friction there and the rest of the course feels manageable.

A Working Study Plan for D387

Because this is a project course, "studying" looks different than it does for a proctored objective assessment. Here is a plan that mirrors how students describe moving through it successfully:

1. Days 1–2: set up before you study. Clone the course repository, create your working branch, open the project in your IDE, and run the application untouched. Do not start the course material until the unmodified project builds and runs on your machine — environment problems are far easier to diagnose before you have changed anything.
2. Read the rubric first, then the course material. The rubric tells you exactly which artifacts you must produce. Read each requirement and write, in your own words, what "done" looks like. Then use the course material and instructor resources to fill only the gaps you actually have.
3. Learn multithreading by predicting, not just watching. Before running any threaded example, write down what you expect the output order to be, then run it and compare. This is active recall applied to concurrency, and it exposes fuzzy understanding fast — which matters because you will need to justify your threading choices in writing.
4. Practice Docker in isolation. Before containerizing the course project, containerize something trivial — a one-file "hello world" server. Build it, run it, map a port, inspect it. Ten minutes of low-stakes practice removes most Docker anxiety.
5. Commit at every milestone. Each time one requirement works, commit with a message naming that requirement. This builds your submission evidence automatically and gives you safe rollback points.
6. Write the cloud deployment plan last, in plain steps. Pick one cloud provider, keep each step to a sentence or two, and walk through it as if a colleague who has never seen your project were following along. Vague plans are a common documentation weakness.

Spaced repetition earns its keep even in a project course: revisit your threading code two or three days after writing it and re-explain it aloud. If you cannot, your written explanation is not ready either.

Where D387 Students Lose the Most Time

• Skipping the rubric until submission day. In student accounts, submissions come back more often for a missing artifact — a screenshot, a file, a section of the write-up — than for broken code. Build your own deliverables checklist from the rubric on day one.
• Over-engineering the code changes. The tasks call for targeted modifications to an existing app, not a redesign. Rewriting large sections introduces bugs nobody asked you to risk.
• Treating threading as copy-paste. Working executor-service snippets are everywhere, but your documentation has to explain your implementation in your own words. Understanding beats borrowing, and it is also the only honest path through a graded submission.
• Fighting the environment silently. Repository permissions, IDE quirks, and Docker daemon settings trip up plenty of students. If you are stuck on tooling for more than an hour, contact your course instructor — environment issues are exactly what they field daily.
• One giant commit at the end. Your branch history is evidence of your process. A single monolithic commit weakens that evidence and forfeits the safety net incremental commits provide.
• Writing the deployment plan from memory. Base your cloud plan on documentation you have actually read from the provider, not a half-remembered tutorial. Evaluators can tell the difference.

D387 Readiness Checklist

• Can you run the unmodified course project locally from your own cloned branch?
• Can you explain, in two or three sentences, why the translated-message feature uses multiple threads and how your code creates and manages them?
• Can you describe what a resource bundle is and how Java selects the right one for a locale?
• Can you convert a time between two time zones in Java and name the API you used?
• Can you write a Dockerfile for a Java application, build the image, run the container, and verify the app responds on the mapped port?
• Can you walk someone through your cloud deployment plan step by step without skipping how the container image reaches the provider?
• Does your Git history show incremental commits tied to individual requirements?
• Have you compared your submission package against every line of the rubric, including screenshots and documents?

For more School of Technology course guides, browse the Technology hub or the full guide index. Official program details, including the current course list, are on wgu.edu.

FAQ

Is WGU D387 an OA or a PA?

D387 is a Performance Assessment. There is no proctored objective exam; you pass by submitting a completed project — modified application code, evidence of a running container, a cloud deployment plan, and supporting documentation — that meets every rubric requirement.

How many competency units is D387?

Advanced Java is worth 3 competency units. It appears in term 8 of the B.S. Software Engineering (Java track) standard path and term 6 of the B.S. Computer Science standard path, in both cases after Java Fundamentals, Java Frameworks, and Back-End Programming.

How long does D387 usually take?

Public student accounts cluster around one to four weeks. If you are comfortable with Java concurrency and have used Docker before, it can go much faster; if both are new, give yourself the full month and front-load the multithreading material.

Do I need to know Angular for D387?

Only lightly. The front-end work is small, pattern-following edits to existing Angular files — you extend what is already there rather than architecting anything new. Deep Angular knowledge is not required, though being able to read TypeScript helps.

What should I learn before starting D387?

Solid object-oriented Java, the Spring familiarity you picked up in Back-End Programming, and comfortable Git habits. If containers are new to you, spend an evening on Docker basics before your start date. D385 Software Security and Testing sits in the same term as D387 on the Software Engineering path, so many students plan the two together.

Can I fail D387 even if my code works?

Yes. Students most often report submissions returned for incomplete deliverables or thin documentation rather than for broken code. Treat the written explanations and the rubric checklist with the same seriousness as the programming and you remove most of that risk.