Then you just don't handle them!
I hear you, but that wasn't what I meant really. When I don't want to handle exceptions because I simply can't handle them, I don't mean I want to swallow them.
In my personal experience, it seems that in a lot of cases the only sensible course of action is to let the exception bubble up right to some top handler that does 'handle' the exception by simply aborting the operating.
In a request/response Java EE situation, this simply means aborting the request and displaying a general error page. Runtime exceptions let you do exactly this without all the boiler plate code and verbosity, which can introduce its own bugs simply by means of obfuscating the real code in your system to your programmers.
No, you should declare an own exception, and wrap the exception of the dependencies in that new exception.
Indeed, this is a reasonable approach, but one that does lead to very deep levels of chained exceptions. Now if the exception is really exceptional this might not be the end of the world, but constantly applying the wrap-retrow pattern can still add a lot of mental overhead to your code. Sometimes this is justified, but in a lot of cases all you want is the exception to be handled by the top level exception handler. You're then creating lots of specific exceptions, lots of specific try/catch code, but it's never really used since it's only the first exception in the chain that counts and nothing is ever done with the intermediate ones.
I do agree that checked exceptions are a great way to force people to document what exceptions a method is expected to throw, which is indeed a benefit.
Anyway, I didn't really start the move away from checked exceptions, just observing that this seems to be happening ;)