How do their APIs compare?

API Comparison: baseadapter vs disruptor

These two libraries serve completely different purposes and domains, so their APIs are shaped very differently — one is an Android UI convenience wrapper, the other a low-level concurrent data-structure library.

hongyangandroid/baseadapter — declarative, inheritance-based UI binding API

The API is designed to minimize boilerplate for Android list/grid rendering. Its core pattern is template method + delegation:

• CommonAdapter<T>: you subclass it and override convert(ViewHolder holder, T item) to bind data to views — no manual ViewHolder pattern needed, as shown in the README's single-item-type example.
• ViewHolder: exposes helper setters like setText(id, text) and setOnClickListener(id, listener), plus getView(id) for arbitrary widget access [README.md:L36-L45].
• Multi-view-type support via MultiItemTypeAdapter + ItemViewDelegate<T> interface, where each item type gets its own delegate implementing getItemViewLayoutId(), isForViewType(item, position), and convert(...) [README.md:L52-L75]. This is managed internally by ItemViewDelegateManager, which iterates delegates in reverse order to find a match and throws IllegalArgumentException if none matches the position [base-adapter-library/.../ItemViewDelegateManager.java:L91-L130].
• Decorator-style wrappers: HeaderAndFooterWrapper wraps an existing adapter to add header/footer views without modifying the adapter itself — explicitly described as similar to the decorator pattern.

The API surface is small, synchronous, and single-threaded (Android main thread UI binding) — there's no concurrency concern here.

lmax-exchange/disruptor — low-level, interface-driven concurrency API

Disruptor's API is built around composable interfaces and abstract base classes for a lock-free ring buffer:

• DataProvider<T>: a minimal decoupling interface, "typically used to decouple classes from RingBuffer to allow easier testing" [src/main/java/com/lmax/disruptor/DataProvider.java:L16-L20].
• EventProcessor: a Runnable-like interface representing a thread that polls the RingBuffer via a wait strategy; the docs note you're unlikely to implement it directly, preferring EventHandler + the pre-built BatchEventProcessor [src/main/java/com/lmax/disruptor/EventProcessor.java:L17-L23].
• AbstractSequencer: base class shared by single/multi-producer sequencers, managing gating sequences and cursor ownership [src/main/java/com/lmax/disruptor/AbstractSequencer.java:L22-L26].
• SequenceGroups: static helper methods for managing SequenceGroup objects, using AtomicReferenceFieldUpdater for lock-free updates [src/main/java/com/lmax/disruptor/SequenceGroups.java:L16-L23].
• DSL layer: ExceptionHandlerSetting supports a fluent API like disruptorWizard.handleExceptionsIn(eventHandler).with(exceptionHandler) for per-handler exception configuration [src/main/java/com/lmax/disruptor/dsl/ExceptionHandlerSetting.java:L23-L26].

This API is deliberately layered: low-level interfaces (DataProvider, EventProcessor, Sequence-related classes) for performance-critical direct use, and a higher-level DSL for ergonomic wiring of handler chains.

Key contrasts

Aspect	baseadapter	disruptor
Domain	Android UI list rendering	High-throughput concurrent messaging
Extension model	Subclass + override (convert)	Interface implementation (EventHandler, DataProvider)
Composition	Decorator wrapping (HeaderAndFooterWrapper)	Sequencer/gating composition (AbstractSequencer, SequenceGroups)
Concurrency	None (single-threaded UI)	Central concern (atomics, sequence gating, wait strategies)
Convenience layer	ViewHolder hel