Introduction Measuring an object’s size in Java is not straightforward. The platform encourages you to consider references and abstractions rather than raw memory usage. Still, understanding how objects fit into memory can yield significant benefits, especially for high-performance, low-latency systems. Over time, the JVM has introduced optimisations like Compressed Ordinary Object Pointers (Compressed Oops) and, more recently, Compact Object Headers. Each of these can influence how large or small your objects appear. Understanding these factors helps you reason about memory usage more concretely. Measuring Object Sizes In principle, you can estimate an object’s size by creating instances and observing changes in the JVM’s free memory. However, you must neutralise certain factors to get consistent results. For example, turning off TLAB allocation ( -XX:-UseTLAB ) makes memory usage more directly observable. Repeated measurements and median calculations can reduce the im...
It depends on the context and what your customer expects. I will differentiate between 3 type of editions:
ReplyDelete1. the ones that can be solved by the customer, like a NumberFormatException from a customer data.
2. The ones that customer cannot do anything like a NullPointerException.
3. Others we can retry, like the dependency is not available.
So for 3 I will not show them to customer unless they are persistent, in which case they become exceptions of type 2.
For type 1 you need to show to the customer and I will not log anything, obviously you need to catch it.
For type 2 you should show to customer as well and potentially with a way to report the error.
Is this blog dead? no posts since Mar.2017
ReplyDeletePlease follow the links to my new blog, though the last post was the end of May, I have more posts planned.
Delete