How do their APIs compare?

Since these two repos are fundamentally different kinds of libraries (a media playback framework vs. a GraphQL execution engine), their APIs compare more in style and philosophy than in surface area. Here's a breakdown based on what's visible in the retrieved code:

google/exoplayer: component/factory-oriented, Android-integrated API

• Factory pattern for pluggable components. ExoPlayer's API leans heavily on DataSource.Factory abstractions that applications inject. For example, CronetDataSource.Factory can be wrapped into DefaultDataSource.Factory as baseDataSourceFactory to support both HTTP(S) and local file playback [extensions/cronet/README.md:L31-L47].
• Deep Android platform coupling. Its API surfaces (ExoPlayer, Player, MediaItem, Timeline.Window, AnalyticsListener) are all designed around Android app lifecycles, as seen in test usage pulling in androidx.media2.session.MediaSession, MediaController, etc. [extensions/media2/src/androidTest/java/.../SessionCallbackBuilderTest.java:L15-L57].
• Extension modules as isolated units. Each codec/network extension (Cronet, Flac, AV1, IMA) exposes a small Library-style class (e.g., FlacLibrary, Gav1Library) that just configures/queries an underlying native library via LibraryLoader [extensions/flac/src/main/java/.../FlacLibrary.java:L16-L29] [extensions/av1/src/main/java/.../Gav1Library.java:L16-L29]. This is a narrow, utility-style API rather than a rich object model.
• Deprecated status affects API stability. Every public class carries a @Deprecated annotation and Javadoc pointing to AndroidX Media3 as the migration target [extensions/flac/src/main/java/.../FlacLibrary.java:L21-L28], meaning the ExoPlayer API itself is frozen and not evolving — RepoPilot's computed signals confirm this with a "Slowing" verdict and last commit 9 months ago, plus a low OpenSSF score (3.1/10) reflecting no active CI/SAST/dependency tooling.

graphql-java/graphql-java: builder-pattern, spec-driven API

• Fluent builder APIs are the norm. GraphQLScalarType.newScalar()...build() is used to define built-in scalars like GraphQLInt, GraphQLFloat, GraphQLBoolean, GraphQLID [src/main/java/graphql/Scalars.java:L22-L58], and QueryTraverser.Builder exposes chained methods like .coercedVariables(...), .root(...), .rootParentType(...) [src/main/java/graphql/analysis/QueryTraverser.java:L285-L324].
• Interface-driven, spec-anchored contracts. ExecutionResult is a plain interface (getErrors(), getData(), isDataPresent(), getExtensions()) with Javadoc directly citing the GraphQL specification section on the "data" entry [src/main/java/graphql/ExecutionResult.java:L18-L57]. This tight coupling to the spec (rather than a platform like Android) is characteristic of graphql-java's API design.
• Context object for cross-cutting concerns. GraphQLContext is a thread-safe, mutable key-value store injected into DataFetchingEnvironment, letting DataFetcher implementations read arbitrary contextual values (e.g., current user) [src/main/java/graphql/GraphQLContext.java:L20-L45].
• Actively evolving with modern Java tooling. Use of @NullMarked/@Nullable from org.jspecify.annotations in GraphQLContext.java [src/main/java/graphql/GraphQLContext.java:L2-L4, L45] shows ongoing modernization, contrasting with ExoPlayer's frozen, deprecated state.

Key contrasts