Eh heh heh… So now you are implicitly for composition declaratively or otherwise / component architectures (CA) / entity systems (ES) as this is exactly what the “has a” relationship addresses. Your complaint is a valid one against OOP as “is a” encapsulation doesn’t lead to easy code reuse, maintenance, or modification and is precisely why I moved on from that sinking ship.
As Java is an OO language through and through you can’t stop anyone from using “is a” inheritance / encapsulation, but through careful construction of the CA one can force this to the leaves and prevent it overtaking the core at least as the central organizational construct.
Encapsulation as a concept in and of itself is not the enemy. I’ve mentioned this before, but in my particular efforts one can still achieve refined encapsulation by adding an internal control system component (AbstractComponentManagerControl / ACMC) to a component manager (may be an entity or whatever) that may veto or transform components or systems added / removed. If this control vetoes all additions / removals you just made that component manager final, etc. Want to change how it works then compose the component manager / entity with a different ACMC and series of components / systems. Potentially you may achieve your modification through composition (very quick) or you’ll be able to just modify the smallest amount of components necessary to realize the change then swap out the offending ones. This also aids in debugging as with declarative composition w/ a little control flow especially on Android being able to filter with device and family names one could branch and load the old and new composition on two different devices testing both at the same time, but on different devices from one build.
Folks should realize that creating a CA and validating its performance characteristics for near real time usage is a difficult task. In my case the ES part is just an extension of a more generalized CA. Since my effort is a runtime middleware layer converting and granularly separating this runtime from its prior OOP configuration so that it runs well over J2SE, Android, <fill in next Java environment / GL binding / etc> is what has taken 99.5% of the time. Not everyone should create their own CA, but those who do will also become better developers and fully use and understand all the advanced language constructs of Java 5.
Conceivably using a well constructed CA / ES once one wraps their head around it and understands how things work together makes coding and prototyping faster and efficient in addition to flexibility through the entire design and implementation process to make quick changes vs massive refactoring.
Ack now to respond to all the good comments since my last post… erg… will take a bit, but I’m on it… My initial verbosity was due to being on a plane with free provided chrome book and wifi… This next one due to good / interesting comments on the forums! 
Edit: I suppose to make things more clear as of course in OO design the “has a” relationship is available as any member field fits this description. What component oriented programming in an OO language like Java changes from normal OO is that the “has a” relationship becomes implicit rather than explicit for component managers, entities, etc.