Java (Java 26)

Analysis against Java 26 (March 2026). Earlier Java releases carry more of the mechanisms below; modern Java (17+) dramatically improves the coupling profile.

This assessment applies the coupling account — coupling as access to a shared resource, and the coupling floor [1], [2] — and the knowledge-embodiment theorem [3]; the language is assessed against its official reference [4].

1 Assessment

This page assesses Java in five parts: core coupling — what the language’s own constructs force; ecosystem coupling — what the surrounding platform, tooling, and community cost; engineering readiness — whether the artifact can be reproduced, verified, observed, worked in quickly, connected to other languages, and governed openly; the profile — the unscored facts a score cannot express; and the scoring detail — the mechanism marks and the arithmetic behind every score. A ✅ bullet marks a construct that helps. A ⚠️ or ❌ bullet marks a cost; the scoring model does not price every cost named here.

Core coupling 50/100 · Ecosystem coupling 61/100 · Engineering readiness 85/100

1.1 Core coupling

1.1.1 Type

  • ✅ Interfaces decouple specification from implementation: Can program to interfaces
  • ✅ Generics enable type parameterization: List<T> decouples from concrete types
  • ✅ Sealed classes (Java 17): Controlled inheritance hierarchies — the class author decides which subclasses exist, decoupling from unknown extensions
  • ✅ Records (Java 16): Immutable data carriers with auto-generated equals/hashCode/toString — construction decoupled from mutation
  • ✅ Pattern matching (Java 21): switch expressions + sealed types enable exhaustive, compositional dispatch
  • ❌ No higher-kinded types: Can’t abstract over generic types
  • ⚠️ Type erasure couples generics: Runtime loses type information
  • ⚠️ Inheritance still available: Unchecked class extension possible (unless final or sealed)
  • ❌ Null still exists: NullPointerException possible (no non-nullable types in the language)
  • ⚠️ Module system (Java 9+) limits reflection: Strong encapsulation of non-exported packages became the default in Java 16, so reflective access to them now needs an explicit --add-opens — reflection is no longer a free-for-all
  • ❌ Package-private couples to package structure: Visibility tied to organization

1.1.2 Construction

  • ✅ Records are immutable by default: record Point(int x, int y) — no mutation coupling, auto-generated components
  • ✅ Immutable collections (Java 9+): List.of(), Set.of(), Map.of() produce unmodifiable collections
  • ✅ Copy-with-change without mutation: Records have no withers or copy constructors, so a copy-with-change is a hand-written call that supplies the new value and copies the rest
  • ✅ Dependency injection frameworks: Spring/Guice decouple construction from usage
  • ⚠️ Records eliminate builders for simple cases: Complex multi-step construction may still need builders
  • ⚠️ Constructors couple creation to initialization: Not eliminated, but records and patterns reduce the problem
  • ❌ Static methods couple to global state: Singleton pattern creates hidden dependencies

1.1.3 Memory

  • ✅ JVM GC decouples memory: Modern GCs (ZGC, Generational ZGC, Shenandoah) provide sub-millisecond pause times
  • ✅ No manual memory management: Can’t have dangling pointers
  • ✅ Foreign Function & Memory API (Java 22): Safe memory access without JNI, decoupling native interop from unsafety
  • ✅ AOT object caching with any GC (Java 26): Ahead-of-time object caching reduces startup time and memory pressure regardless of GC choice
  • ⚠️ GC pauses affect latency: Minimized by modern GCs but not deterministic
  • ❌ Memory leaks from static references: Static collections couple to application lifetime (still possible)

1.1.4 Error

  • ✅ Checked exceptions separate error paths: throws IOException makes errors explicit
  • ✅ Pattern matching for switch + sealed types (Java 21): Exhaustive error handling — compiler verifies all error cases covered
  • ✅ Primitive types in patterns (preview, Java 26): Extends pattern matching to primitive types, enabling exhaustive switching over numeric domains
  • ❌ Try-catch doesn’t compose: Can’t map/flatMap over exceptions without wrapping
  • ⚠️ RuntimeException bypasses checks: Unchecked exceptions defer error-coupling detection to runtime (sealed hierarchies with pattern matching help)

