BSbsommerfeld·May 5, 2026Submission
Show HN: Pathetic – Java pathfinding: 10k concurrent paths in ~7ms
It started with drones. My co-founder and I were building a Minecraft plugin where drones had to navigate through unloaded chunks - terrain that doesn't even exist in memory yet. No existing library had any concept of it, which led to drones being stuck in non-existence.
Sloppy at first, tightly coupled to Minecraft's API, we built our own. But somewhere along the way we realized: the problem wasn't Minecraft. It was how Java pathfinding is built in general - object-heavy, GC-hostile, and single-threaded by assumption.
So I split the project. The core became its own thing: pure Java 8+ for compatibility, featuring a zero-allocation primitive heap instead of a theoretically optimal FibonacciHeap, because pointer chasing and cache misses were unacceptable. 100% async, even in a single-threaded, async-hating Minecraft hell, and a processor p
Read the rest
ipeline providing full extensibility. No game engine, yet the possibility to adapt to your environment.
Sometimes it isn't the algorithm that needs optimization, but the environment it lives in. Pathetic is full of these micro-optimizations: a BloomFilter lookup before the expensive closed set check, a multi-metric squared heuristic to kill Math.sqrt() overhead, and bit-packing 3D coordinates into a single primitive long. In order to get Java fast, you need to treat it like C++.
The result: 10k concurrent paths in ~7ms, where most libraries quietly die. A 20k distance path (equivalent to 100k+ nodes) in ~60ms without bloating the heap.
The README is... a choice. Judge it, because it does the same to you.