RSS Amplifier

Engineering With Java · Aug 16, 2026

Engineering With Java: Digest #99

0
Sign in to vote or save

Suraj Mishra · Engineering With Java

👋 Java Devs! Welcome to this week's edition. I hope you all are doing great!

This week's issue leans heavily into performance and platform internals. On the article side, we dig into DuckDB replacing hand-written Java loops in Spring Batch, why Java Stream's anyMatch/findFirst/count are quietly allocation-hungry, OpenJDK's guidance on safely evolving sealed-type switches, and Project Valhalla's first real preview reshaping how == works for value objects.

On video, catch a Spring Boot/Quarkus code-quality tool with a built-in MCP server, idiomatic Kotlin with Spring Boot 4, the latest on Valhalla and post-quantum crypto from Inside Java, and a deep dive into JDK Flight Recorder for production profiling. Let's dive in!

📢 If you have product, services or job that you like to present in front of ~8200 Java and Spring Developers , considering sponsoring this newsletter.

Sponsorship Details

DuckDB in Spring Batch: Replace In-Memory Java Loops with One SQL Statement

This article compares two Spring Batch apps that compute per-group order aggregates from a CSV—one using hand-written Java loops with an in-memory HashMap, the other replacing the transform step with a single DuckDB SQL statement inside one small Tasklet. The recommendation: use DuckDB for aggregation-heavy transform steps over files/databases it can read, while keeping the classic reader/processor/writer pattern for row-level enrichment, external calls, or strict downstream writes.

Preparing for Change: Safe Switching over Sealed APIs

This OpenJDK guide (Bimpoudis, Buckley, Goetz) explains that exhaustive switches over sealed types don't stay exhaustive forever; adding a new permitted subtype can break recompilation or cause a MatchException at runtime, and argues this is a feature, not a bug, since it forces developers to consciously re-verify their assumptions as the domain evolves. It strongly advises against using default as a catch-all (since it hides broken assumptions, doesn't handle null, and can mask erroneous results), recommending instead either handling every permitted subtype explicitly or using the narrowest possible match-all case (e.g., case Fruit other rather than case Object other).

Project Valhalla’s First Preview: JEP 401 Redefines == for Java Objects

