JavaBeans do not have any business being mentioned in the context of object oriented concepts such as encapsulation.
Encapsulation refers to the containment of functionality behind an api - in object oriented languages, the api is typically provided by a class through its public members. Encapsulation allows you to easily re-use functionality without causing undo binding because, again, the functionality is accessed through an api - never directly.
As someone mentioned above, an object by definition is when data and the code that operate on it are in the same class. In 99.9% of the cases I have seen JavaBeans being used (which unfortunately is everywhere), they do not contain any functionality other than setters and getters. Setters and getters are not application level functionality - i.e. you aren't going to cause an invoice to be saved by calling a setter or a getter, therefore beans are not objects.
Beans are structs, which are data only structures used in structured and procedural programming. They were state of the art in the late 80's, early 90's, using just about every language available at the time, the most popular being C.
Using beans will make your programs much larger and far less flexible than, for example, using collections in appropriate places. Everyone I discuss this with scoffs at this notion, but if I am not mistaken, compiled java classes, under the hood, are basically collections of collections. These collections are what reflection trolls through to get you information about the class. They are what the runtime looks through to find the correct method to run for a given class.
A bean is, without a doubt, about as automation unfriendly as you can get - they are utterly inflexible, and will grow your code base far beyond the functionality it contains.