Rethinking Java String Concatenation
summary
A prototype keeps the JEP 280 design but replaces large method‑handle expression trees with generated helper classes using the Class‑File API and hidden classes, plus a reference‑key cache to avoid one‑class‑per‑site explosion. The result matches throughput while cutting startup and warmup: earlier enumeration produced ~40,000 generated classes (later reduced to ~3,000); a 100‑argument case drops from ~160 classes to one; microbenchmarks show roughly 40% startup reduction and parity in steady‑state. Works as a near‑drop‑in replacement for the current JDK path JDK 23.
AI-written summary · about
chapters (10)
- 0:00Introduction and challenges
- 4:11Current implementation basics
- 7:30Method handles explained
- 13:44High-arity fallback
- 15:23Performance and scalability
- 21:39Potential solutions and Leyden
- 26:07New prototype approach
- 33:46Prototype results and future
- 38:59Key takeaways and outlook
- 43:36Q&A and discussion
related talks
46mEnough java.lang.String to Hang Ourselves ...
48mEnough java.lang.String to Hang Ourselves ...
40mWhat Every Java Programmer Should Know About Strings
09mString Enhancements in JDK 9
46mEnough java.lang.String to Hang Ourselves...
32mUnveiling the Hidden Layers of Java Class Files Beyond Bytecode
32mClojure, Java 9, and You
01h 02mCompact Strings