You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ola Berg <ol...@arkitema.se> on 2002/06/16 20:52:20 UTC
Re: [reflect] Proposal: (WAS [BeanUtils] etc...)
>The multitude of potential users of this component is
>huge, they all have
>current solutions and they all have some peculiarities about them. �For this
>new component to be successful, we will need to address all of those
>requirements, which calls for an abstract, configurable and customizable
>architecture.
I don\'t agree. Well, of course there are many users that do a lot of stuff in their reflection/introspection packages.
But IMO reflect should be a mere utility for easy use of reflection (reducing complexity and awkwardness in java.lang.reflect). Other cool things (like automatic configuration of beans from command line or config files) do belong in other packages (both examples above should go in a Configuration framework?).
Those are _users_ of reflection, they don\'t faciliate reflection in themselves. This doesn\'t call for plugable architectures, and if we end up with it I believe that we have over-engineered them and missed a clean separation of concerns.
I think of a Reflection class with static methods like
Reflection.set( Object bean, String propertyName, Object value);
Object o = Reflection.get( Object bean, String propertyName);
Reflection.add( Object bean, String propertyName, Object value);
Reflection.put( Object bean, String propertyName, Object key, Object value);
Reflection.set( Object bean, String propertyName, int index, Object value);
Object result = Reflection.call( Object bean, String methodName, Object [] parameterValues);
The internals of a Reflection class could very well use a plugable framework for insertion of new handy methods and cached lookup of reflection Method objects (like all getters in a class etc), and some of this functionality should probably be pluggable (for people to insert new bean-like naming conventions, maybe using Predicate on methods).
But main functionality exposed as handy methods.
/O
--------------------
ola.berg@arkitema.se
0733 - 99 99 17
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [reflect] Proposal: (WAS [BeanUtils] etc...)
Posted by Juozas Baliuka <ba...@centras.lt>.
We can implement some reflection things too.
It is about code generation. Some ideas was discussed on BCEL list.
We have some code in simplestore, this code is not persistence specific and
can be used
for any aspects, simplestore and XORM on sourceforge uses it to implement
persistence aspect. This code generates interceptor/proxy/enhancer on the
fly in memory like
java.reflect.Proxy doe's.
> Ola,
>
> Perhaps I misunderstood what the proposal was all about. My understanding
> was that it was after introspection rather than pure reflection. When I
> hear the word "reflection", the list of features that comes to my mind is:
>
> 1. List of methods
> 2. List of constructors
> 3. List of fields
> 4. List of inner classes
>
> And that's about it - all of this is basically done by the JVM itself.
> Sure, we can put some veneer over it - but I thought this proposal called
> for something more.
>
> The word "introspection" is one level above reflection: beans, bean
> properties etc. These may be implemented using reflection or not. This
is
> where the diversity begins. Pretty much everybody supports JavaBeans.
But
> then on top of that we all add our extensions: BeanUtils support
DynaClass,
> JXPath has JXPathBeanInfo, etc. We are all expanding the notion of a Bean
> beyond the official JavaBean specification. Strictly speaking, even Ant
> with its mapping of "foobar" to "getFooBar" is extending the
specification.
>
> There is a layer above introspection, which is abstract models and mapping
> those models to Java artifacts. For example, there is a JSR that maps UML
> to EJB. IMO, that stuff is much too abstract for our purposes. We don't
> want to end up with something like MOF, which is complex to the point of
> being almost esoteric.
>
> I am not convinced we can do anything about Java Reflection - it is built
> natively into the JVM. Introspection though is a different matter.
>
> - Dmitri
>
>
> > >The multitude of potential users of this component is
> > >huge, they all have
> > >current solutions and they all have some peculiarities about them. For
> this
> > >new component to be successful, we will need to address all of those
> > >requirements, which calls for an abstract, configurable and
customizable
> > >architecture.
> >
> > I don\'t agree. Well, of course there are many users that do a lot of
> stuff in their reflection/introspection packages.
> >
> > But IMO reflect should be a mere utility for easy use of reflection
> (reducing complexity and awkwardness in java.lang.reflect). Other cool
> things (like automatic configuration of beans from command line or config
> files) do belong in other packages (both examples above should go in a
> Configuration framework?).
> >
> > Those are _users_ of reflection, they don\'t faciliate reflection in
> themselves. This doesn\'t call for plugable architectures, and if we end
up
> with it I believe that we have over-engineered them and missed a clean
> separation of concerns.
> >
> > I think of a Reflection class with static methods like
> >
> > Reflection.set( Object bean, String propertyName, Object value);
> >
> > Object o = Reflection.get( Object bean, String propertyName);
> >
> > Reflection.add( Object bean, String propertyName, Object value);
> >
> > Reflection.put( Object bean, String propertyName, Object key, Object
> value);
> >
> > Reflection.set( Object bean, String propertyName, int index, Object
> value);
> >
> > Object result = Reflection.call( Object bean, String methodName, Object
[]
> parameterValues);
> >
> > The internals of a Reflection class could very well use a plugable
> framework for insertion of new handy methods and cached lookup of
reflection
> Method objects (like all getters in a class etc), and some of this
> functionality should probably be pluggable (for people to insert new
> bean-like naming conventions, maybe using Predicate on methods).
> >
> > But main functionality exposed as handy methods.
> >
> > /O
> >
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [reflect] Proposal: (WAS [BeanUtils] etc...)
Posted by Dmitri Plotnikov <dm...@apache.org>.
Ola,
Perhaps I misunderstood what the proposal was all about. My understanding
was that it was after introspection rather than pure reflection. When I
hear the word "reflection", the list of features that comes to my mind is:
1. List of methods
2. List of constructors
3. List of fields
4. List of inner classes
And that's about it - all of this is basically done by the JVM itself.
Sure, we can put some veneer over it - but I thought this proposal called
for something more.
The word "introspection" is one level above reflection: beans, bean
properties etc. These may be implemented using reflection or not. This is
where the diversity begins. Pretty much everybody supports JavaBeans. But
then on top of that we all add our extensions: BeanUtils support DynaClass,
JXPath has JXPathBeanInfo, etc. We are all expanding the notion of a Bean
beyond the official JavaBean specification. Strictly speaking, even Ant
with its mapping of "foobar" to "getFooBar" is extending the specification.
There is a layer above introspection, which is abstract models and mapping
those models to Java artifacts. For example, there is a JSR that maps UML
to EJB. IMO, that stuff is much too abstract for our purposes. We don't
want to end up with something like MOF, which is complex to the point of
being almost esoteric.
I am not convinced we can do anything about Java Reflection - it is built
natively into the JVM. Introspection though is a different matter.
- Dmitri
> >The multitude of potential users of this component is
> >huge, they all have
> >current solutions and they all have some peculiarities about them. For
this
> >new component to be successful, we will need to address all of those
> >requirements, which calls for an abstract, configurable and customizable
> >architecture.
>
> I don\'t agree. Well, of course there are many users that do a lot of
stuff in their reflection/introspection packages.
>
> But IMO reflect should be a mere utility for easy use of reflection
(reducing complexity and awkwardness in java.lang.reflect). Other cool
things (like automatic configuration of beans from command line or config
files) do belong in other packages (both examples above should go in a
Configuration framework?).
>
> Those are _users_ of reflection, they don\'t faciliate reflection in
themselves. This doesn\'t call for plugable architectures, and if we end up
with it I believe that we have over-engineered them and missed a clean
separation of concerns.
>
> I think of a Reflection class with static methods like
>
> Reflection.set( Object bean, String propertyName, Object value);
>
> Object o = Reflection.get( Object bean, String propertyName);
>
> Reflection.add( Object bean, String propertyName, Object value);
>
> Reflection.put( Object bean, String propertyName, Object key, Object
value);
>
> Reflection.set( Object bean, String propertyName, int index, Object
value);
>
> Object result = Reflection.call( Object bean, String methodName, Object []
parameterValues);
>
> The internals of a Reflection class could very well use a plugable
framework for insertion of new handy methods and cached lookup of reflection
Method objects (like all getters in a class etc), and some of this
functionality should probably be pluggable (for people to insert new
bean-like naming conventions, maybe using Predicate on methods).
>
> But main functionality exposed as handy methods.
>
> /O
>
> --------------------
> ola.berg@arkitema.se
> 0733 - 99 99 17
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [reflect] Proposal: (WAS [BeanUtils] etc...)
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Getting the balance right will be important. I think of Digster here
(although I must confess to not having actually used it!). Digester allows
different projects to setup rules as to how XML is parsed. Some standard
rules are provided. But projects can add their own (that is the key, thus a
config project can have its own rules).
Your simple flat methods are fine for beans following a strict naming
convention. But not all _classes_ do. That doesn't mean that there is no
place for an interface like you suggest, but I'm just trying to be fair to
the requirements yet to be gathered.
Stephen
----- Original Message -----
From: "Ola Berg" <ol...@arkitema.se>
To: <co...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 7:52 PM
Subject: Re: [reflect] Proposal: (WAS [BeanUtils] etc...)
> >The multitude of potential users of this component is
> >huge, they all have
> >current solutions and they all have some peculiarities about them. For
this
> >new component to be successful, we will need to address all of those
> >requirements, which calls for an abstract, configurable and customizable
> >architecture.
>
> I don\'t agree. Well, of course there are many users that do a lot of
stuff in their reflection/introspection packages.
>
> But IMO reflect should be a mere utility for easy use of reflection
(reducing complexity and awkwardness in java.lang.reflect). Other cool
things (like automatic configuration of beans from command line or config
files) do belong in other packages (both examples above should go in a
Configuration framework?).
>
> Those are _users_ of reflection, they don\'t faciliate reflection in
themselves. This doesn\'t call for plugable architectures, and if we end up
with it I believe that we have over-engineered them and missed a clean
separation of concerns.
>
> I think of a Reflection class with static methods like
>
> Reflection.set( Object bean, String propertyName, Object value);
>
> Object o = Reflection.get( Object bean, String propertyName);
>
> Reflection.add( Object bean, String propertyName, Object value);
>
> Reflection.put( Object bean, String propertyName, Object key, Object
value);
>
> Reflection.set( Object bean, String propertyName, int index, Object
value);
>
> Object result = Reflection.call( Object bean, String methodName, Object []
parameterValues);
>
> The internals of a Reflection class could very well use a plugable
framework for insertion of new handy methods and cached lookup of reflection
Method objects (like all getters in a class etc), and some of this
functionality should probably be pluggable (for people to insert new
bean-like naming conventions, maybe using Predicate on methods).
>
> But main functionality exposed as handy methods.
>
> /O
>
> --------------------
> ola.berg@arkitema.se
> 0733 - 99 99 17
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>