>Not an expert in Java myself... From what I have seen so far, it should work if you access the properties ("fields" I think they are called in Java) directly (assuming you defined them with the appropriate access rights).

>
>The problem here is that the designer of a class may later decide to change the internal data structures - and this may require to change any outside calls to this class. To avoid this, the data is encapsulated - the properties are hidden (from outside classes), and can only be accessed through "set" and "get" methods. Thus, the developer makes changes only within the class.

This argument has IMHO more weight when used for an interface exposing only very small part of the class - and even then, if type changes in the base field for instance, changes in the external code can be necessary. But most internal class code also uses the get/set-methods, as they are (today mostly automatically genereated) in the code anyhow, so why not use the isolation for internal use ?

Yes, I also think "overriding" normal property handling is more elegant and programming only the needed exceptions or functions from "normal" behaviour has better OOP taste ;-) But AFAIR at least some java devs strive for less boilerplate code as well: aspect-orientation can be used in a similar way. But IMHO this is still uglier than the vfp way.