What did it save you server-wise and how long did it take to identify and make the change? Also, did you discover this as part of a performance problem investigation or was it something you saw upfront and nipped in the bud before it became a problem. I agree it sounds like poor design. I instinctively simplify whatever info is going to be sent from the server.
Generally when building servers on top of a jvm, it's a good idea to be able to capture eg 1m requests, replay them, and monitor your memory allocation / gc as part of quality tests. If you create nests of objects in java, it quickly gets expensive, both in terms of net memory and gc costs. One common place this happens is parsing json/xml; use thrift or protobufs instead.
If you are eg building an ad server that is supposed to sustain some XX thousand requests per second, you want to also monitor eg eden, survivor, tenured, and promotions. Bump pointer allocation and gc is very fast -- normally faster even than manual memory management -- as long as almost nothing survives. The problem is if some objects start accidentally living past requests, stuff goes boom fast.
It was something written by a different team, so it was committed by the time I saw it. But I thought it looked bad immediately. Profiling later showed that it was a problem spot, and changing it showed decent improvement.
