A deep dive into JUnit 6's three-pillar architecture: Platform, Jupiter, and Vintage. Learn how the TestEngine SPI, Launcher, and LauncherDiscoveryRequest work together, with code examples showing programmatic test execution and custom engine concepts.
A detailed, side-by-side comparison of JUnit 6 and JUnit 5 — architecture, annotations, parameterized tests, extension model, and records support — plus a practical migration guide updated for Spring Boot 4.0, which makes JUnit 6 the default testing baseline.
Learn how to structure your JUnit 6 test projects for scalability and long-term maintainability. Covers package layout, naming conventions, test base classes, test helpers, and real-world best practices used in production Java projects.
A comprehensive guide to configuring JUnit 6 with Maven and Gradle. Covers Surefire plugin, Failsafe plugin, multi-module projects, test filtering, IDE integration, and common configuration mistakes to avoid.
A step-by-step guide to installing JUnit 6, setting it up with Maven and Gradle, configuring your IDE, and writing your very first passing unit test. Includes complete code examples and expected output.
A complete, hands-on JUnit 6 tutorial covering everything from installation and first tests to advanced topics like parameterized tests, extensions, Spring Boot integration, parallel execution, and CI/CD pipelines. Perfect for beginners and experienced Java developers alike.
session.get() and session.getReference() look interchangeable at a glance, but the difference isn't "eager vs lazy" -- it's what you're telling Hibernate you need. This piece runs four calls against Hibernate 7.4.1.Final, builds the full same-session matrix, and pins down exactly where the proxy identity contract breaks -- including one same-session result that the usual L1-cache explanation gets wrong.
merge() and refresh() get described as opposite directions of the same tool -- one pushes, one pulls. Run them against a real @Version-ed entity and that framing misses the actual question: which one fails loudly when the state it's holding is stale? Three named experiments against Hibernate 7.4.1.Final, including a result that overturned the article's own original assumption.
Setting hibernate.jdbc.batch_size is not the same as verifying batching happens. Two nearly identical entities, one GenerationType difference, and Hibernate's own statistics show a 30-vs-4 prepared-statement gap -- then two sweeps (allocationSize, batch_size) run the numbers instead of predicting them, including one off-by-one that reproduced across two separate full-suite runs.
Are you tired of manually instantiating validators or dealing with NullPointerException when your custom constraint validators try to @Inject a service? In the world of modern Jakarta EE and MicroProfile applications, manual plumbing is a relic of the past. If you are moving to Hibernate Validator 7, understanding CDI bootstrapping is the key to building decoupled, testable, and robust validation layers. The Problem: The Manual Validation Headache Validation logic often needs access to external resources — database repositories, configuration services, or security contexts. When you use the standard Validation.buildDefaultValidatorFactory(), you are operating outside the CDI (Contexts and Dependency Injection) container. Your @Inject annotations within custom ConstraintValidator implementations simply won't work. They return null, forcing you into anti-patterns like static lookups or manual dependency passing that make your code brittle and nearly impossible to unit test. Imagine writing a @UniqueUsername constraint. You need your UserRepository to check the database. Without proper CDI bootstrapping, Hibernate Validator instantiates your validator class using simple reflection — bypassing the container's dependency graph entirely. You end up with a validation layer that is "deaf" to your application's ecosystem.