Open debate: checked vs. runtime exceptions

I have written, or more accurately refactored, a large amount of code to switch from checked to runtime exceptions, and it made things better every time. In principle, I agree that checked exceptions have a place when the caller can recover in the given context. User input is a typical example. These cases account for perhaps 20%. The remaining 80% are runtime exceptions caused by system failures that the client cannot recover from in that context. A database server outage is one example.

The biggest drawback of checked exceptions, as I see it, is how much they intrude into the client API. This causes two problems. It breaks backward compatibility and, in most cases, produces repetitive code that converts exceptions into runtime exceptions. I agree that exceptions need proper handling, but I see little advantage in having the compiler enforce it.
In practice, that tends to make exception handling more chaotic.

You can handle runtime exceptions properly, too. The key is a central place, perhaps an aspect, responsible for catching and processing them. Another handy technique is the declared runtime exception. List runtime exceptions in the throws clause, and at least anyone looking at the method signature can see what might happen.