1.1.5 Concurrency

  • ✅ Virtual threads (stable, Java 21+): Lightweight threads — each task gets its own thread, eliminating callback coupling
  • ✅ Structured concurrency (preview, Java 21+): StructuredTaskScope — subtask lifetimes scoped to lexical block, preventing thread leaks
  • ✅ Scoped values (final, Java 25+): Thread-local data with guaranteed cleanup, decoupling context from global state
  • ✅ CompletableFuture: Composable async primitives when needed
  • ⚠️ Shared mutable state still possible: synchronized, volatile, and manual lock patterns remain available

1.1.6 Platform

  • ✅ Open specifications: The Java Language Specification and the JVM Specification are public standards that any conforming implementation may implement
  • ✅ Multiple vendor runtimes: OpenJDK, Oracle JDK, Eclipse Temurin, Amazon Corretto, Azul Zulu, and GraalVM run the same class files
  • ✅ Open-source core: OpenJDK is developed in the open under the GPL with the Classpath Exception
  • ✅ Portable bytecode: Compiled classes run unchanged on every platform that hosts a JVM

1.1.7 Trade-offs (not coupling)

  • Checked Exceptions vs. Composition: Explicit errors don’t compose natively (no monadic operations), though sealed types + pattern matching provide exhaustive error handling
  • Backward Compatibility vs. Modern Features: 30 years of legacy — old codebases can lag behind modern idioms
  • Null as Default vs. Safety: Everything nullable by default couples all code to defensive checks — records and pattern matching help but don’t solve the root issue
  • Type Erasure vs. Runtime Types: Generics erased at runtime couples generic code to raw types
  • Inheritance vs. Composition: Hierarchy coupling possible when teams choose extension over composition

1.2 Ecosystem coupling

1.2.1 Performance

  • ✅ JVM optimization: Excellent JIT, fast steady-state
  • ✅ Virtual threads: Low-overhead concurrency scales to millions of threads
  • ⚠️ GC pauses: Tunable; ZGC offers sub-millisecond pauses (R2)
  • ⚠️ Startup time: JIT warmup (mitigated by AOT object caching (Java 26), GraalVM native image, CDS archives, and CRaC)
  • ✅ G1 throughput improvements (Java 26): Reduced synchronization overhead in G1 GC improves throughput
  • ✅ HTTP/3 client (Java 26): Native HTTP/3 support decouples networking from legacy protocol constraints
  • ✅ Mature profilers: Excellent performance tooling

1.2.2 Ecosystem

  • ✅ Massive ecosystem: Maven Central has everything
  • ⚠️ Enterprise monoculture: Spring dominates the server stack, so the alternatives are not really alternatives (Ec6)
  • ⚠️ Legacy burden: The enterprise stack keeps a 1999-era API in service next to a 2026 one, so a library supports both (Ec7)
  • ✅ Standardized build: Maven/Gradle industry standard
  • ✅ Excellent IDEs: IntelliJ, Eclipse, NetBeans
  • ✅ Mature tooling: Debuggers, profilers, monitoring
  • ✅ Cross-platform: Write once, run anywhere (mostly true)

1.2.3 Evolution

  • ✅ Strong backward compatibility: Rarely breaks
  • ✅ Regular releases: 6-month cadence, LTS every 2 years
  • ✅ Preview features: Opt-in features decouple experimentation from production stability
  • ⚠️ Legacy burden: Old APIs accumulate (though deprecated-for-removal process is active; applet API removed in Java 26)
  • ✅ final mutation now warns (Java 26): Deep reflection that mutates a final field reports a warning, ahead of a future release that blocks it

1.2.4 Domain

  • ✅ Excellent for backend/enterprise: Industry standard
  • ✅ Good for Android: Primary language (with Kotlin)
  • ✅ Strong for distributed systems: Mature frameworks
  • ⚠️ Poor for frontend: Applet API removed (Java 26); JavaFX remains niche
  • ⚠️ Not for systems programming: GC, overhead

1.2.5 Learning

  • ✅ Gentle: Widely taught, lots of resources
  • ⚠️ Modern Java is growing in surface: Records, sealed types, pattern matching, virtual threads, modules — more to learn than Java 8
  • ✅ Excellent docs: Javadoc, tutorials, books
  • ⚠️ Legacy/Modern split: Learning the “right” modern way requires guidance

