Skip to main content

Envelope — what Java code fits on Fiji

The envelope is the positive boundary of a Fiji release: the catalogue of Java capabilities and host environments that fit inside the runtime, organized by category and classified by support level.

The authoritative envelope ships with every release tarball at envelope-0.4.md, and lives in source at doctrine/envelope-0.4.md. This page summarizes what it is and how to use it.

Two boundaries, both shipped with every release​

A Fiji release ships two complementary boundaries:

  • Negative boundary — Constraints: what does not fit. Workloads that depend on those capabilities fail at the boundary.
  • Positive boundary — the envelope (this page): what does fit, by category, with evidence.

Every release tarball includes both. Together they answer the question "can I bring this Java workload to Fiji?" without needing to talk to the project.

How to read the envelope​

The envelope organizes capabilities into twelve sections — execution hosts, Java language and core APIs, networking, file I/O, encryption, process and system, component composition, validated frameworks and applications, known limitations, JVM implementation status, operational characteristics, and a reading guide.

Each row carries one of three classifications:

SymbolMeaning
✓Supported. Empirical evidence (workload runs, test passes, or release smoke) backs this row.
△Partial. The capability exists but with caveats — limited scope, specific subset, or known edge cases. Rows note the boundary.
✗Not supported. The capability is outside the release envelope. Workloads that depend on it fail at the boundary.

Each row cites the empirical evidence that backs its classification — a closure spec, a witness workload, or a release smoke. Classifications without evidence do not get a ✓.

How to use the envelope​

Before adopting Fiji. Read the envelope to self-classify your workload. If the capabilities you need are ✓, the release supports them today. If they're △, read the row notes for the specific boundary. If they're ✗, the workload is outside the release envelope.

When filing a bug. The envelope helps triage. If your workload exercises a ✓ row and fails, that's a regression. If it exercises a △ row outside the documented sub-boundary, that's an envelope ambiguity. If it exercises a ✗ row, that's outside the release envelope — not a regression.

When evaluating benchmarks. Workloads that exercise ✓ surfaces are representative of what the release supports. Workloads that exercise △ or ✗ surfaces are aspirational — they tell you about future trajectory, not current state.

Envelope expansion versus hardening​

The envelope evolves between releases through two distinct motions:

  • Expansion — adding new ✓ rows. New capabilities, new validated frameworks, new host environments. The envelope grows outward.
  • Hardening — converting △ rows to ✓ as additional witness workloads land. The envelope grows more confident in capabilities it already articulates.

Both are public release events visible in the envelope diff between versions.

See also​