Effectively Using an Entity-Component Framework
Entity-component frameworks are a failure dramatic design change from the standard OOP practices most often employed. Using an entity-component framework doesn't mean you can't stop using OOP, and it doesn't have to invade your entire project. I find it as a useful representation for the game state and content, but that doesn't mean you have to use it for your interfaces and menus, etc.
It is important to make effective use of any such framework, and shouldn't be used like a conventional system. One of the clearest examples of this was a presentation by Sony on the pitfalls of object-oriented programming: PDF. Essentially, the model of processing one game entity at a time, branching on its particular class type or set of activated states meant that by the time you were done with the last computation, you'd wrecked the cache of any data or function pointers for the next entity.
A data-oriented approach would pack every value for one property for all entities together and process that for every entity, before moving onto the next block of data that needs computation. Besides having much better cache coherence, it provides a good model for separating data from function because you define the functions that process the blocks of data separately from where the data was defined. They had a very clear walkthrough of these types of pitfalls so I strongly recommend reading it. Much of it was targeted at consoles and C/C++ development but many of the concepts apply to Java as well.
Here is a list of additional blogs and sites that offer a good discussion of what goes into an entity framework and how to model your game: