commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [clazz] New project? [was Re: [lang] Proposal for *NEXT* version]
Date Wed, 09 Oct 2002 15:47:43 GMT

+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" <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>


--
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