How do their APIs compare?

These two libraries solve fundamentally different problems, so their APIs are shaped very differently — one is a resource-pool configuration API, the other is an ORM/query and object-model API.

HikariCP (brettwooldridge/hikaricp): a small, imperative configuration + DataSource API

• The central object is HikariConfig, a plain JavaBean-style configuration holder with a large set of setXxx()/getXxx() methods (e.g. setJdbcUrl, setUsername, setPassword, setMaximumPoolSize, setMinimumIdle) as shown in the README initialization example [README.md:L447-L502] and in the HikariConfig field/constructor definitions [src/main/java/com/zaxxer/hikari/HikariConfig.java:L45-L84].
• Config can be built three ways: programmatically via setters, from a .properties file path passed to the constructor, or from a java.util.Properties object — all shown side-by-side in the README [README.md:L447-L502].
• A subset of properties (pool size, timeouts, credentials) remain mutable at runtime through HikariConfigMXBean, e.g. setMaximumPoolSize, setPassword, setUsername, setCredentials [src/main/java/com/zaxxer/hikari/HikariConfigMXBean.java:L146-L185]. Once the pool starts, the config object is "sealed" and further changes throw IllegalStateException, forcing you through the MXBean for live changes [src/main/java/com/zaxxer/hikari/HikariConfig.java:L1125-L1164 region, checkIfSealed()].
• The actual pool is HikariDataSource, a standard javax.sql.DataSource, so consumption is idiomatic JDBC: ds.getConnection() returns a normal java.sql.Connection [src/test/java/com/zaxxer/hikari/metrics/prometheus/HikariCPCollectorTest.java:L119-L158].
• Extensibility points are narrow and interface-based, e.g. HikariCredentialsProvider for dynamic credential retrieval [src/main/java/com/zaxxer/hikari/HikariCredentialsProvider.java:L1-25], and IMetricsTracker/MetricsTrackerFactory for plugging in metrics backends like Prometheus.
• Overall the API surface is deliberately minimal — the README explicitly frames this as a "zero-overhead" design where "every property is optional except the essentials" [README.md:L133-L172].

Realm Java (realm/realm-java): a richer, annotation-driven ORM/query API

• Object models are plain Java classes annotated with things like @LinkingObjects to declare inverse relationships, which are resolved by an annotation processor at compile time [realm-annotations/src/main/java/io/realm/annotations/LinkingObjects.java:L71-L110].
• Naming/schema mapping is also annotation-controlled via @RealmClass(fieldNamingPolicy = ...) and RealmNamingPolicy, letting you decouple Java field names from the on-disk schema [realm-annotations/src/main/java/io/realm/annotations/RealmNamingPolicy.java:L41-L80].
• Querying is done through a fluent, chainable RealmQuery<T> builder, e.g. equalTo(fieldName, value, caseSensitive) [CONTRIBUTING.md:L153-L196, documenting the Javadoc conventions for exactly this kind of method], and Kotlin extension functions layer idiomatic sugar on top, such as oneOf(...) which delegates to RealmQuery.in(...) [realm/kotlin-extensions/src/main/kotlin/io/realm/kotlin/RealmQueryExtensions.kt:L1-40].
• The API is intentionally verbose/self-documenting: Realm's own contribution guidelines mandate full Javadoc on every public class/method, with strict conventions (verb-first descriptions, {@link} cross-references, exception documentation, 120-char line limits) [CONTRIBUTING.md:L153-L196], reflecting a much larger, more object/query-oriented public surface than HikariCP's flat setter-based config.

Summary of the contrast

• HikariCP: one main config bean + one DataSource implementation, small sur