Skip to main content

Compatibility Strategy

Kanvas does not define compatibility as "the application compiled."

There are several independent compatibility layers:

Gradle API compatibility
        │
JDK / Java-agent compatibility
        │
Compose + Skiko bytecode compatibility
        │
JNI/native ABI compatibility
        │
OS + graphics backend compatibility
        │
GPU/driver behavior

A project can pass one layer and fail another.

Do not collapse these layers

"Works on my machine," "the plugin applied," "the transform matched," and "the GPU backend presented correctly" are different claims. Kanvas documentation and diagnostics keep them separate on purpose.

Why kanvasCompatibility is informational​

The compatibility task reports the Compose/Skiko runtime artifacts associated with the selected run task.

It intentionally does not claim that a version is fully renderer-compatible simply because its JAR name matches a known line.

Version detection is not bytecode verification

Kanvas instruments implementation details. Two artifacts with similar version numbers can still differ in class layout or method signatures.

That is why the transformers validate the actual target methods they need and emit explicit transform failures when those methods are absent.

Source:

Why compatibility is reported in layers​

A renderer that works on one macOS/Metal machine does not automatically establish:

  • Windows Vulkan correctness
  • Windows D3D9 correctness
  • Linux Vulkan correctness
  • another GPU vendor's behavior
  • another Compose/Skiko ABI line
Verification vocabulary

Kanvas deliberately distinguishes implementation exists, runtime shape recognized, and real hardware verified. Those labels describe different levels of evidence.