D387 Advanced Java is banner number ITSW 3024 and three competency units in the School of Technology. The catalog describes it as refining object-oriented skills by implementing multithreaded Java code to meet business requirements, which names the two halves of the course precisely. Half of it is concurrency, the hardest ordinary topic in application programming, and half of it is the connection between a business requirement and the technical choice that satisfies it. What it builds toward is the ability to write code that does several things at once and to explain, in a sentence a manager could read, why that was the right answer.
Concurrency is the competency, and it is unforgiving
Single-threaded bugs are reproducible. You run the program, it fails the same way, you fix it. Concurrency bugs are not, and that difference is the entire difficulty of this course. A race condition can pass a hundred runs and fail on the evaluator's machine because their processor scheduled two threads differently than yours did. Code that appears to work is therefore not evidence that the code is correct, and the course grades whether you know the difference.
The vocabulary has to be exact. A race condition is two threads reaching shared state without ordering. A deadlock is two threads each holding what the other needs. Starvation is a thread that never gets scheduled. Visibility is the separate problem of one thread not seeing another thread's write at all. Students routinely use race condition as a label for all four, and an aspect asking you to identify a concurrency hazard will not accept the wrong name for the right symptom.
Java gives you several levels of tooling and choosing the right level is scored. The synchronized keyword and intrinsic locks are the basic mechanism. The concurrency utilities that arrived with the modern platform give you executor services, concurrent collections, atomic types, latches and barriers, and futures, and most business requirements are better served by one of those than by managing raw threads. Creating threads by hand where an executor service was the natural answer is a working solution that reads as an outdated one.
The business requirement framing is not decoration. A requirement to process a batch of independent records is a parallelism problem. A requirement to keep a user interface responsive while work happens is a background execution problem. A requirement to coordinate producers and consumers at different speeds is a queueing problem. Naming which one you have is the first move, and it decides everything after it.
Turning scored aspects into a threading design and a word budget
Each aspect is scored on its own at WGU, a 2 in every one is required, and a single gap sends the task back. In a concurrency course the most useful translation is to convert each aspect into either a piece of the threading design or a piece of evidence that the design behaves correctly.
Work the arithmetic. Suppose seven scored aspects and a written portion of roughly 1,400 words. Seven into 1,400 is 200 apiece. Now sort by type. Two aspects are implementation demonstrations, satisfied by the code, needing about 90 words each of pointer text naming the class and method, which is 180 and releases 220. One aspect asks you to identify the shared state and the hazards it creates, and that is the technical core of the document, so give it 400. One asks you to justify the synchronization mechanism you chose against an alternative, another argument section, 350. One asks for evidence of correct behavior, which is mostly a table with 150 words around it. The last two hold at 200 each. Adding it up: 180 plus 400 plus 350 plus 150 plus 400 is 1,480, so trim the justification to 300 and you land near 1,430 with two thirds of the words on hazard analysis and justification.
Design the concurrency before writing any of it. Write down every piece of state two threads can touch, decide for each one whether it becomes immutable, confined to a single thread, or guarded by a specific lock, and record that decision. That table is both your design and the answer to the aspect that asks how you protected shared state.
Stuck on the threading task?
Send the aspects and the business scenario. You get a shared-state table, a mechanism choice with the argument behind it, and a model write-up.
The table that organizes a concurrency deliverable
| Shared item | Who touches it | Strategy | Why that strategy |
|---|---|---|---|
| Configuration values | All worker threads, read only | Make immutable, publish safely at construction | Nothing to protect once nothing can change it |
| Work queue | One producer, several consumers | A blocking queue from the concurrency utilities | Handles waiting and handoff without hand-written locks |
| Running counters | Every worker increments | An atomic type | Increment is not atomic in plain code, and a lock is heavier than needed |
| Aggregate results | Workers write, main thread reads at the end | A concurrent collection, or per-thread results merged once | Avoids contention on the hot path |
| Completion signal | Main thread waits, workers finish | Executor shutdown and awaitTermination, or a latch | Explicit coordination beats sleeping and hoping |
| Shutdown flag | Any thread sets, all threads read | A volatile field or an interrupt | Visibility, not mutual exclusion, is the actual problem |
Fill this in for your own program before coding and most of the written document is already drafted, because every row is a decision with a reason attached, which is exactly the shape a rationale aspect wants.
How to evidence code whose bugs hide
Because a passing run proves little, the evidence in this course has to be constructed deliberately. Run the concurrent section many times rather than once and report the count. Run it with more threads than cores so the scheduler is forced to interleave. Where a requirement involves ordering or totals, assert the invariant in the code rather than eyeballing the output, so a violation fails loudly instead of scrolling past.
Logging is your instrument. Include the thread name in every log line, timestamp to the millisecond, and log at the boundaries where state changes hands. A log excerpt showing two threads entering and leaving a guarded section in a correct order is far stronger evidence than a screenshot of a final total.
Citation in an advanced Java course means the platform documentation first. The official API documentation defines behavior for the concurrency classes and the language specification defines the memory model, and both cite in APA as organizational web sources when your program requires it. Established texts on Java concurrency are legitimate secondary sources. Forum answers about threading are unusually unreliable, since much of the advice online predates the modern concurrency utilities and recommends patterns the platform has since replaced.
What earns Competent in a concurrency task
WGU records Competent or Not Competent with no letter grades and no ordinary grade point average, and a performance assessment that misses an aspect returns for revision without penalty. In a six month flat rate term the cost of a return is the days it takes, so the aim is a first submission where every claim has evidence attached.
Passing submissions state their concurrency model explicitly instead of leaving a reader to infer it from the code. They name the hazards their design faced and the mechanism that addresses each. They show the program producing correct results under repetition and load rather than once. And they connect the technical choice back to the business requirement, which is the sentence most students leave out.
Returns are consistent. Synchronization applied to everything, which removes the hazard and also removes the concurrency, so a program that is technically thread safe achieves nothing in parallel. Threads created and never joined or shut down, leaving the program hanging on the evaluator's machine. Sleep calls used to make timing work out. And an aspect about hazard identification answered with a textbook definition of a race condition rather than a description of where one could occur in this code.
Five mistakes that cost D387 students days
- Testing once and calling it correct. Concurrency defects are probabilistic. Repetition under load is the only testing that means anything here.
- Using sleep as coordination. A sleep that makes the output look right is a bug that has been timed rather than fixed, and evaluators recognize it immediately.
- Managing raw threads where an executor fits. The concurrency utilities exist. Hand-rolled thread management is more code, more risk and a weaker answer to a justification aspect.
- Confusing visibility with mutual exclusion. A flag read by many threads needs visibility guarantees, not a lock, and using the wrong tool signals the concept was not understood.
- Leaving the business requirement unmentioned. The catalog frames this course as meeting business requirements. A technically excellent document that never says which requirement the design serves has skipped the framing the course is built on.
How we work on this course
D387 support is design and review rather than code delivery. Send the scored aspects and the scenario and you get a shared-state analysis, a recommended mechanism for each item with the argument that defends it, a test approach that will actually surface a race, and a model written portion in the register WGU evaluators expect. Code review names the hazard and explains the fix so you can make it, because a justification aspect cannot be answered about a decision you did not make. If your course includes an objective assessment, support there is preparation only, and objective assessments are proctored: we never sit or assist during one, and we never ask for or use portal credentials.
Concurrency is the topic where an unplanned week turns into three. In a six month flat rate term that is the difference between closing four courses and closing two, which is the whole economics of the model.
Three questions D387 students ask
Is D387 the same course as ITSW 3024?
How much Java do I need before D387?
My program works every time I run it. Is that enough?
Where D387 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.