Perceived Flaw with Java

There are several things that annoy me about Java.  Same goes for C# and similar languages.  Albeit - I do respect the "code-behind" feature of C#.

The flaw is not security, it's not performance, it's not syntax, it's the encouraged methodology.  And I'm not complaining about the inner classes used to implement interfaces to receive events (although that could be a rant on it's own).  It's a philosophy that developers must break out of.

Getters and setters - I'm looking at you!

Nothing wrong with getters and setters?  Hmm - let's delve deeper into the perceived problem.  A getter allows code to extract values from a class, and a setter allows us to set values into a class while performing a bit of error correction.  Sounds good so far.

But there's an ominous problem here - and it appears to affect most OOP languages.  The getters and setters - when used improperly (happens more often than not) - bypasses the elegant concept that a class' public methods are simply a gateway to get something to happen and that the underlying implementation can change at will.

Classes should perform a (limited) set of actions and the getters/setters should reflect not the underlying implementation but what the user of the class is expecting.  So often I've seen getters/setters for questionable things that clearly indicate how the underlying implementation must function.  Functions made public for the sake of having them accessible by any other class (since it was convenient).

And XML serialization is making this worse, using reflection to get at the class internals by assuming variables will each have a "getValue" and a "setValue".  The holy-grail of OOP - modular components that can be changed independent as long as they retain the same behavior diminishes as the getters/setters imply an implementation.

I could argue for C-style header files.  However, that wouldn't make a difference - it's a method that I feel Java makes worse.

For example - for most problems - if posed correctly - can be very simple and elegant.  Composition of this simpler problems using classes that expose simple interfaces can keep the program as a whole simple.  However, in reality at times, it's a free-for-all with overly complex function calls... (a big picture view is required to get anything done)

Maybe I'm ranting for nothing?  Maybe things need to expose their complexity?