commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: [Design Discussion] DynaBeans - Round 2
Date Thu, 27 Dec 2001 20:42:30 GMT

On Thu, 27 Dec 2001, Rey Francois wrote:

> Date: Thu, 27 Dec 2001 18:36:25 +0100
> From: Rey Francois <>
> Reply-To: Jakarta Commons Developers List <>
> To: 'Jakarta Commons Developers List' <>
> Subject: RE: [Design Discussion] DynaBeans - Round 2
> Just bouncing a few thoughts...
> How about pooling DynaBean instances? The best place to do this would be the
> DynaClass itself, assuming it has the responsibility of creating DynaBean
> instances. This could introduce some complications too: applications will
> need to call a discard() method in order to properly recycle an instance.
> Still, I think that deserves some exploration because such feature could be
> very interesting in some cases...

It (pooling in the DynaClass) could certainly be done.  Of course, it can
also be done externally (commons-pool or whatever), so I'm not sure that
it's important to support it inside.

> Perhaps for now we should keep this in mind and see if it makes sense once
> it has been deployed a few times. If we give the DynaClass the
> responsibility to create DynaBean instances, then later on we could still
> implement the usage of a pool behind the factory method. Or we could also
> create a class called DynaConstructor, which as a newInstance() method, and
> make the DynaClass able to return one or more DynaConstructors:
> DynaConstructor getContructor(Class[] parameterTypes). This solution is
> actually imitating the JDK classes Class and Constructor...

I think that DynaClass *does* need a factory method to create new
instances (equivalent to Class.newInstance()), with a configurable
implementation class.  But, after the instance is created, I think it's
really up to the application to decide whether to pool or not.

> One more thought: a few of us have been debating about the type-safety
> issues, whether changing to non-type-safe languages is a better choice, etc.
> I don't think the purpose of DynaBeans is to get away from the type-safety
> Java offers. To me the real reason why DynaBeans are being discussed and
> proposed is because the  Java language does not offer any way to define bean
> classes dynamically at run-time. However the solution we propose to this
> problem makes us loose type-safety. Suppose Java supported the ability to
> define a bean at runtime, say, with a helper class that takes a list of
> properties and returns a Class instance. Wouldn't this remove the need for
> DynaBeans and integrate nicely with the existing java.beans and beanutils
> packages, while preserving some type-safety? Another way to implement
> DynaBeans would be to generate class files and use a special class loader
> for that purpose...

We could always just generate Java source code and compile on the fly, the
way JSP pages work ... but you have to have container support (i.e.
allowing an application defined class loader).

In terms of type safety, Java has lots of situations where you don't have
it -- all the collection classes take Object as element types, and so on.
You always have the choice to do the same for your properties too.  I want
DynaBeans to be useful for both people who want type safety and those who
don't to maintain that kind of freedom of choice.

My bet is that a very common usage pattern will be to use DynaBeans for
VOs and other sorts of simple data carrier classes, especially in the
prototype stage of a new application.  Later on, you can improve
performance and/or add functionality by converting some or all of them to
real beans -- but even this transition can be hidden away if you're
accessing the properties indirectly via things like PropertyUtils.

> The issue were facing here is quite similar to the one faced by the dynamic
> generation of event listener, see
> for more
> details. To resolve the latter problem, J2SE 1.3 has introduced the Dynamic
> Proxy Class API
> (
> As I said, just bounding a few thoughts...
> Fr.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message