This article covers JEP 401 (Value Objects Preview), now integrated into JDK 28, which introduces identity-free classes via a new value modifier; instances with only final fields where == compares by field values rather than reference identity (though equals is still needed since state isn't always equivalent). It requires --enable-preview at compile and runtime, comes with construction rules enforced by JEP 539's bytecode verification, restrictions on synchronized, and migration of value-based JDK classes like primitive wrappers and LocalDate; the payoff is potential JVM optimizations like scalarization or flattening into compact representations, though this isn't guaranteed and falls back to ordinary allocation when constraints (like atomicity limits) aren't met.

Allocation Hungry Any/All/None, FindFirst, and Count Methods on Java Stream

Donald Raab (Eclipse Collections creator) explains that Java Stream methods like anyMatch, allMatch, noneMatch, filter().findFirst(), and filter().count() are surprisingly allocation-heavy; each call creates a Stream object (80-88 bytes) plus several internal closures/inner-class objects, even when used serially and eagerly, generating unnecessary garbage. He recommends avoiding these patterns in hot code paths or libraries, instead using Eclipse Collections' Iterate utility (anySatisfy, detect, count, etc.) which accomplishes the same tasks with near-zero allocation.

Optimistic Concurrency with SQL Version Columns

This article explains optimistic concurrency using SQL version columns to prevent lost updates, where a stale write silently overwrites newer data because updates that key only on a row's ID have no way to detect intervening changes. The fix is carrying a version value from the original read into the UPDATE's WHERE clause (e.g., WHERE id = 101 AND version = 7) alongside incrementing it, so a stale write matches zero rows instead of overwriting newer data, with the application detecting conflicts via the affected-row count.

Evolving a Java MCP Server During MCP Specification Upgrades

This article demonstrates how a Helidon-based Java MCP server can adopt the new MCP 2026-07-28 spec; which moves the protocol to stateless HTTP, replaces initialize with server/discover, and adds explicit protocol headers, cache metadata, and typed tool output, without breaking existing 2025-06-18 clients. Using the urgency-mcp example, it adds a routing-level adapter (McpRequestLoggingFeature/StatelessMcpProtocolHandler) that intercepts only requests carrying the new protocol header, enforces the 2026 stateless contract (rejecting session IDs, validating headers, handling discovery/tools/list/tools/call), and otherwise lets legacy clients pass through to the original generated Helidon MCP route unchanged.

Java Concurrency Programming Learning Roadmap: Understanding Threads Through Problems

It proposes learning Java concurrency problem-first, starting from why concurrency matters (response time, multi-core use), then working through atomicity, visibility, and ordering problems, mapping solutions (volatile, synchronized, ReentrantLock, AQS, CAS), thread cooperation (CountDownLatch, CyclicBarrier, Semaphore, CompletableFuture), safe shutdown, thread pools, concurrent collections, and deadlock avoidance; framed as a conceptual build-up rather than API memorization. Let me know if you’d like anything different from this pass (e.g., shorter, different focus).

📢 Get actionable Java and Spring Boot insights every week, including practical code tips and real-world, use-case-based interview questions, to help you level up your backend skills—join 8200+ subscribers for hand-crafted, no-fluff content.

Upgrade to paid now (60% discount) and get the annual membership at $50/year forever that is ~ $4/mo.

So far we have covered 70+ real world based interview questions and will add up to 100 by end of this year.

Testimonials

BootUI - Inspect, Analyze and Improve your Spring Boot and Quarkus Applications

Boot UI is a single-dependency dev-console tool for Spring Boot and Quarkus apps that scans code against best practices (architecture, REST APIs, security, Hibernate) with scoring and fix suggestions, built by a core JHipster contributor, while also offering live monitoring of health, metrics, SQL queries, scheduled jobs, caching, and messaging. Its standout feature is a built-in MCP server that plugs into AI coding assistants like IntelliJ's, letting you ask an agent to run scans and even fix violations directly.

Idiomatic Kotlin applications with Spring Boot 4

Sebastian Deleuze (Spring Framework core committer) covers best practices for idiomatic Kotlin with Spring Boot 4, arguing clean code still matters in the AI-agent era since agents copy patterns from your codebase, and recommends Java 25, Gradle Kotlin DSL, and upgrading to Spring Boot 4 for continued support. Key Spring Boot 4 features include modularized auto-configuration, full JSpecify-based null safety across the entire Spring portfolio (checked via NullAway, now natively translating to Kotlin null safety), and Kotlin 2.4's fix for the classic Jackson/Hibernate annotation-target gotcha.

JSON API, Valhalla Progress, LTS ❤️ PQC

This Inside Java Newscast (Nicolai Parlog) covers several OpenJDK updates: Project Valhalla's value types and strict field initialization have merged into JDK 28 early access, with Dan Smith identifying ~60 JDK API classes as migration candidates (though not urgent); primitive patterns will get another unchanged preview in JDK 28 due to overlap with constant patterns; and JEP 540 proposes an incubating, deliberately minimal JSON API (not meant to replace Jackson/GSON) targeting JDK 28.

Efficient Profiling and Troubleshooting for Java Applications

This talk by Michael introduces JDK Flight Recorder (JFR), an event-based, always-on recording framework designed for production use with under 1% overhead, capturing everything from GC and JIT activity to TLS handshakes, thread dumps, and custom application events with stack traces. It explains JFR's efficiency; thread-local buffering, reuse of data the JVM already collects, and a compact self-describing binary file format—plus its flexible filtering/throttling and configuration via .jfc files.

Thats all for this week friends! Thanks for reading this far. If you liked it please like and share with your network.

Share

Before you leave, don’t forget to unlock all the real world use case based interview questions , just at $4/mo (with annual subscription).

📢 If you have a product or services that you like to present in front of ~8000 Java and Spring Developers , considering sponsoring this newsletter.

Sponsorship Details

Happy Coding 🚀
Suraj

Subscribe | Sponsor us | LinkedIn | Twitter | Youtube

Read the original on javabulletin.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.