As much as I am a fan of go, this sounds like it's a bad build infrastructure more than any fault of Java. JAR shading exists, their imports were probably out of hand (and significantly unused), and while they were microservices, they probably could have had groups of them share a JVM (and benefited from the shared permgen space).

Still, that's time and effort, and in Go you get all of those things for free. There's far fewer janky edges (I spent hours figuring out the problems with signed jars, shaded jars, and symlinks when trying to deploy)

> The idea is that a server this small should probably not consume oodles of memory.

The number of LOC has no bearing on how much memory something will consume. For all you know the service could just be poorly implemented.

This is true regarding heap space (you can allocate couple gigs in one line), but perm gen space and JIT space can also be significant in JVM case.

Permgen space doesn't exist in the JVM any longer.

And not sure what JIT space is.

I think the OP meant "Code Cache" when they said "JIT space".