A complete, reference-level guide to the Java Streams API (Java 8+). Covers stream creation, intermediate operations (filter, map, flatMap, sorted, distinct, peek), terminal operations (collect, reduce, count, findAny, anyMatch), collectors, parallel streams, and the most common pitfalls u2014 with fully annotated code and sample output for every example.
How to deserialise one JSON shape into several Java subtypes with Jackson 3: @JsonTypeInfo and @JsonSubTypes, the list that silently loses its type label, sealed-class subtypes, unknown labels, and what changed in default typing and type validation. Every output is from a run.
@RestClientTest and MockRestServiceServer, rebuilt against Spring Boot 4.1.1: a RestClient-based client, a legacy RestTemplate client, a declarative HTTP interface client, and the error path -- plus three real, verified surprises: two packages that moved without warning, Jackson 3 resolving in place of Jackson 2 by default, and a genuine trap where identical mocking code works for RestTemplate and throws a real AssertionError for RestClient.
A beginner-first, fully verified guide to @DisplayName, DisplayNameGenerator, @Nested, and @Tag in JUnit — every code example and console transcript comes from a real Maven module built and run against JUnit 6.1.3, the current GA release verified against Maven Central. Covers what changed for these three annotations between JUnit 5 and JUnit 6, including a real behaviour change (deterministic @Nested ordering) that most migration guides mention only in passing.
Dozer is a battle-tested Java bean mapper that eliminates DTO-to-entity boilerplate using runtime reflection. This guide covers basic and nested mapping, custom converters, Spring integration, and a head-to-head benchmark vs MapStruct — so you can choose the right tool for your project.
JUnit's @RepeatedTest runs the same method N times, each with its own pass/fail result. Rebuilt here against real JUnit 6.1.3 on JDK 25: all four RepetitionInfo accessors (not just two), RepetitionInfo injected into @BeforeEach/@AfterEach, what failureThreshold actually does when it fires (skips, not stops), a real flaky-test detection demo, and a placeholder the original version of this post claimed existed but never did.
HashMap vs ConcurrentHashMap interview guide: internals, null-key/value handling, the computeIfAbsent recursion trap (verified on JDK 25), and real JMH throughput numbers up to 8 threads.
Whether you are preparing for a technical interview or exploring the fascinating world of number theory, encountering Pronic numbers is almost a rite of passage for Java developers. These numbers, often hidden in pattern-matching puzzles, have unique properties that make them a favorite for practicing algorithmic efficiency. In this guide, we will dive deep into what Pronic numbers are and demonstrate two distinct ways to identify them using Java—ranging from a beginner-friendly loop to a high-performance mathematical "trick." What is a Pronic Number? A Pronic number (also known as an oblong or rectangular number) is a number that is the product of two consecutive integers. Mathematically, a number P is pronic if it can be expressed as: P = n X (n + 1) For some integer n. Examples of Pronic Numbers: 0: 0 X 1 = 0 2: 1 X 2 = 2 6: 2 X 3 = 6 12: 3 X 4 = 12 20: 4 X 5 = 20
A Disarium number is a positive integer where the sum of its digits raised to their positional powers equals the number itself. Learn the algorithm and see a complete, well-commented Java program with sample output.
Imagine your application's log file as a constant stream of information. In a production crisis, this stream becomes a firehose. How do you find the single critical error message in a flood of routine status updates? The answer lies in logging levels. These aren't just labels; they are the fundamental control mechanism in Log4j2. They allow developers to filter noise, pinpoint failures, and monitor application health effectively. Mastering this hierarchy is the key to creating logs that are helpful, not overwhelming. This guide explores Log4j2’s levels, from configuration to real-world best practices. The Logging Threshold: How Levels Work Think of logging levels as a gatekeeper's volume knob. Each log message you write (an "event") is assigned a level of importance, or severity. The logger itself is then configured with a threshold level. When a message arrives, the framework compares its severity to the logger's threshold. Only messages at or above the configured threshold are processed and sent to their destination (like a file or the console). This simple mechanism provides fine-grained control over your application's verbosity. You can run the exact same code in different environments and get drastically different log outputs—all without changing a single line of Java. In development, you might set the threshold low to see everything. In production, you set it high to capture only significant errors.