Graphitron is built on two foundational dependencies. They’re not incidental implementation choices; they shape the architecture and your experience working with Graphitron.

jOOQ

jOOQ generates type-safe Java code from your database schema and provides a fluent API for building SQL queries. It has been actively maintained since 2009, stays close to SQL rather than hiding it, and produces readable, debuggable code.

jOOQ is where you work. When you need custom logic (filtering, calculated fields, complex conditions) you write it using jOOQ’s DSL. You’ll work with generated table classes, write Condition methods, and think in jOOQ’s terms. Familiarity with jOOQ is essential for extending what Graphitron generates.

Licensing: jOOQ uses dual licensing. The open source edition covers PostgreSQL, MySQL, SQLite, and others. Commercial databases require a commercial license. We use the commercial license, which includes source rights: if jOOQ’s maintainers disappeared, we could continue.

GraphQL-Java

GraphQL-Java is the reference implementation of GraphQL for Java. It parses schemas, executes queries, and provides the DataFetcher and TypeResolver interfaces that Graphitron’s generated code plugs into.

GraphQL-Java is under the hood. You won’t typically write GraphQL-Java code directly: Graphitron handles that. But understanding how it executes queries helps when reading generated code or debugging.

Staying current

Graphitron tracks the current jOOQ and GraphQL-Java lines, and we recommend you do too. Staying current keeps you on upstream fixes and improvements, and it keeps each upgrade small: the longer a subgraph sits on an old line, the larger the eventual jump.

To make that the default rather than something you have to remember, the build says so. When your project resolves a jOOQ or GraphQL-Java version a minor line behind the one Graphitron itself is built against, the build emits a warning naming your version, the current one, and the coordinate to bump. Patch-level lag within the current minor is silent, because one patch behind is materially current and saying so on every build would be noise.

Every jOOQ edition counts, not just the open source one: the commercial and trial distributions ship the same release line under their own group ids (org.jooq.pro, org.jooq.pro-java-<n>, org.jooq.trial), and the warning names the coordinate your build actually resolved, so a commercial subgraph is never told to bump its way onto the open source edition. If you somehow resolve two editions at once, the warning speaks about the lower line, since that is the one holding you back.

It is a nudge, not a compatibility gate. Nothing here fails a build, and there is no minimum supported version: the compiler is the bar, so if the generated code compiles against your versions, you are fine. If you are held on an older line deliberately, silence the warning by rule id like any other, jooq-version-lag or graphql-java-version-lag under <lint><disabledRules>. The two are separate rules so you can accept one and keep the other.