Imran Nazar recreated a JavaScript animation demo on 1982 hardware and wrote up every decision along the way: 6510 assembler, fixed-point math with no floating point available, a CPU bug turned into a cosine lookup. When he lands at 30fps, he can tell you exactly why without running it. It's very cool.
Christian Rackerseder makes the case that developer experience is a performance feature. The stronger version of his claim is that developer experience is an epistemic feature. Good performance is just one of the things that falls out when your team can finally see what it has been shipping.
Timefold Solver, OptaPlanner's successor, hits 2.0 with list variables promoted, a new Neighborhoods API, and a quietly consequential license shift: the explainability APIs you built on in 1.x now require a commercial edition. The solving core stays Apache 2.0, but the answer to "why did the solver pick this?" is now a paid feature.
MethodHandle has been in the JDK since Java 7, and most Java developers have a vague sense that it exists somewhere near invokedynamic and lambda internals. David Lloyd's ongoing series covers the mechanics thoroughly. What it doesn't cover is when you'd actually reach for it - and why.
Optimization isn't a single measurement and a fix. It's whack-a-mole: find the loudest problem, fix it, then look at what the problem was hiding. Jonathan Vogel's second installment in his Java performance series shows this process live, with JFR recordings and flame graphs - including a contention bug that was completely invisible until he pushed the concurrency high enough for it to matter.
Two recent articles tackle JSON querying performance from opposite ends: one applies automata theory to eliminate interpretation overhead at query time, the other kills a $500K/year language-boundary tax by rewriting a JavaScript reference implementation in Go. The methodologies are different; the lesson is the same.