I'm working on an application in which I need to construct some objects at runtime in a way in which the JavaBeans pattern seems to make sense. I need to let the end-user set properties on an object. The exact list of properties, their names, and types are dependant on the concrete implementation of the classes not their interfaces. The implementations may be loaded as modules dynamically. I was hoping to use the property sheet Swing components to provide this.
The problem is that the classes are generified and Generics don't sit well with JavaBeans since Generics are a compile-time trick (which can be introspectively examined on the class but not the object) and JavaBeans are about creating and modifying an object at runtime.
Is there a sensable workaround to this type of design or an alternative pattern to JavaBeans which would let me carry parameter information in some form with the objects? Is this anything anyone has come up against?
The more I use Java Beans the less I see the point, unless there is a design-time facllity. These days I am just using a single request-scoped Map bean for all that stuff and avoiding the ORM style of things altogether as much as possible. I don't miss it ;-)
You could be right, i just didn't want to get bogged down in the details in case there was a simple work-around.
I'm working on a graphical framework for problem solving. Problems and algorithms have specific parameters and I want to have the user construct them using property sheet Swing components (that or something similar). The algorithms are generified on the type of encoding they work with and use operators on the same generified encoding types. These operators are parameters of the algorithms and themselves have parameters. The objects which the user builds should be serializable; and I will have to load classes which are developed after the program was written, hence will have properties accessed introspectively.
It seems as if JavaBeans gives me what I want here except for generics. Do I have to abandon the generics (meaning the user wont find out about mistakes mismatching the types until they run the algorithms and get class cast exceptions) or can I work-around this, or is there a simpler design? What do you think?