How do their APIs compare?

These two projects serve completely different purposes, so their APIs reflect very different design goals — one is a UI compositing widget for Android, the other is a high-performance concurrent messaging library for the JVM. Let me lay out what the retrieved data shows for each.

hugeterry/coordinatortablayout — declarative, fluent UI API

This is an Android custom view, so its "API" is a mix of XML configuration and a small fluent Java builder-style interface:

• XML usage: You declare CoordinatorTabLayout as a container in your layout XML wrapping a ViewPager with app:layout_behavior="@string/appbar_scrolling_view_behavior" [README.md:L25-L43].

• Java-side fluent setup: The main entry points are chainable methods called on the view instance:

  • setTitle(String title) — sets the collapsing header title
  • setImageArray(int[] imageArray) — sets per-tab background images
  • setImageArray(int[] imageArray, int[] colorArray) — same, plus a content scrim/color overlay
  • setupWithViewPager(ViewPager viewPager) — binds the tab layout to a ViewPager

  These are chained together, e.g. mCoordinatorTabLayout.setTitle("Demo").setImageArray(mImageArray).setupWithViewPager(mViewPager) as shown in the README usage example.

• There's also a small internal utility API, e.g. SystemView.getStatusBarHeight(Context) [coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/utils/SystemView.java:L9-L19], used internally for layout math rather than exposed as a primary public API.

This API surface is small, imperative/fluent, and tightly coupled to Android UI lifecycle (Activities, Views, ViewPager).

lmax-exchange/disruptor — low-level concurrency primitives API

Disruptor's API is structured around a set of composable interfaces and classes for building lock-free/low-latency producer-consumer pipelines:

• Sequencing/claiming: AbstractSequencer is the base for single/multi-producer sequencers, managing gating sequences and the ring cursor [src/main/java/com/lmax/disruptor/AbstractSequencer.java:L1-L27]. SequenceGroups provides static helpers for managing SequenceGroup objects [src/main/java/com/lmax/disruptor/SequenceGroups.java:L1-L24].
• Exception/error handling as part of the DSL: ExceptionHandlerSetting supports a builder-like API such as disruptorWizard.handleExceptionsIn(eventHandler).with(exceptionHandler) [src/main/java/com/lmax/disruptor/dsl/ExceptionHandlerSetting.java:L1-L29].
• Consumer wiring: ConsumerRepository is an internal DSL support class that associates EventHandlers with EventProcessors, exposing methods like add(...), startAll(ThreadFactory), haltAll(), hasBacklog(...), getEventProcessorFor(...), getBarrierFor(...) [src/main/java/com/lmax/disruptor/dsl/ConsumerRepository.java:L33-L129].
• Capacity/backpressure signaling: InsufficientCapacityException is thrown specifically by RingBuffer#tryNext() when a non-blocking claim would wrap consumers, and it deliberately omits a stack trace for performance [src/main/java/com/lmax/disruptor/InsufficientCapacityException.java:L1-L25].
• Lower-level array/ring-buffer access patterns (unsafe access, VarHandle, MethodHandle) even show up in benchmark code exploring alternative access strategies [src/jmh/java/com/lmax/disruptor/ArrayAccessBenchmark.java:L124-L163, src/jmh/java/com/lmax/disruptor/RingBufferBenchmark.java:L122-L161], illustrating how performance-sensitive the internal API design is.

Key contrasts