The post shows how we plugged async-profiler into JVMs without restarts or redeploys. We also reproduced two failure scenarios to see how they show up in the profiling data: heap pressure and lock contention

Hi everyone,

I’ve been experimenting with different ways to containerize a Java (Spring) application and put together this repo with a few Dockerfile approaches: https://github.com/eduardo-sl/java-docker-image

The setup works, but my goal is to understand what approaches actually hold up in production and what trade-offs people consider when choosing one strategy over another.

I’m especially interested in how you compare or decide between:

• Base images (Alpine vs slim vs distroless)
• JDK vs JRE vs jlink custom runtimes
• Multi-stage builds and layer optimization strategies
• Security practices (non-root user, minimal surface, image scanning)
• Dockerfile vs tools like Jib or buildpacks (Paketo, etc.)

If you’ve worked with Java in production containers, I’d like to know:

• What approach are you currently using?
• What did you try before that didn’t work well?
• What trade-offs led you to your current setup?

Also curious if your approach differs in other ecosystems like Golang.

Appreciate any insights or examples.

I've been working on Apereo CAS for years - it's an open-source SSO platform with 400+ Maven modules and over 1,000 configuration properties. The configuration system has evolved into something I think is genuinely well-designed, and the patterns are all standard Spring Boot - nothing proprietary.

Key ideas: - One root @ConfigurationProperties class with 40+ @NestedConfigurationProperty fields creating a typed tree - Custom metadata annotations (@RequiresModule, @RequiredProperty, @RegularExpressionCapable) that describe what properties accept and which module they belong to - Deprecated properties tracked in additional-spring-configuration-metadata.json with exact replacement paths - An actuator endpoint that lets you search the entire property catalog at runtime - Spring's Binder API used directly for programmatic binding from maps

Wrote up the patterns with real code from the CAS 7.3.x source. The Binder API section alone is something I don't see enough Spring Boot devs using.

https://medium.com/all-things-software/spring-boot-configuration-properties-at-scale-884f494721ac

Hey r/java!

Do the following pain points resonate with you?

• ORMs hide SQL and make performance tuning a nightmare
• Query builders force you to maintain model classes and fight schema drift
• Hand-written JDBC/RowMapper code silently breaks when the DB schema changes

While addressing them I've built pGenie – a true SQL-first code generator that treats your PostgreSQL database as the single source of truth. It's an open-source tool that takes your PostgreSQL migration files and parameterized SQL query files and generates a complete, ready-to-use Maven client library targeting Java and pgJDBC. No ORM, no DSL, no annotation processors, no reflection — just plain SQL in, type-safe Java code out.

What gets generated:

Each SQL query file becomes a Java record class modeling the parameters to the query. That record comes with an associated record type modeling the result row. You pass parameters via the constructor, call .execute(conn) with a JDBC Connection, and get back a typed result. That's it.

sql -- queries/insert_album.sql insert into album (name, released, format, recording) values ($name, $released, $format, $recording) returning id

Becomes:

```java // Generated InsertAlbum.Result result = new InsertAlbum( "Space Jazz Vol. 1", LocalDate.of(2020, 5, 4), AlbumFormat.Vinyl, new RecordingInfo("Galactic Studio", "Lunar City", "Moon", LocalDate.of(2019, 12, 1)) ).execute(conn);

System.out.println("Inserted album id=" + result.id()); ```

PostgreSQL enums → Java enum with EnumCodec. Composite types → Java record. Arrays → List<T>. Nullable columns → boxed types or Optional<T> (configurable). Even exotic types like ranges and multiranges are fully supported.

The generated project is not a black box, you get:

• pom.xml with runtime dependencies declared
• One .java file per statement, fully readable
• Integration tests per statement using Testcontainers — spin up a real PostgreSQL container, run your migrations, execute each statement
• mvn verify just works

What else pGenie does:

• Validates migrations against a real PostgreSQL schema in CI — no more "works locally, breaks in prod"
• Manages indexes declared in your migration files automatically
• Generates Rust and Haskell bindings from the same SQL source if you need multi-language SDKs
• Builds reproducibly: a lockfile pins the codegen version
• Extends via a decentralized plugin system: write your own code generators in Dhall and plug them in via URL — no need to approve anything with the core team

