This is not the most popular opinion but I don't see much of a difference.
Setters and getters are a fairly bad idea. I've thought about it and honestly I can't come up with a difference between a setter/getter and a public variable in practice.
In THEORY a setter and getter add a place to take some extra actions when a variable is set/gotten and in theory they isolate your code from changes.
In reality I rarely see setters and getters used to add an action, and when you do want to add an action you want to add it to ALL the setters or getters of a class (like logging) which should make you think that there ought to be a better solution.
As for isolating design decisions, if you change an int to a long you still have to change your setters and at least check every line that accesses them by hand--not much isolation there.
Mutable classes should be avoided by default anyway, so adding a setter should be a last resort. This is mitigated with the builder pattern where a value can be set until the object is in a desired state then the class can become immutable and your setters will throw exceptions.
As for getters--I still can't come up with much of a difference between a getter and a public final variable. The problem here is that it's bad OO in either case. You shouldn't be asking for a value from an object and operating on it--you should be asking an object to do an operation for you.
By the way, I'm in no way advocating public variables--I'm saying setters and getters (and even properties) are way too close to already being public variables.
The big problem is simply that people who aren't OO programmers are too tempted to use setters and getters to make objects into property-balls (structures) that are passed around and operated on, pretty much the opposite of how Object Oriented code works.