Objects should have both state and behavior.
Getters and setters are evil when used to process data related to that class. For example having a Sale class do this:

salesLineItem.setTotal(salesLineItem.getQty() + salesLineItem.getPrice())

rather than this

salesLineItem.calculateTotal()

is an abuse of getters/setters.

Following the ‘expert’ pattern, an operation that requires knowledge of state should reside in the object that contains the state.

What?! No, I can’t see that at all. Are you saying I should not be able to retrieve the textual name of a File? What if I (*gasp*) wanted to print the name of the file to a JTextArea or JLabel? What if I wanted to log the name of the file currently being operated on to a log file? It’s just insanity to remove the ability to convert a File object into its textual representation. Everywhere I ever needed to work with both a textual representation of the filename and also the File object, I would have to pass two arguments instead of one. Not to mention the hassle of return values, where you are limited to returning a single argument, so passing both the textual representation and the File object itself is not even an option unless you return an array or some sort of wrapper class, which defeats the purpose of separating them in the first place.

The cause of this poorly designed code is poor design, not Getters and Setters. Trying to solve design flaws with syntax-level solutions is like trying to turn a 2 year old into a master painter by giving him more expensive paint.