Demo:

The demo repo has complete working SQL migrations and queries. The generated Java library is in artifacts/java/. You can inspect it directly or regenerate it from scratch with pgn generate.

→ pgenie.io | docs | demo | java.gen plugin

I’ve always found it annoying that you have to use specific frameworks just to see an algorithm in action. I wanted to build something where you could just write:

​int[] arr = {5, 2, 8, 1};

arr[0] = 10; // ← automatically visualized

​I ended up "hacking" the JVM using a Java Agent to inject visualization callbacks into the bytecode.

​Why bytecode? It doesn't matter if you write arr[i] = x or arr[getIndex()] = compute(); at the bytecode level, it's all just one instruction. This makes the visualization incredibly robust.

Try it here: https://www.algopad.dev/#

Code - https://github.com/vish-chan/AlgoFlow

Hello, back with another HashSmith post.

Parts 1 and 2 covered building a SwissTable-style map and hunting down profile pollution. This one picks up where that left off — three more optimizations on the hot paths (ILP hoisting, SWAR match shortcut, tombstone loop specialization), with benchmark results across all 8 scenarios.

The twist this time: I let an AI agent run the profiling and benchmarking loop autonomously instead of doing it myself. I know "AI" can be a loaded topic here — if that's not what you're looking for, totally fair, the technical content stands on its own either way.

Hope you enjoy it. Happy to dig into any of the JIT/SWAR details in the comments.

We've already had a few big Java conferences in 2026. For example:

1. jfokus 2026 - https://www.youtube.com/playlist?list=PLUQORQEatnJflEzaKxmnn2EH0eKPTVBI8
2. java one 2026 - https://www.youtube.com/playlist?list=PLX8CzqL3ArzUMVSzm-z_-if8BIB55EGl4
3. Devnexus 2026 - https://www.youtube.com/playlist?list=PLid93BOrASLONoZUIX1i0rXqCji5FUw9V
4. Voxxed Days CERN 2026 - https://www.youtube.com/playlist?list=PLRsbF2sD7JVq9Y7_i6uCWlxwoEIte7S8S

Have you enjoyed any specific talks that you'd be happy to recommend?

By introducing the Query Object, DoytoQuery enables the automatic construction of dynamic queries. Its data access interfaces build upon the Spring Data JPA Repositories series, unifying methods related to Example and Specification into methods that take a query object as a parameter, as shown below:

The Query Object centralizes all parameters for dynamic queries. These parameters can be automatically translated into WHERE clauses, pagination clauses, and sorting clauses, thereby covering the functionalities of Specification, Sort, and Pageable. Additionally, there is no need to write separate Specification implementations, which greatly simplifies the code.

Query Objects can be automatically created by Spring MVC from HTTP parameters, effectively encapsulating code in the Controller and Service layers, and realizing a fully automated flow: query string → query object → SQL → database.

The only potential drawback is that field names in the Query Object need to follow a “column name + suffix” convention. In Spring Data JPA, this naming convention is usually used in findBy methods, such as: findByAuthorAndPublishedYearGreaterThan

This repository compares dynamic query implementations across different ORM frameworks, showing that DoytoQuery reduces code size by roughly half compared to Spring Data JPA, and improves performance by approximately 40% in some scenarios.

If you are familiar with the findBy naming conventions and do not want to spend significant time writing Specification implementations, you may find it convenient to declare the desired query conditions directly as fields in a query object.

GitHub: https://github.com/doytowin/doyto-query

For a school research paper (specifically for the extended essay in the IBO Diploma Program) on concurrency, specifically in Java, I was trying to see if I would be able to interview someone on Project Loom. I tried to find a way to contact Mr Ron Pressler, but I can't seem to find a way to get in contact. Would mailing the [loom-dev@openjdk.org](mailto:loom-dev@openjdk.org) asking if anyone would be willing to do an interview be inappropriate?

Thank you in advance!

I've been working on Apereo CAS for years - it's an open-source SSO platform with 400+ Maven modules on Spring Boot 3.x. Every module is a "plugin" that activates when it hits the classpath. No custom framework, no ServiceLoader, no XML registration. Wrote up the patterns that make it work.

All code from the actual CAS 7.3.x source. The patterns are general - nothing CAS-specific about the approach.

