The samples of the bean properties highlight the use of annotations quite a bit, however the annotations are only used during the first time a bean is bound. After that all of the data is stored with no need for reflection in the bean context/property context. The cool aspect if that 3rd party can define their own annotations for their own uses such as DB related annotations and plug them in by overriding the default bean container.

The ability to invoke myMethod(myBean.myProperty); allows you to pass a bean property to a generic method that doesn’t need to know much about said property. A method that accepts a color might not care if you will later use said color as foreground or background.
Probably the best example of this is the addListener method that now accepts a pointer to the property e.g. addListener(property, listener); Rather than the previous implementation that had addProppertyChangeListner(“propertyName”, listener); Notice that the propertyName is neither checked by the compiler nor properly documented.

In order to implement observability, probably the most common bean feature of all you need to implement at least 4 methods (2 for add and 2 for remove) and write significant amounts of code in order to fire events in every set method. A pain to say the least… You get that pretty much for free in the new bean properties and as an added bonus you can observe property changes in 2 additional scopes (property context and bean context) which allow whole new use cases.

Binding to anything be it a database or a GUI is remarkably hard, this is made harder still by invoking get/set methods dynamically in order to extract/push the data within said property. The current implementations of both the GUI binding API and the database binding API require no bytecode manipulation whatsoever and most of the code relies on plain and simple polymorphism. Yes there is an invocation of Field.get() there but when compared to the scale of reflection or generated bytecode a typical implementation of these features would require… The difference is quite bit.

Automatically generating a UI from a pure data bean has been done before and failed, there are many reasons for that failure and all of them have been solved by the bean properties. UI factories become not only possible to develop but also remarkably easy to develop and localize thanks to the design of the bean info.

Virtual properties allow us to dynamically add a property to a preexisting bean without modifying its code. The property would not be visible statically (e.g. bean.virtual won’t compile) but it will be visible dynamically in the many bean context methods that allow detecting properties (e.g. bean.getContext().getPropertiesArray() would return virtual properties as well).
This allows use cases that were previously impossible such as database primary keys that have no business purpose don’t need to be defined in the bean, they can be dynamically added for the DB mapping layer only. It allows custom fields defined at runtime to have the right name/attributes and Java type!

Few people ever bother to write bean info objects since they are such a pain, they are limited and annoying. They can’t be extended and generalized like proper objects and its very hard to add additional meta data… No wonder their meta data looks like an early 90’s API (monochrome 16x16 icon?). The lack of ability to specify anything elaborate not to mention localize the information has eliminated the very idea of meta-data associated with beans!!!
What are beans if not coarse grained objects with additional meta-data? We ended up dumbing down our beans and tools because we just didn’t want to deal with this terrible construct. No more, meta-data can be defined easily and mostly checked by the compiler where applicable. It exists in runtime and can easily be extended by 3rd parties to contain additional information.

The state loaded by bean info is only half the story, comparison of beans and actions on a bean sometimes need to apply a feature to a scope of the whole bean/property rather than a single object instance. Since every bean and every property has a single global context object associated with it using this object as part of your API becomes trivial. E.g. bindToGui(PropertyContext p); would work as bindToGUI(bean.property.getContext()); Notice that this is checked by the compiler and can be used to apply functionality to the given property on all of the instances of the bean.

Building your own implementation of Property is remarkably easy! This is far more powerful than implementing a get/set method since this code can be refactored and reused as much as you want. Several examples of such reusable properties exist in the code base, an SQLProperty was an interesting experiment while the LegacyDelegateProperty seems like a remarkably useful tool in order to expose functionality of an underlying legacy bean. The ability to define your own reusable properties is what differentiates this framework from getter/setters.

EJB’s and lightweight IoC frameworks have benefited from central management for years and now a simplified version of these ideas is within reach. Since all beans pass through a central point a great deal of the code can be generalized. Event handling is probably the simplest and most powerful allowing the greatest performance benefits from central management. However the flexibility is only limited by your imagination, the container can be subclassed and replaced (without changing a single line of bean code including BeanContainer.bind(this) calls!). This allows you to tailor in custom logic for every bean binding which is an excellent point for runtime bytecode instrumentation if someone desires or for custom bean initialization code… Common methods such as equals, toString etc. and some special methods such as toMap have generic reasonably efficient implementations within the container allowing for a great deal of reuse.