commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject [clazz] New project? [was Re: [lang] Proposal for *NEXT* version]
Date Wed, 09 Oct 2002 08:23:11 GMT
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" <john@scioworks.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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:baliuka@centras.lt]
> > > > 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:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message