Solution 1:

This is because the root class for all exceptions, Throwable implements the Serializable interface. All exceptions by default are serializable and that's a language design decision because the authors wanted exceptions to be capable of being sent across the wire without any special configuration.

If the base class is not serializable, you would have a difficult time conveying what exactly went wrong in case a remote method failed since you would have no control over the built in exception types.

Solution 2:

If your custom exception is ever used in a distributed application (using RMI, Spring http-invoker, whatever) and can be thrown from a server method that is invoked from a remote client, then the exception will have to be serialized to cross the wire and go to the client.