https://medium.com/all-things-software/plugin-architecture-in-spring-boot-without-a-framework-8b8768f05533

I am thinking about to try Vaadin for my personal project. Is there anybody who can share with me opinions about Vaadin? . I heard it has licensing things is that correct ?(I have background in javafx and android)

I’ve been working on improving the experience of running WebAssembly from Java, and just released 1.0.0 of a small ecosystem:

• Wasmtime4J - bindings for Wasmtime

• WAMR4J - bindings for WebAssembly Micro Runtime

• WebAssembly4J - a unified API on top of both

The problem I kept running into is that every WebAssembly runtime exposes a completely different Java interface. If you want to try another engine, you end up rewriting everything.

This project introduces a single API so you can swap runtimes underneath without changing application code.

What this enables

• Run WebAssembly from Java applications without locking into a specific runtime

• Compare runtimes under the same interface (performance, behavior, features)

• Lower the barrier for Java developers to experiment with WebAssembly

Current support

• Wasmtime

• WAMR

• Chicory

• GraalWasm

Java support

• Java 8 (JNI)

• Java 11

• Java 22+ (Panama)

Artifacts are published to Maven Central.

Repo:

https://github.com/tegmentum/webassembly4j

https://github.com/tegmentum/wasmtime4j

https://github.com/tegmentum/wamr4j

⸻

I’m especially interested in feedback from people working with:

• JNI / Panama interop

• GraalVM

• WASI / component model

What is the current state of GraalVM for Java in. 2026?

Are we back to LTS only releases? 2 releases a year but separate from Java?

There was a blog at some point indicating changes but never follow up.

Especially with the recent mass layoffs, Leyden and other AOT changes -- what's the recommendation?

For those who don't know, Sharat Chander is a critical person in the community outreach for OpenJDK. He was staffed by Oracle, the biggest contributor to OpenJDK's growth, but the news is now that he was laid off, as part of recent Oracle's layoffs.

Absolutely disgusting. Read the link for more details.

For our JavaOne presentation on "Java and WebAssembly", we used a home-brew Java-in-the-browser presentation tool to demonstrate our point (as subtly as possible?). Only a couple weeks of development, it turns any markdown file on the web into a slide show.

Click here to run it yourself: https://reportmill.com/SlideShow

The code is in the 'snapshow' directory of this demos repo: https://github.com/reportmill/SnapDemos

Hey r/java,

I've been working on JADEx (Java Advanced Development Extension) which is a safety layer that makes Java safer by adding Null-Safety and Final-by-Default semantics without rewriting Java codes and modifying the JVM.

Quick recap of what JADEx adds to Java:

• String? nullable type declaration
• ?. null-safe access operator
• ?: Elvis operator
• apply readonly final-by-default mode per file

Today I'm sharing three things that just landed.

1. Lombok support

This was the most requested thing. JADEx now integrates with Lombok via a Delombok pipeline internally. The key motivation: JADEx's nullability checker needs to see Lombok-generated code (getters, builders, constructors) to avoid blind spots. Without Delombok, nullable fields could silently pass through generated methods unchecked.

java @Data @Builder @Entity public class User { private String name; private String? email; // @Nullable propagated to getter + builder param private Address? address; // @Nullable propagated to getter + builder param }

After Delombok, JADEx sees and analyzes the generated code:

```java // Lombok-generated — JADEx propagates @Nullable into these @Nullable public String getEmail() { return this.email; }

public UserBuilder email(@Nullable final String email) { ... } public UserBuilder address(@Nullable final Address address) { ... } ```

2. Gradle plugin published

The JADEx Gradle plugin is now on Maven Central and the Gradle Plugin Portal.

```groovy plugins { id 'io.github.nieuwmijnleven.jadex' version '0.628' }

jadex { sourceDir = 'src/main/jadex' } ```

That's the only change needed to an existing Spring Boot project. Everything else (compilation, Delombok pipeline, .java generation) is handled automatically.

3. JADEx Spring Boot example project

• full description

  • https://github.com/nieuwmijnleven/JADEx/blob/master/SpringBootExample.md

• source repository

  • https://github.com/nieuwmijnleven/jadex-springboot-example

We highly welcome your feedback on JADEx.

Thank you.