Skip to content
Bluetape4k docs1.11

Marker selection

Latest stable Based on Bluetape4k release 1.11.0

Choosing by name alone tends to overload Experimental and Internal. Start with the unstable contract: can callers rely on the API, is the declaration public only for technical reasons, does safe use require specialized knowledge, or is only third-party implementation unstable?

Bluetape API marker selection map

Prefer internal or private when external code has no reason to access a declaration. A marker adds policy to a public declaration; it does not replace visibility. Consider a marker when inlining, framework integration, or another technical constraint requires public exposure.

MarkerDiagnosticUse whenCaller accepts
BluetapeExperimentalApiErrorThe contract may change or disappearNo source or binary compatibility guarantee
BluetapeBetaApiWarningStabilization is likely, with minor changes still possibleMinor source, binary, or behavior changes
BluetapeInternalApiErrorThe declaration is public only for technical reasonsIt is not supported external API
BluetapeDelicateApiWarningSafe use requires lifecycle, concurrency, resource, or security knowledgeThe documented contract and failure modes
BluetapeObsoleteApiErrorThe API remains only for migration or compatibilityNo new use and possible removal
BluetapeImplementationApiWarningCalling is stable but third-party implementation is notChanges to the implementation or subclassing contract

Experimental, Internal, and Obsolete block compilation without opt-in. Beta and Delicate emit warnings. Implementation applies when code implements or subclasses a type marked through @SubclassOptInRequired, not when it merely calls the type.

Use Experimental while removal or incompatible changes remain plausible. Use Beta after the direction is settled and only minor changes are expected. Do not choose Beta merely because a warning is more convenient than an error.

Internal says external use is unsupported. Delicate says external use is permitted after the caller understands a demanding contract. The current Kafka binary codecs use BluetapeDelicateApi to flag serialization and type-safety boundaries.

Obsolete is an opt-in policy. Kotlin @Deprecated supplies a replacement and migration message to IDEs. They solve different problems and may be combined when an API needs both a hard usage boundary and a migration path.

One marker usually communicates the owning contract best. Multiple markers can obscure what the caller is accepting. Combine them only when independent contracts genuinely overlap, and explain each contract separately in KDoc.