Posts

Prompt Engineering for Java Developers: A Practical Guide

You shipped the summarizer from the last lesson. It takes a support ticket, calls the model, and returns a summary. It worked in your demo — and then the tickets started coming in at 2 a.m. and the summaries started coming out in three different formats: sometimes bullet points, sometimes a paragraph, sometimes a paragraph with opinions . Your downstream code expected a neat JSON object with summary and urgency fields. Instead it got a haiku about a broken router. Nothing in your Java code changed. What changed is that you asked a probabilistic system for a deterministic contract and got a vibes-based answer. Prompt engineering is the discipline of closing that gap — not by finding magic words, but by treating the prompt like a real engineering artifact: specified, tested, versioned, and never trusted without validation . The memorable principle for this whole post: "Validate the output, not the prompt." No matter how carefully you word the request, the contract li...

Calling LLMs from Java: HTTP, JSON & Streaming

This is post 2 of 10 in the AI for Java Developers track — Java-first, hype-free AI integration. New to the series? Start at the Java Learning Roadmap 2026 hub . The customer problem Your company's support team drowns in long customer threads — fifty-message email chains where the actual issue hides somewhere in the middle. They ask you, the Java developer, for an internal tool: paste a thread in, get a short summary out. No new framework, no microservice sprawl — just call a chat API from the Java service you already run. That means this post is about plumbing, not magic: how to send an HTTP request to a chat API, shape it correctly, parse the answer, survive the ways it fails, and stream tokens so the UI doesn't sit silent for twenty seconds. By the end you'll have one complete, copy-pasteable client class you can actually run. Prerequisites: Java 21 (HttpClient, records, text blocks), Maven or Gradle for the Jackson dependency, and an API key from a chat-...

AI for Java Developers: The Landscape

Picture a standup not unlike yours. The product manager says: "Customers keep asking whether we have AI. Can we add AI to the support dashboard by next quarter?" Three developers hear three different projects. One hears a chatbot widget. One hears automatically summarized tickets. One hears "replace the search box with something smarter." All three nod. None of them means the same thing. That gap — everyone saying "AI" while nobody shares a vocabulary — is the real blocker on most teams. Not the math. Not the model weights. The words. This post fixes that. It gives you a map of the landscape: what a large language model actually does, the handful of building blocks every AI feature is assembled from, and exactly where your Java code sits in the picture. Theory is kept to the minimum you need to navigate the rest of this track — everything else is grounded in one concrete feature we will carry through all ten posts. The running example. We will gro...

Oracle JDK 21's Free Updates Ended: What Java Teams Must Do Before Oct 20

There is a date sitting eight days in front of you, and most Java teams have not put it in their calendar. On October 20, 2026 , Oracle ships its quarterly Critical Patch Update. For JDK 21, that release is the first one published under the Java SE OTN license — the paid terms that already cover Java 8, 11, and 17. If you run Oracle's own JDK 21 binaries in production, this post is your checklist. What actually changed Oracle JDK 21 shipped in September 2023 under the No-Fee Terms and Conditions (NFTC) license, which permits free use — even commercial and production use. Oracle's stated policy: the current LTS stays under NFTC, and the previous LTS transitions to the OTN license one year after the next LTS release. JDK 25 arrived in September 2025, so JDK 21's free window ran through September 2026 . Oracle's own licensing FAQ says updates after that are planned under the Java SE OTN license , the same paid terms governing Java 8, 11, and 17 today. Two clarifi...

Capstone: End-to-End Pipeline

Ten posts ago you couldn't draw the data platform. Now you're going to run one. This capstone wires every row of the platform diagram from post 1 into a single working pipeline: a stream of e-commerce order events flows through ingest → validate → transform → store → serve , and every stage runs for real on this lab machine — the event generator, the validator with its dead-letter queue, a Spark job with a genuine shuffle, a Parquet file with inspectable internals, and two serving systems answering the two questions they're built for. By the end you'll have watched the same numbers come out of three different systems and agree with each other. That agreement is the whole game. Lab honesty, up front. Everything shown as a run below actually ran: the generator (5,000 events), the validator (113 rejects), the Spark RDD transform in local mode (real reduceByKey shuffle), the Parquet write/read with footer inspection, the Redis serving demo (Jedis), and the ClickHouse ...

Redis & ClickHouse: Storage & Serving

Post 1 opened with a scene: a 2 TB Postgres, a four-hour revenue report, and a product manager asking for "a dashboard that updates every minute." The track since then has built the pipeline that feeds that dashboard — Kafka carrying events, Spark crunching them. But a pipeline that nobody can read from at speed is a write-only achievement. The dashboard has two questions it must answer fast: "what are this user's features right now ?" (milliseconds, millions of times a day) and "how did revenue trend by country this quarter?" (billions of rows, seconds). One system cannot answer both well. This post gives you the two that can: Redis for the millisecond question, ClickHouse for the billion-row question. The Data & Messaging track's "Caching in Java" post already covered Redis-as-cache — cache-aside, eviction, TTLs, thundering herds. We won't repeat any of that. This post goes deeper into Redis-as- serving-layer : its data str...