Item — HN Reader

Well, it was annoying until autoboxing came in.

  // Before autoboxing
  list.add(new Integer(42));

  // After autoboxing
  list.add(42);

Mostly it's a non-issue now. If you're desperately cycle/memory constrained you're likely not using Java anyway.

2 comments

You can get pretty good performance out of Java these days, so long as you know to avoid stuff like boxed primitives and the streams api, as they generally have god-awful memory locality, and generally don't vectorize well.

Yeah, I know there are even oddballs using it for HFT and the like - I like Java a lot, but even I find that a bit peculiar.

Edit: actually, if someone here is using it for something like that I'd love to hear the rationale...?

I've worked adjacent to that space (high performance fin-tech java), enough that I feel qualified to answer.

It's mostly a trade-off. Java's tooling, reliability and ecosystem is some of the best around. Even though building high performance software in Java is a bit of a pain, looking at the bigger picture, it's often still worth it.

Not „oddballs“ for sure. Java established itself as the primary enterprise language for fintech in 2000s and since then there was and there is no reason to switch. It offers everything business needs including vast supply of workforce.

If you're desperately cycle/memory constrained you're likely not using Java anyway.

Java Cards would like to have a word with you. But yeah I know what you mean.