1.2.6 Syntax

  • ✅ Records eliminate getter/setter boilerplate: record Person(String name, int age) replaces 50-line POJO
  • ✅ Pattern matching reduces verbosity: switch expressions + sealed types
  • ⚠️ Still verbose compared to Kotlin/Scala: Type erasure, generics syntax
  • ⚠️ Checked exception syntax: Verbose, couples signatures

1.2.7 Testing

  • ✅ JUnit industry standard: Mature testing
  • ✅ Excellent debuggers: Step-through, breakpoints, virtual thread debugging
  • ✅ Mocking frameworks: Mockito, EasyMock
  • ✅ Profiling tools: VisualVM, YourKit, JFR

1.2.8 Security

  • ✅ Memory safe: GC prevents memory bugs
  • ✅ Type safe: Static typing
  • ✅ Module system: Restricts reflective access to non-exported packages by default (Java 16+)
  • ⚠️ Null: NullPointerException still possible
  • ⚠️ Serialization vulnerabilities: Deserialization attacks (mitigated by records + modern serialization frameworks)

1.3 Engineering readiness

1.3.1 Reproducibility

  • ❌ Builds are not byte-reproducible by default.
  • ❌ Dependencies resolve without a lock by default.

1.3.2 Supply chain

  • ✅ No charged mechanism in this dimension.

1.3.3 Observability

  • ✅ No charged mechanism in this dimension.

1.3.4 Feedback

  • ✅ No charged mechanism in this dimension.

1.3.5 Interop

  • ✅ No charged mechanism in this dimension.

1.3.6 Governance

  • ✅ No charged mechanism in this dimension.

1.4 Profile

Unscored, and kept separate from every score on purpose. The profile records what a mechanism price cannot express: what a running program costs, how well a coding model and an agent work in the language, and whether a safety-critical path exists.

1.4.1 Energy and cost

What this axis asks: what does a running program cost in energy and time?

  • ⚠️ Runs on a virtual machine, above native code in the energy and time benchmarks [5]; a causal re-analysis attributes most of the gap to execution time [6].

1.4.2 AI and agent readiness

What this axis asks: how well does a coding model and an agent work in this language?

  • ✅ A large training corpus and strong code-generation results: models write this language well [7], [8].

1.4.3 Safety certification

What this axis asks: is there a certified or standards-qualified path to a safety-critical system?

  • ✅ A standards-qualified toolchain or an established safety standard covers this language.

1.5 Scoring detail

1.5.1 Core coupling Dimensions

Dimension Mechanism Description Present Cost
Type T1 dynamic no static check — 0
T2 weak static — 0
T3 dynamic/duck dispatch — 0
T4 no sum types — 0
T5 no generics — 0
T6 no namespaces — 0
T7 type erasure/reflection ✅ −4
T8 operator overloading — 0
T9 inheritance required for polymorphism — 0
T10 no null-safety ✅ −8
T11 no module boundary — 0
T12 no effect tracking ✅ −8
T13 async/sync colouring — 0
T14 unchecked foreign boundary ✅ −4
Type subtotal −15 (−24)
Construction C1 global mutable state by default — 0
C2 no immutability by default ✅ −4
C3 constructors coupled to allocation — 0
C4 no constructor/validation — 0
Construction subtotal −4
Memory M1 manual deallocation — 0
M2 GC non-deterministic pauses ✅ −8
M3 no RAII ✅ −4
M4 no ownership model ✅ −8
Memory subtotal −15 (−20)
Error Er1 no structured path — 0
Er2 unchecked exceptions only ✅ −8
Er3 errors ignored/non-exhaustive — 0
Er4 no composable result type — 0
Error subtotal −8
Concurrency K1 GIL/no parallel — 0
K2 shared mutable state default — 0
K3 manual sync no race detection ✅ −8
K4 no structured concurrency — 0
K5 no primitives — 0
Concurrency subtotal −8
Platform P1 cannot function outside one vendor/domain — 0
P2 single-vendor but other uses — 0
P3 legacy/discontinued platform — 0
Platform subtotal 0

Core Dimensions score: 50/100 — total cost = −50 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.2 Ecosystem coupling Dimensions

