+1 I will help to code low level stuff. I think we need some high level API (interfaces ?) first and we will find ways how to implement it later BCEL, java.lang.reflect ... ..
> There seems to be some consensus that a new project is possible here. I have > already been working locally on classes in this area. Below is the > proposal.html file that I was using to control my scope:? > > <h3>(0) Rationale</h3> > <p> > The Java Reflection Framework provides a set of classes for accessing > and calling classes, methods and fields dynamically at runtime. In > addition, the beans Introspector class provides for examination of > java beans. Together these offer very useful functionality that is > widely used by todays applications. > </p> > <p> > There is a need for reflection and introspection code in a great many of > the Commons, Jakarta and Apache projects. However, the standard Java > classes have proved inadequate, causing each project to write their own > reflection helper classes. In addition, many projects also require metadata > to be stored against classes and properties. This is not supported by the > current Java APIs. > </p> > <p> > The <em>Clazz</em> package will focus on introspection and class > manipulation. > Reflection helper code is located in the [lang] package. > </p> > > <h3>(1) Scope of the Package</h3> > <p> > The <em>Clazz</em> package shall create and maintain a package that provides > introspection and class manipulation handling built upon the Java Reflection > Framework and other providers, such as byte and source code > readers/generators. > </p> > > <p> > The package should: > </p> > <ul> > <li>handle all classes, not just beans</li> > <li>support extensible metadata (not just for GUI builders)</li> > <li>handle normal (today) bean conventions (get/set/add/put methods)</li> > <li>handle future conventions that are not yet standard</li> > <li>support method overloading</li> > <li>provide a complete alternative to using java.beans.Introspector</li> > <li>be simple to learn</li> > </ul> > </p> > > In terms of code, [clazz] would begin by having classes/interfaces that > represent a class, method and field like reflection. It would then provide > mechanisms to build the structure via reflection and BCEL, and ideally to > generate classes from the structure using BCEL. Note: One possibility would > be to say that the BCEL dependency belongs in BCEL, and the commons version > just uses reflection. > > [clazz] would also provide mechanisms for identifying methods as being > property methods, coping with modern conventions such as addXxx(), lists and > maps that the beans introspector doesn't. This would allow [clazz] to be > used by betwixt and digester to add flexibility. (I remember reading a case > where some swedish company had insisted on localising the words get and set > in bean methods - [clazz] could cope with that) > > Thoughts? > > Stephen > > ----- Original Message ----- > From: "John Yu" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Wednesday, October 09, 2002 2:46 AM > Subject: Re: [lang] Proposal for *NEXT* version > > > > > > +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" (?!). > > -- > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
