Your view differs from some of the OO language designers. For example, Stroustrup defines encapsulation as "the enforcement of abstraction by mechanisms that prevent access to implementation details of an object or a group of objects except through a well-defined interface. C++ enforces encapsulation of private and proteced members of a class..."
I sympathize, yet encapsulation is appropriate for some projects. Not all users of a library want to frequently update to their own code. Forbidding encapsulation and deprecation would increase this cost. Also, it's comforting to be able to refactor the guts of a class without harming users.
I reported to a manager that attempted to measure our productivity fixing bugs by comparing the lines of code before and after the fix. Most fixes reduced the lines of code, so our numbers were usually either negative or close to zero. A couple weeks later the manager interrogated the team as to why we were so unproductive.
Another fun experiment is to measure developers using lines of code, and then switch to unit test coverage. For some reason, the code always seems to shrink.
Counting lines of code for maintenance work is a little like evaluating your mechanic based on the weight difference of your car before and after he fixes it.
Has the Java the brand completely evolved from a enterprise Sun product, into a counterculture language? With GWT and other JVM languages, Java is starting to look cool again.