Dimension Mechanism Description Present Cost
Performance R1 interpreted no AOT/JIT — 0
R2 GC pauses ✅ −8
R3 JIT warmup ✅ −4
Performance subtotal −12
Ecosystem Ec1 no package manager — 0
Ec2 fragmented tooling — 0
Ec3 small/niche/discontinued — 0
Ec4 proprietary — 0
Ec5 platform-locked tooling — 0
Ec6 monoculture ✅ −8
Ec7 legacy burden ✅ −8
Ecosystem subtotal −15 (−16)
Evolution V1 breaking changes — 0
V2 frozen — 0
V3 discontinued — 0
V4 glacial standards — 0
Evolution subtotal 0
Domain D1 domain/vendor lock-in — 0
D2 poor domain fit — 0
D3 framework forces architecture ✅ −8
Domain subtotal −8
Learning L1 steep — 0
L2 large surface/multi-paradigm ✅ −4
L3 sparse docs — 0
Learning subtotal −4
Syntax S1 verbose — 0
S2 inconsistent — 0
S3 punctuation-heavy — 0
Syntax subtotal 0
Testing G1 weak tooling — 0
G2 poor debugging — 0
G3 runtime-only errors — 0
Testing subtotal 0
Security Q1 memory-unsafe — 0
Q2 dynamic/weak typing risk — 0
Q3 known vulnerability/injection — 0
Security subtotal 0

Meta Dimensions score: 61/100 — total cost = −39 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.3 Engineering readiness Dimensions

Dimension Mechanism Description Present Cost
Reproducibility Y1 build not reproducible ✅ −8
Y2 dependencies not pinned ✅ −8
Reproducibility subtotal −15 (−16)
Supply chain Y3 no signed provenance — 0
Y4 registry without namespacing — 0
Supply chain subtotal 0
Observability Y5 no stable tracing standard — 0
Y6 no structured logging — 0
Observability subtotal 0
Feedback Y7 slow build — 0
Y8 no fast in-editor analysis — 0
Feedback subtotal 0
Interop Y9 no foreign-function interface — 0
Y10 no portable target — 0
Interop subtotal 0
Governance Y11 single-vendor governance — 0
Y12 closed specification — 0
Governance subtotal 0

Readiness Dimensions score: 85/100 — total cost = −15 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

Verdict: Modern Java (17+) significantly improves coupling over its reputation. Records provide immutability by default. Sealed classes enable controlled hierarchies. Virtual threads transform concurrency from callback soup to structured blocking. Pattern matching with sealed types enables exhaustive error handling. Module system restricts reflection. Main strength: interfaces + records + sealed types + virtual threads create a strong coupling toolkit. Main weakness: null still exists, type erasure persists, and legacy codebases may not adopt modern idioms.

Note: The score reflects modern Java idioms: records over POJOs, sealed types over open hierarchies, virtual threads over thread pools, pattern matching over instanceof chains.

The formal development. The definitions, theorems, and proofs behind this page are published in:

All published papers

References

[1]
Y. Loth, “On the nature of coupling: All coupling as shared resource access.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925122.
[2]
Y. Loth, “Coupling as a consequence of cohesion: Decomposition, the coupling floor, and domain-imposed coupling.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925201.
[3]
Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.
[4]
J. Gosling, B. Joy, G. Steele, G. Bracha, A. Buckley, and D. Smith, “The java language specification.” Oracle; Java SE 21 Edition, 2023. Available: https://docs.oracle.com/javase/specs/jls/se21/html/index.html
[5]
R. Pereira et al., “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN international conference on software language engineering (SLE), 2017, pp. 256–267. doi: 10.1145/3136014.3136031.
[6]
N. van Kempen, H.-J. Kwon, D. T. Nguyen, and E. D. Berger, “It’s not easy being green: On the energy efficiency of programming languages,” in Proceedings of the 40th IEEE/ACM international conference on automated software engineering (ASE), 2025. doi: 10.1109/ASE63991.2025.00131.
[7]
S. Joel, J. J. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025, doi: 10.1145/3770084.
[8]
Y. Qing et al., “EffiBench-x: A multi-language benchmark for measuring efficiency of LLM-generated code,” in Advances in neural information processing systems 38 (NeurIPS), datasets and benchmarks track, 2025. doi: 10.48550/arXiv.2505.13004.