Hi,
I implemented some generator for beans, it is very dirty and generated beans
are not serializable at this time.
It can be used this way :
BeanGenerator generator = new BeanGenerator();// some kind of ClassLoader
// add get/set and private field
generator.addProperty("myProperty", int.class );
generator.addProperties( propertyDescriptors );
// add static methods
generator.addMethod( "mySin", Math.class.getMethod("sin",new
Class[]{double.class} ) );
generator.addMethods( StringUtils.class );
Class beanClass = generator.generate();
context.put("bean", beanClass.newInstance() );
can be used as:
myNumber = bean.mySin(pi)
in some scripting language.
I have plans to implement generator for BeanInfo too.
It hosted on sourceforge [cglib] at this time
I am not sure it is useful thing, but it can solve some dynamic programing
problems,
like "static utility methods".
>
> +1 on adding a new subproject.
> -0 on calling it "reflection".
>
> Calling it "reflection" will be a bit misleading as it implies
> java.lang.reflect. But what has been discussed so far is more than simply
> providing a "thin" utils on the top of java.lang.reflect.
>
> I'd suggest something like "Meta-Prog", "ClassGenerator", or even
> "Metaclass" (?!).
Code generation is invisible for user and I think it was not good idea to
use
names like "generator". Some java.lang.reflect implementations use code
generation too.
> --
> John
>
>
> At 03:33 pm 08-10-2002, you wrote:
>
> >Agree, [lang] must be minimalist as possible,
> >[lang] is not a very good prefix for this thread.
> >I am thinking about some new subproject it sandbox for reflection.
> >
> >BTW .NET's reflection has some API like BCEL to genetate code for CLR.
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, October 07, 2002 11:15 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [lang] Proposal for *NEXT* version
> > > >
> > > >
> > > > Hi,
> > > > I do not think dependency on top level project is any problem
> > > > for commons
> > > > component, if public API does's not have classes or
> > > > interfaces from this
> > > > project.
> > >
> > > I disagree. Commons Lang should sit as close to the JDK as possible -
> >that's
> > > really what it's all about. If it starts depending on other packages,
then
> > > it seems to me that it no longer meets its design goals.
> > >
> > > > Projects like BCEL , ORO, Lucene are very good and solve
> > > > common problems
> > > > too.
> > >
> > > Sure, but they do not - and should not - relate to Commons Lang.
> > >
> > > --
> > > Martin Cooper
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
