For example, if you want a Property that is non-null and 256-or-less characters, you would need to extend Property to generate NonNullProperty and then extend NonNullProperty to generate TwoFiftySixCharacterProperty. Should a Property that is 256-or-less characters be required that can take null values, you would need to essentially duplicate the TwoFiftySixCharacterProperty class and extend directly from Property. As you can see, this will get out of hand quite quickly.
Then don't do that.
Make a SuperDuperNullNotNullAnyLengthNumberValidatingUberProperty that you can configure when you build it.
Or: Property<String> myString = PropertyFactory.buildProperty(String.class, "initial value", NOTNULL, MINLENGTH, 5, MAXLENGTH, 10, REGEX, "[A-Z]+");
Wow, that was hard.
I like the idea. I like it for many of the reasons stated, notably being able to reuse logic as an aspect of the property (like change notification, etc.) rather than the thousands of lines of boiler plate we get code gen'd "for free" (yea, like a puppy...).
The dark side is, at least in my case, a bulk of my "beans" are JPA'd beans. So, they're not really eligible for this since neither the FIELD or PROPERTY technique can (readily) be used to populate them. I mean, I could boiler plate the setter/getter as wrappers for the Property calls, but -- dunno if that kills or cures, really.
So its one of those chicken/egg momentum things. If the idiom were first used early on, then we'd have all of this built in dependency for it (like we have now). But, now it's a bit far down the road, so uptake as a general purpose tool has many ancillary infrastructure costs.
Still a cool idea, and I'll keep it in mind.