How do their APIs compare?

API comparison: mybatis/mybatis-3 vs realm/realm-java

These two projects solve very different problems (SQL mapping vs. mobile object database), so their APIs are shaped around different paradigms.

mybatis-3: annotation- and XML-driven SQL mapping API

MyBatis exposes its API primarily as Java annotations placed on mapper interface methods, which map directly to SQL statements:

• @Select lets you attach raw SQL (optionally with dynamic SQL) to an interface method, e.g. @Select("SELECT id, name FROM users WHERE id = #{id}") on a method like User selectById(int id) [src/main/java/org/apache/ibatis/annotations/Select.java:L26-L40].
• @SelectProvider / @DeleteProvider (and analogous @InsertProvider, @UpdateProvider) let you delegate SQL generation to a separate provider class/method instead of inlining SQL as a string literal [src/main/java/org/apache/ibatis/annotations/SelectProvider.java:L26-L40] [src/main/java/org/apache/ibatis/annotations/DeleteProvider.java:L26-L40].
• @CacheNamespace configures a per-mapper-interface cache, defaulting to PerpetualCache/LruCache but pluggable via implementation and @Property name/value pairs [src/main/java/org/apache/ibatis/annotations/CacheNamespace.java:L23-L40].
• @Many (paired with @Result/@Results) declares nested-select mappings for collection-valued properties, supporting configurable columnPrefix and fetch strategy via FetchType [src/main/java/org/apache/ibatis/annotations/Many.java:L24-L40].

Underneath these annotations, the framework builds internal objects like SqlSource/StaticSqlSource, which hold a BoundSql plus ParameterMappings tied to a Configuration [src/main/java/org/apache/ibatis/builder/StaticSqlSource.java:L17-L27]. This is all part of the org.apache.ibatis.builder package, described simply as the "Base package for the Configuration building code" [src/main/java/org/apache/ibatis/builder/package-info.java:L16-L20]. So the public-facing API surface (annotations) is thin and declarative, while a builder layer resolves things like constructor argument matching for result mapping [src/main/java/org/apache/ibatis/builder/ResultMappingConstructorResolver.java:L200-L239].

Net effect: MyBatis's API is statement-centric — you annotate methods to bind them to SQL, and the framework's builders wire that into executable mappings at configuration time.

realm-java: fluent query builder / object-model API

Realm's API is centered on a fluent, chainable query builder over live objects rather than SQL strings:

• RealmQuery<T> extension functions like oneOf let you build "IN" style comparisons directly on typed queries, e.g. realmQuery.oneOf("propertyName", arrayOfValues, Case.SENSITIVE), which internally delegates to .in(...) [realm/kotlin-extensions/src/main/kotlin/io/realm/kotlin/RealmQueryExtensions.kt:L23-L40].
• Object mapping isn't done through interface-method annotations tied to SQL, but through model classes and field-level annotations like @RealmField, with naming policies (e.g., camelCase-to-underscore transforms) controlling how Java property names map to on-disk field names, independent of any JSON serialization annotations from libraries like Moshi/GSON [realm-annotations/src/main/java/io/realm/annotations/RealmNamingPolicy.java:L81-L120].
• Build/dependency-wiring APIs exist too, but at the tooling layer rather than query layer — e.g. SimpleAGPVersion for comparing Android Gradle Plugin versions [gradle-plugin/src/main/kotlin/io/realm/gradle/SimpleAGPVersion.kt:L18-L26], and Gradle plugin logic that configures dependency configurations (api vs. legacy compile) for consuming projects [gradle-plugin/src/main/kotlin/io/realm/gradle/Realm.kt:L103-L139].