Constantin Marian

Article is based on JDK 8 mainly

Agree, the numbers are just examples, but definitely to make it close to reality I will adjust as you suggest. Thanks

It depends on GC type. F.e. G1C brings this application pause to minimum, however there are phases when GC runs that still need a full application pause. Please see the "Garbage collector types" in this article

When first GC happens, objects are moved into survivor (S0) space, and when GC happens the second time objects from young gen that survive, are moved already to second survivor (S1) space. At this point also those who survive GC from S0, are also moved to S1 memory space. Hope that I answered your question.

Hi,
In the article itself you can find examples of strong, weak and soft references, and how to create those. Static is a bit something else. When you have a static variable , this means it belongs to the class, and you reference to it with the class name. This variable is shared among all created objects (instances) of that class.

That's arguable! This is not an anti-pattern. The problem you mentioned is more like not having duplicate exception handlers. But you can handle the exception partially, and then rethrow it, or rethrow a wrapped exception.

It's indeed a good practice to wrap the low level exceptions into your custom exception, but ony if it's the case. Sometimes you may want to throw different types of exceptions, because you want to give the possibility to the caller to handle them different. e.g. A service is calling DAO's method for deleting an object, and could be that the object doesn't exist anymore in the database, but also could be that the object is locked for an update. In this case, you might need to throw different type of exceptions. In this way, you let the service layer to decide what to do next, simply return a nice message or trigger a retry action.

SQLExceptions and IO exceptions are low level exceptions. If you want to handle that type of exceptions at a higher level, the best way to do this is to wrap your low level exception into a custom exception. A high level API doesn't need to know the reason why an SQL or IO exception was raised. Only you want to see in a higher level API is an explicit message, containing the reason of what went wrong. So, don't hesitate to catch low level exceptions, get the useful info from them (log them as well if it's the case) , wrap them into a higher level exceptions with a meaningful message, and retrow them