Posts

Java Singleton Pattern: Enum, Lazy Holder & Double-Checked Locking Explained

Maya's bookstore app has grown since the last post. Checkout, receipts, and nightly reports all need the same shop settings: the store name, the currency, and the tax rate. Each part of the app loads those settings its own way — checkout reads the settings file when it starts, receipts read it again when printing, reports read it a third time overnight. That worked until the day Maya changed the tax rate at noon: checkout used the new rate, receipts still used the old one, and the day's books did not reconcile. Three copies of "the settings" turned out to be three chances to disagree. This post is about the pattern that answers a different question from the last one. Post 1, Design Patterns in Java: What They Are, When to Use Them, and When Not To , asked what varies? This post asks how many? — and when the honest answer is "exactly one," the Singleton pattern is the shape for it. The principle for this lesson: a singleton answers "how many?" —...

Design Patterns in Java: What They Are, When to Use Them, and When Not To

Maya runs a small online bookstore. Her checkout code started simple: add up the cart, apply a discount, print a receipt. Then the business grew. Students asked for 10% off. A seasonal sale added 15%. Loyal customers earned 5%. Each new rule meant opening the checkout code, adding another branch, and re-testing everything the checkout already did — because every edit touched the same method that all the old rules lived in. This is the exact moment design patterns exist for. Not as clever tricks, and not as a badge of seniority — as answers to a recurring question: this part of my program keeps changing; how do I shape the code so the next change is small and safe? This post answers that question with one pattern, worked end to end, and gives you the map for the rest of the track. The principle for this lesson: give what varies a name and a seam. 1. The customer problem Maya's checkout has one job that never changes — turn a cart into a total and a receipt — and one part that ...

JDK 27 Released: G1 GC Is Now the Default, Compact Object Headers & Post-Quantum TLS — Should You Upgrade?

On September 15, 2026 , JDK 27 reached general availability — the 18th feature release in a row to ship on Java's six-month cadence. It carries nine JEPs, but the headline is not the count. It is this: JDK 27 is the release where Java stops asking you to opt in to good defaults and turns them on. Two of the four finalized JEPs quietly change how your running services behave without you touching a line of code — and a third hardens every TLS connection your apps make against quantum computers. If your services run in small containers and you never set a GC flag, this release changes your garbage collector. Read on before you bump the base image. The release at a glance Four JEPs are final and active with no special flags; the rest stay in preview or incubator, meaning their APIs can still change: JEP Feature Status 523 Make G1 the default garbage collector in all environments Final 527 Post-quantum hybrid key exchange for TLS 1.3 Final 534 Compact object headers by defa...

The AI Playbook: Shipping Reliable AI Features

The demo wowed the room. Somebody typed a gnarly customer question into the chat box, and the assistant answered it perfectly — cited the right policy, used the right tone, even apologized for the wait. The VP leaned forward. "Let's ship it next month." Then the quiet part, usually said later and quieter: "To 10,000 users. And it can't hallucinate about refunds." That gap — between the demo and the deployment — is where most AI features go to die. The demo was a happy path through one question. Production is every question, asked by strangers, at 2 AM, with your company's name on every answer. The model didn't change between the two. Everything around it did: the inputs get weirder, the failures get more expensive, and "it usually works" stops being a sentence anyone will accept. This post is the capstone of this track: a numbered playbook for closing that gap, practiced-judgment style. Not laws of nature — every team tunes these t...

AI Hallucinations: Why AI Makes Things Up and How to Fix It

You ask your AI assistant a simple question: "What time does Northgate Dental close on Saturdays?" It answers instantly, in perfect sentences: "Northgate Dental is open 9:00 AM to 2:00 PM on Saturdays." Confident. Specific. Plausible. So you plan your whole Saturday around it, drive across town at 1:30 PM — and find a locked door with a sign that says they're closed on weekends, always have been. The hours were never real. The model didn't misread a website or garble a fact it knew. It invented a Saturday schedule out of nothing, delivered it with total confidence, and moved on as if nothing had happened. This is an AI hallucination : fluent, confident, specific — and wrong. Hallucinations are the single most misunderstood behavior of modern AI. They are not bugs in the usual sense, not lies, and not fixable by "a better prompt" alone. They come from the deepest design decision in how these models are built. Once you understand that deci...