AI Unified Process plugin for the Vaadin/jOOQ stack
97
93%
Does it follow best practices?
Impact
98%
1.30xAverage score across 10 eval scenarios
Passed
No known issues
Implement the use case $ARGUMENTS using Vaadin for the UI layer and jOOQ for data access.
Don't create tests – there are the karibu-test and playwright-test skills for that.
If the Vaadin and jOOQ MCP servers are configured, check them for guidance; otherwise rely on your own knowledge and the documentation links below.
fetchInto(SomeDto.class) for projected queries — use Records.mapping(SomeDto::new) insteaddocs/use_cases/docs/entity_model.mdWhen a query projects columns into a DTO, Java record, or any immutable class,
map the result with org.jooq.Records.mapping(...) and a constructor reference.
Do not use fetchInto(Dto.class) — it uses reflection and is not checked
against the projection at compile time.
import org.jooq.Records;
// List
List<PersonDto> persons = ctx
.select(PERSON.ID, PERSON.FIRST_NAME, PERSON.LAST_NAME, PERSON.EMAIL)
.from(PERSON)
.fetch(Records.mapping(PersonDto::new));
// Single (optional) row
Optional<PersonDto> person = ctx
.select(PERSON.ID, PERSON.FIRST_NAME, PERSON.LAST_NAME, PERSON.EMAIL)
.from(PERSON)
.where(PERSON.ID.eq(id))
.fetchOptional(Records.mapping(PersonDto::new));
// Stream
try (Stream<PersonDto> stream = ctx
.select(PERSON.ID, PERSON.FIRST_NAME, PERSON.LAST_NAME, PERSON.EMAIL)
.from(PERSON)
.fetchStream()
.map(Records.mapping(PersonDto::new))) {
...
}The order of the projected columns must match the constructor parameter order of the target type — the compiler will enforce this.
Exception: when fetching a generated table record without projection
(ctx.selectFrom(PERSON).fetchInto(Person.class) using the generator-produced
POJO), the generated into mapper is fine.
https://mcp.vaadin.com/docs)https://jooq-mcp.martinelli.ch/mcp)https://www.javadocs.dev/mcp)