On 2/26/08, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > The proxy based approach solves exactly this problem.
Wow, fancy! :-) Thanks for sharing it, we'll probably use it too. The rest is by no means ment to discredit your effort, more like the devils advocate grumbling in front of the TV about Java in general: Isn't the JavaBean as key-value datastructure the real problem? We were lucky to be able to use a Map at one place in our wicket code for a "reflective" model object instead: CompoundPropertyModel supports it uniformly. Do people ever use non trivial getters and setters in their JavaBeans? We don't. Type safety and JPA are nice though, so we use JavaBeans everywhere else :-) But I just can't help wondering how the complexity (and performance) of current reflection/bytecode generation efforts would compare to porting all the JavaBean based tools and utilities to some different datastructure convention? One designed for programmatic manipulation. Like a Map where the key contains the type of the value. Some EnumMap-like optimisation could be employed when the keys are known compile-time. Would cover 90% of the cases people use reflection for currently I expect. Just imagine, JAXB could be a utility class with 2 static methods: encode and decode :-) Gabor Szokoli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
