You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "John C. Dale" <jc...@downinthedesert.com> on 2003/08/09 15:16:37 UTC
Reflection Bad, OO and direct Method invocation Good...
I'm concerned about your mention of reflection. I really like
reflection, and think it has many useful applications in the application
development space, but should be kept out of any runtime application
that has stringent scalability and performance requirements. Although
reflection allows an incredibly generic way to solve many difficult
problems, and really opens the door to completely grandios perfectly
idealistic genericititousness ;) , a straight-forward OO approach to
solving the problems would 1) be faster and 2) be easier to read and
maintain. I've seen reflection based approaches work, and I've seen
them bomb.
One might argue that in a container based system that will eventually
support clustering and scalability doesn't have to worry about savoring
individual CPU cycles that might be expended needlessly with a
reflection-based design. Just add more hardware and the user experience
will be perpetually preserved. I would argue, however, that the
development community will be able to make better use of the product if
the rate at which additional hardware purchases becomes necessary
decreases. The philosophy, IMHO, should be to solve the problems at
hand with straight-forward OO solutions, and not to focus so much on
being generic and supporting n * infinity solutions up-front. Using
things like the Policy/Strategy pattern at well-selected locations will
afford the opportunity for pluggability without compromising
maintainability and performance.
Here are some dramatic results:
*Direct:*
public void init()
{
customer = new Customer();
}
public void run()
{
customer.work();
}
*Interface (Polymorphism):*
public void init()
{
customer = new Customer();
}
public void run()
{
Person person = (Person) customer;
person.work();
}
*Reflection:*
public void init()
{
customer = new Customer();
try
{
method = customer.getClass().getMethod("work", new Class[0]);
}
catch (Exception e)
{
}
params = new Object[0];
}
public void run()
{
try
{
method.invoke(customer, params);
}
catch (Exception e)
{
}
}
With 1000000 of the above code, here were the results:
JDK DirectTest InterfaceTest ReflectionTest
*Sun 1.4* 52 ms 54 ms 543 ms
*Sun 1.4 -server* 26 ms 56 ms 279 ms
*Sun 1.3* 124 ms 128 ms 2168 ms
*Sun 1.3 -server* 41 ms 58 ms 2012 ms
*IBM 1.3* 75 ms 78 ms 2134 ms
Reflection will significantly effect the performance of the system and
should be avoided for any runtime operations. Where it should and could
definitely be applied is with the dynamic generation and compilation of
code, or generation of metadata. Otherwise, even at the recommendation
of Sun, it should be avoided for runtime operations.
Best,
John C. Dale
Leo Simons wrote:
> Jason Dillon wrote:
>
>> PS. Can someone write up something about the current state of the
>> major component containers out there with a feature blurb... no soap
>> boxes, just the facts jack.
>
>
> What, no soap boxes? How on earth can anyone comply with that? ;) No
> wait,
> you weren't asking me anyway, were you. Ah, e-mail already typed. Bummer.
>
> = My Opinion =
>
> You should *not* be evaluating component containers. You should save
> this discussion
> for a later date and just code your way to 1.0. The basic design idea
> overview
> below should show that most of the architectural concepts behind all
> these containers are
> very similar. I've been experimenting (no, I will not plug it, you
> will just get confused) with
> some reflection that will allow any component written for any of the
> below to run in any
> of the other containers, and that is feasible, straightforward and
> performant.
>
> So write your components to plug in whatever you have, do a nice IoC,
> SoC, SAI, AOP
> setup, and you will be able to defer refactoring around an external
> container until much later.
>
> But that's my opinion, and I have now said it three times, and your a
> responsible adult
> (yep, its a guess, you could also be 11 years old :D). Switching
> soapbox mode off.
>
>
> = Disclaimer =
>
> Comparing component containers is comparing apples with pears. Avalon
> is by far the
> biggest 'generic' project at the moment, for example, but recent
> developments utilize AOP
> and interceptor architecture to support a much 'lighter'
> container-component api and
> contract. Indeed, picocontainer was started by an avalon elder from
> the firm belief that
> things should be simpler and smaller. So to actually evaluate all this
> stuff, you really should
> spend a day or so delving into the websites and the code of all these
> projects, and backing
> tech like nanning (nanning.codehaus.org) and aspectj
> (www.aspectj.org). I would start
> by looking at pico/nano and xwork, then take a look at the tutorials
> for avalon-merlin.
> The other projects have a smaller community atm, and I tend to value
> community size
> and vibe.
>
> Furthermore, I have strong opinions about stuff, and allegations to
> various projects, hence
> this is not an objective overview, even though I tried to make it
> somewhat objective.
>
>
> = Features/ design idea shorthands =
>
> IoC = Inversion of Control, the idea that an application is controlled
> from the top down
> SoC = Seperation of Coccerns, the idea that a class (aspect) should do
> one job and do it well
> SAI = Seperation of API from Implementation, the idea that you define
> and code to work
> interfaces
> AOP = Aspect Oriented Programming, mostly lightweight nowadays where
> you add a chain
> of interceptors around a method call that can handle orthogonal
> concerns
> DecP = Declarative Programming, where you use a declarative-style
> language (usually xml) to
> determine things like component wiring (ie your average tomcat
> config file, generalized)
> EBP = Event Based Programming, basically making the inter-object
> method call asynchronous
> and encapsulating such a call into some kind of event object that
> can be queued, modfied,
> etc
>
>
> = No particular order, incomplete list =
>
> http://wiki.opensymphony.com/space/XWork - IoC, SoC, SAI, AOP, DecP,
> EBP. Nearing
> 1.0 release. Used in webwork2 (a competitor to struts). EBP very basic
> only. Lean and mean,
> but not mature and some client-server web-layer specific assumptions.
> Don't like the XXXAware
> interfaces. Very vibrant and active community and many famous peeps
> with J2EE experience
> around at opensymphony.
>
> http://www.picocontainer.org/ and http://www.nanocontainer.org/ -
> IoC, SoC, SAI, AOP, DecP. 1.0 beta releases. Lean and mean and very
> extensible and
> embeddable, developed by smart XP peeps, some stuff already in use in
> some apps, but
> otherwise pretty much alpha. I love picocontainer and the way they're
> doing the project.
> The dev community is intentionally kept small atm, but many peeps are
> watching this one.
>
> http://plexus.codehaus.org/ - IoC, SoC, SAI, DecP. Container supporting
> avalon-framework components. Used to be
> yet-another-novel-avalon-container, but I
> think they're growing to be container-component-contract-agnostic.
> Corporate backed
> development. Smart guys, not so much focussed on releases as on
> getting all the
> functionality they need (which is a lot) in place. Very much a
> pragmatic project.
>
> http://www.jcontainer.org/ - Not yet public container development
> (dubbed 'loom' IIRC) by a smart ex-avaloner 'n others. Haven't seen
> any code yet
> but my guess is it'll be good. The website says "move along" so you
> prolly should.
>
> http://www.springframework.org/ - haven't looked at in too much depth.
> Seems similar to
> nanocontainer and xwork. Think it has one active developer and a beta
> release. Some
> smart points made, but too much xml for my taste. Hoping to see some
> of this rolled into
> Xwork and/or pico.
>
> http://avalon.apache.org/ - IoC, SoC, SAI, DecP, EBP (EBP for fortress
> only). By far
> the oldest 'generic container' project. Big committer base, mature
> codebase, mature
> ASF project (which can be a good thing and a bad thing ;) rather
> extensive
> 'avalon-framework' (comparatively heavy compared to more recent
> developments)
> that defines the contracts between a component and a container. Has 3
> container projects to consider: avalon-phoenix, a mature microkernel
> design,
> avalon-fortress, similar in weight and featureset to something like
> nanocontainer with a
> 1.0 release (successor to avalon-ecm, the container used in (among
> other projects)
> apache-cocoon), and avalon-merlin, a more recent development which we
> _seem_
> to be converging on as the successor to all other previously produced
> containers. Merlin
> is further described in the email by Stephen Mcconnell. Arguably the
> biggest,
> most extensive and most dynamic IoC container implementation around
> (and hence
> also the most complex). Re: my earlier blurb on 'geronimo and avalon'
> for more
> yadayada.
>
> http://jakarta.apache.org/commons/sandbox/hivemind - haven't looked at
> in much detail, but seems
> very similar in scope and setup to avalon at first glance. Framework
> being refactored out
> of hibernate, one developer, still in alpha with no releases I think.
> No offense to Howard
> intended, but I think he's cut himself a rather big piece of the
> puzzle to recode from scratch
> at once. But I am an uninformed whiner, so I'm not going to comment
> further in the hope that
> Howard will just eventually see the light and direct his energy
> towards collaboration with the
> avalon peeps :P
>
>
> I am spending too much time on writing messages to this mailing list
> (it is nearly 3am over here).
> I promise this is the last message from me for two weeks :D
>
> g'night,
>
> - Leo
>
>
>
>
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Leo Simons <le...@apache.org>.
John C. Dale wrote:
> I have no problem with reflection for the instantiation of a policy
> *once* during the course of an applications' lifecycle. However,
> using reflection rampantly for every user request will result in the
> vaunted and oft feared big Oh catastrophy. If you have 1 + n
> reflection operations for every user request, the application
> performance relative to the reflection code will degrade exponentially
> with the increase of concurrent users to the system O(n exponential).
hey, guess what: we agree!
A container is basically there to manage an applications' lifecycle.
When your
components are up and running, the container should be next to invisible
(or at
least you should have that option). But startup is already so expensive
that a
little reflection isn't going to hurt. The same goes for stuff like
xml<->object
conversion like soap and many other setups.
> If its precise empirical data you're asking for, I would ask the same
> - 99%? ;)
let's settle on the 80/20 rule then :D.
> How does an application 'not care if it is subject to reflection'?
> Module isolation? Low coupling?
dynamic proxying is one way. Really careful interface design is another,
as is bytecode
manipulation.
regards,
- Leo, who wishes he'd learn to just shut up
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by "John C. Dale" <jc...@downinthedesert.com>.
I have no problem with reflection for the instantiation of a policy
*once* during the course of an applications' lifecycle. However, using
reflection rampantly for every user request will result in the vaunted
and oft feared big Oh catastrophy. If you have 1 + n reflection
operations for every user request, the application performance relative
to the reflection code will degrade exponentially with the increase of
concurrent users to the system O(n exponential).
If its precise empirical data you're asking for, I would ask the same -
99%? ;)
The bottleneck is *always* at the database, which is constrained by the
time it takes to shuttle bits-n-bytes back and forth from/to the
database. Software optimization efforts at that level are wasted. The
nice thing, though, is that database technology has advanced to the
extent that a 5ms query under no load doesn't degrade too fast under
heavy user load - unlike reflection.
I have a feeling that many of the core developers on the team have
already put an extensive amount of reflection into the system. I have
yet to see any code, but will be interested to do a performance
evaluation on the existing kernel (if there is one :) . Furthermore,
I'm very interested in using probing utilities to discover the extent to
which particular segments of code are slowing the system down.
How does an application 'not care if it is subject to reflection'?
Module isolation? Low coupling?
I'll reiterate that a straight forward OO implementation will be easier
to maintain than would something that relies heavily on being generic.
Usually, systems that are overly generic for the sake of saving
development time spend far too much time developing a generic framework.
my2c
Best,
John C. Dale
Leo Simons wrote:
> John C. Dale wrote:
>
>> I'm concerned about your mention of reflection. I really like
>> reflection, and think it has many useful applications in the
>> application development space, but should be kept out of any runtime
>> application that has stringent scalability and performance requirements.
>
>
> it should be kept out of *any* code that has stringent performance
> requirements.
> Indeed! One should know when to use the right tool.
>
> But in all applications I have ever developed using containers that
> use reflection
> operations, (usually to do instantiation and facilitate late binding),
> those operations
> have never turned out to be the bottleneck.
>
> 99% of time is spent doing I/O, waiting for locks, or doing actual
> processing.
> If the development time gained by using some ingenious proxying or
> reflection
> code you write once and use in the right place, is spent optimizing
> the bottleneck
> code, your app becomes lighting fast.
>
> The trick is to write most of your application so that it does not
> care whether
> it is subject to reflection of any kind at any point. If it turns out
> that's your
> bottleneck, you can always take it out and replace it with something
> efficient.
>
>> Here are some dramatic results:
>
>
> ehm. Why are they dramatic? Reflection is known to be slow, yes, but
> I've yet
> to see hard figures showing it being the bottleneck in any realistic
> system.
>
> cheers!
>
> - Leo
>
>
>
>
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Leo Simons <le...@apache.org>.
John C. Dale wrote:
> I'm concerned about your mention of reflection. I really like
> reflection, and think it has many useful applications in the
> application development space, but should be kept out of any runtime
> application that has stringent scalability and performance requirements.
it should be kept out of *any* code that has stringent performance
requirements.
Indeed! One should know when to use the right tool.
But in all applications I have ever developed using containers that use
reflection
operations, (usually to do instantiation and facilitate late binding),
those operations
have never turned out to be the bottleneck.
99% of time is spent doing I/O, waiting for locks, or doing actual
processing.
If the development time gained by using some ingenious proxying or
reflection
code you write once and use in the right place, is spent optimizing the
bottleneck
code, your app becomes lighting fast.
The trick is to write most of your application so that it does not care
whether
it is subject to reflection of any kind at any point. If it turns out
that's your
bottleneck, you can always take it out and replace it with something
efficient.
> Here are some dramatic results:
ehm. Why are they dramatic? Reflection is known to be slow, yes, but
I've yet
to see hard figures showing it being the bottleneck in any realistic system.
cheers!
- Leo
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Frankie Lam <fr...@mindless.com>.
>From what I saw from JBoss implementation (in debugger only, I have never
digged into the source code), it uses a proxy to construct a value object
dynamically using reflection. 100 reflections aren't that much when you have
* a single row *, but when you encounter a table with, say, 40 fields and
you want to load 1000 records, then it takes 40000 reflection operations. In
addition, persistence is essential to any J2EE applications. So if there are
10 users requesting data per second, then it's 400000 operations. Of course
it isn't that much when you count CPU cycles.
But the point is: Why do we want to stress the CPU on the operations that we
can save?
Best regards,
Frankie
----- Original Message -----
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Saturday, August 09, 2003 11:05 PM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...
> On Sat, 9 Aug 2003, Frankie Lam wrote:
> > I fully agree with you and the benchmark you made is really persuasive
=)
> > I would like to raise a point that the disadvantages of reflection are
more
> > apparant when the methods are called frequently. JBoss CMP
implementation
> > is, AFAIK, reflection-based and its performance is really disappointing.
I'd
> > prefer some sort of on-the-fly compilation mechanisms that need to be
done
> > once only instead.
>
> Wait, I'm confused. Let's say a CMP operation uses 100 reflection
> operations (which is outrageous). According the the benchmark that you
> fully agree with, you have now officially wasted 0.0000223 seconds. Did
> you catch that on your stopwatch?
>
> Aaron
>
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Sat, 9 Aug 2003, Frankie Lam wrote:
> I fully agree with you and the benchmark you made is really persuasive =)
> I would like to raise a point that the disadvantages of reflection are more
> apparant when the methods are called frequently. JBoss CMP implementation
> is, AFAIK, reflection-based and its performance is really disappointing. I'd
> prefer some sort of on-the-fly compilation mechanisms that need to be done
> once only instead.
Wait, I'm confused. Let's say a CMP operation uses 100 reflection
operations (which is outrageous). According the the benchmark that you
fully agree with, you have now officially wasted 0.0000223 seconds. Did
you catch that on your stopwatch?
Aaron
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Frankie Lam <fr...@mindless.com>.
I fully agree with you and the benchmark you made is really persuasive =)
I would like to raise a point that the disadvantages of reflection are more
apparant when the methods are called frequently. JBoss CMP implementation
is, AFAIK, reflection-based and its performance is really disappointing. I'd
prefer some sort of on-the-fly compilation mechanisms that need to be done
once only instead.
Best regards,
Frankie
----- Original Message -----
From: John C. Dale
To: geronimo-dev@incubator.apache.org
Sent: Saturday, August 09, 2003 9:16 PM
Subject: Reflection Bad, OO and direct Method invocation Good...
I'm concerned about your mention of reflection. I really like reflection,
and think it has many useful applications in the application development
space, but should be kept out of any runtime application that has stringent
scalability and performance requirements. Although reflection allows an
incredibly generic way to solve many difficult problems, and really opens
the door to completely grandios perfectly idealistic genericititousness ;)
, a straight-forward OO approach to solving the problems would 1) be faster
and 2) be easier to read and maintain. I've seen reflection based
approaches work, and I've seen them bomb.
One might argue that in a container based system that will eventually
support clustering and scalability doesn't have to worry about savoring
individual CPU cycles that might be expended needlessly with a
reflection-based design. Just add more hardware and the user experience
will be perpetually preserved. I would argue, however, that the development
community will be able to make better use of the product if the rate at
which additional hardware purchases becomes necessary decreases. The
philosophy, IMHO, should be to solve the problems at hand with
straight-forward OO solutions, and not to focus so much on being generic and
supporting n * infinity solutions up-front. Using things like the
Policy/Strategy pattern at well-selected locations will afford the
opportunity for pluggability without compromising maintainability and
performance.
Here are some dramatic results:
Direct:
public void init()
{
customer = new Customer();
}
public void run()
{
customer.work();
}
Interface (Polymorphism):
public void init()
{
customer = new Customer();
}
public void run()
{
Person person = (Person) customer;
person.work();
}
Reflection:
public void init()
{
customer = new Customer();
try
{
method = customer.getClass().getMethod("work", new Class[0]);
}
catch (Exception e)
{
}
params = new Object[0];
}
public void run()
{
try
{
method.invoke(customer, params);
}
catch (Exception e)
{
}
}
With 1000000 of the above code, here were the results:
JDKDirectTestInterfaceTestReflectionTest
Sun 1.452 ms54 ms543 ms
Sun 1.4 -server26 ms56 ms279 ms
Sun 1.3124 ms128 ms2168 ms
Sun 1.3 -server41 ms58 ms2012 ms
IBM 1.375 ms78 ms2134 ms
Reflection will significantly effect the performance of the system and
should be avoided for any runtime operations. Where it should and could
definitely be applied is with the dynamic generation and compilation of
code, or generation of metadata. Otherwise, even at the recommendation of
Sun, it should be avoided for runtime operations.
Best,
John C. Dale
RE: Reflection Bad, OO and direct Method invocation Good...
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
HiveMind includes some stuff refactored out of Tapestry, not Hibernate (that's Gavin King's LGPL O/R
mapping framework).
HiveMind makes use of Javassist (MPL) to generate classes on-the-fly. This sidesteps reflection in
a very nice, efficient way.
Javassist is very clever; it groks an approximation of Java language syntax (has some kind of parser
built in) and generates bytecode from that. Makes doing sophisticated bytecode generation very,
very easy.
I did some tests that showed that using Javassist was a bit faster than dynamic proxies, and a lot
more memory efficient.
Please direct all Tapestry questions to tapestry-user@jakarta.apache.org.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Alex Blewitt <Al...@ioshq.com>.
On Saturday, Aug 9, 2003, at 14:16 Europe/London, John C. Dale wrote:
> Although reflection allows an incredibly generic way to solve many
> difficult problems, and really opens the door to completely grandios
> perfectly idealistic genericititousness ;) , a straight-forward OO
> approach to solving the problems would 1) be faster and 2) be easier
> to read and maintain. I've seen reflection based approaches work, and
> I've seen them bomb.
I'd like to disagree with 1). Sun have done a lot of work in the more
recent VMs making reflection fly, just for this kind of purpose. With a
Method.invoke() you get a call-time similar to calling static methods
(which don't require any messy inheritance searching for the correct
method call in sub/super classes). Since the Method contains the
reference to the class that it's defined in, inheritance doesn't play a
part (unless that Method is defined as abstract, such as an interface
or abstract class, obviously ;-)
I'd completely agree with 2), though -- but I'd suggest that reflection
has its uses in low-level routines rather than in every step.
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by "John C. Dale" <jc...@downinthedesert.com>.
Aaron Mulder wrote:
>On Sat, 9 Aug 2003, John C. Dale wrote:
>
>
>>Microbenchmarks can in fact be misleading when we aren't talking about
>>as much as a factor of 10! Reflection, in the best case scenario below,
>>was a factor of 10 slower! The bottom line is that reflection takes a
>>lot more electricity than does non-reflection.
>>
>>
>
> No, really, it can be misleading by a factor of 10. The compiler
>or VM can "do things" (like inlining a method when you're testing the time
>it takes to call different kinds of methods) that totally defeat a
>microbenchmark. I will certainly agree that "reflection is significantly
>slower", but I don't think it's valuable to point to specific numbers on a
>benchmark like you showed.
>
>
So we're in agreement then that reflection is slower, regardless of the
benchmark's presence in my argument. I always like to have some
supporting empirical evidence - a habit, really...but as long as we're
in agreement on that point.
>
>
>>You are absolutely right in that the round trip to the database is going
>>to consume more time for the life of the user request than is a sequence
>>of reflection-based calls. That will always be the bottleneck in
>>systems that don't have any kind of intelligent middle-tier cache - but
>>wait, there's more!
>>
>>Entity EJBS are just that (a cache) aren't they? Through intelligent
>>caching and good design of our applications, we're able to avoid the
>>extra knocks on the database if the entity of our type with our PK has
>>already been loaded. This, in my mind, is one of the chief advantages
>>of using Entity Beans; throughput. This throughput will definitely be
>>impacted negatively if there are several reflection calls for each user
>>request as the system comes under (and maintains) load. Furthermore,
>>although the bottleneck is clearly the round trip to the database for
>>the hydration/storage of data, the time it takes to get to the point of
>>JDBC query invocation will be effected negatively if reflection is used
>>- this effect becomes more pronounced as the system comes under heavy
>>load. The sooner the JDBC query starts, the sooner it will finish.
>>
>>
>
> In my experience, slow EJB apps can be attributed to the frequency
>and nature of the JDBC calls and/or application problems far more often
>than the server technology. In other words, it's pretty rare to find an
>EJB performance problem that can't be addressed without altering something
>like whether the server uses reflection. And in response to "the JDBC
>request that starts faster finishes faster", granted, but I refer you to
>my response to Frankie -- you won't notice any difference if every JDBC
>request finishes 0.00002 seconds faster (and that's being generous).
>
>
And let's not forget the people writing the SQL - you are right IMHO,
but with one additional qualification. The SQL that is being executed
is far more often the culprite than is the JDBC implementation. In my
experience, I've found that stable releases of most JDBC drivers are
very nice. So much revolves around the application design (the web/EJB
app, not the container) and implementation, and we are *all* in
agreement that bad developers write bad apps no matter how fast/good the
platform.
>
>
>>I would also note that 'optimizing away' performance issues due to
>>reflection (assuming that the core of the system is based on reflection)
>>is MUCH easier to type than it is to implement. If we see the train
>>coming now, why don't we get out of the way...now?
>>
>>
>
> You're implicitly asserting that reflection has no advantage.
>Agreed, if reflection has no advantage and costs performance, we should
>avoid it. I would argue that such is not the case, and the reflection
>code:
>
> - is more straightforward/less buggy than generating custom Java code
>during deployment (due to comments, exception handling, version control,
>etc.)
>
> - is dramatically faster to start up then writing out Java code, running
>the compiler, and reading the classes back in
>
> - reduces the amount of code an EJB client is required to have access to
>(1 server JAR and the code written by the EJB developer, instead of 1
>server JAR plus 1 server JAR per EJB JAR in addition to the code written
>by the EJB developer)
>
> - has less of an impact on debugging (vs. getting errors originating in
>classes that the server generated)
>
> - allows common code such as passing control to a chain of interceptors
>to be written and compiled and tested in one place by a server developer,
>instead of being generated into every method in every EJB
>
> - gives the server developers more options for how to handle the passing
>of requests over the network, and again lets that code be written once and
>version controlled and so on rather than forcing us to maintain the code
>that writes the code.
>
> Well, that's what I can think of for now, and overall, I'd say
>it's well worth a few microseconds on every request.
>
>Aaron
>
>
>
>
I have yet to see the code, so I am happy to suspend judgement regarding
the advantage point until I get the opportunity to get a really critical
look at the implementation you have in mind. Coincidentally, you made
the point very well and also suggest an alternative that hasn't worked
in the past. It's almost as though you've argued this issue before.
hmmmm...
Thanks for taking the time to make your points, and they are well taken.
I will be watching the implementation closely and will be happy to
reverse-engineer documentation and do some performance probing to reduce
the risk(s) of embedding significant amounts of (hopefully isolated)
reflection into the kernel.
Best,
John C. Dale
Professional Services
Compuware
>
>
Re: [aspects] Re: Reflection Bad, OO and direct Method invocation Good...
Posted by James Strachan <ja...@yahoo.co.uk>.
Agreed. FWIW already AspectWerkz can dynamically weave aspects into
Java code at deployment time using a special ClassLoader which performs
the necessary bytecode swizzling to insert the aspects.
http://aspectwerkz.codehaus.org
On Sunday, August 10, 2003, at 05:10 pm, Jules Gosnell wrote:
> let me subvert this thread a little...
>
> for the future...
>
> If you step back a little and look again at the precompiled and
> dynamically aggregated containers, I think you would find that they
> could both be decomposed into aspects in a pretty similar way. The
> difference is simply in the choice of how to implement those aspects.
>
> The thing that I find exciting is that from only a little bit of
> reading around aspects it looks as if it will soon be possible (if it
> is not already) to weave the same set of aspects at either compile or
> deploy/run time. Whether the aspect guys will be able to be as
> efficient at deploy-time weaving as they can at compile-time is a
> matter for an aspect list, but I suspect that compile time weaved
> aspects will not be any slower than a custom compiled container and
> deploy-time weaving will be considerable more efficient than existing
> run time interceptor frameworks.
>
> So, in short, I think that the gap between compile time and deploy
> time container composition is probably shrinking into irrelevance,
> which is good news as it means that both teams can concentrate on a
> single impl - competition is good, but right now I think it should be
> all hands on deck to get something out there...
>
> Jules
>
>
> Greg Wilkins wrote:
>
>>
>> Even if we are able to support two or more EJB containers, I would
>> never recommend using different ones for development and deployment.
>> That, as you say, is just asking for inconsistencies to cause grief.
>>
>> But some users may choose to give up the benefits of the dynamics
>> during development for a compiled container - because either they
>> really want/need every nano seconds of latency reduced or because
>> their culture is opposed to dynamics on production machines.
>>
>> If there are really several diametrically opposed ways of doing
>> EJBs - then it would be great if geronimo could support them all.
>> But then I have little idea of the amount of work required to
>> come up with AbstractEJBContainer.
>>
>> cheers
>>
>>
>> Test Account wrote:
>>
>>> Greg,
>>>
>>> Absolutely, that was the gist of what I was trying to say,
>>> albeit,
>>> somewhat poorly. You want the fast dynamic development deployment
>>> capabilities while banging out endless refactorings. But when it
>>> comes time
>>> to deploy in a scalable environment you may need to eek every last
>>> drop of
>>> performance, so may need the compiled skeletons. It would be great
>>> to have
>>> both. The problem would be in guaranteeing consistency between the
>>> two
>>> paths. I wouldn't want to get differing behavior when running in
>>> development from when running in production.
>>>
>>> Enjoy,
>>>
>>> Craig
>>>
>>> ----- Original Message ----- From: "Greg Wilkins" <gr...@mortbay.com>
>>> To: <ge...@incubator.apache.org>
>>> Sent: Sunday, August 10, 2003 1:07 AM
>>> Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>>>
>>>
>>>
>>>> I don't know if this falls into the "too much choice is a bad thing"
>>>> arena, but would it not be good if we could have both a dynamic
>>>> jboss
>>>> inspired EJB container and a compiled EJB container (perhaps from
>>>> or inspired by the JOnAS folks??).
>>>>
>>>> --
>>>> Greg Wilkins<gr...@mortbay.com> Phone/fax: +44
>>>> 7092063462
>>>> Mort Bay Consulting Australia and UK.
>>>> http://www.mortbay.com
>>>>
>>
>>
>
>
> --
> /*************************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> * http://www.coredevelopers.net
> *************************************/
>
>
James
-------
http://radio.weblogs.com/0112098/
[aspects] Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
let me subvert this thread a little...
for the future...
If you step back a little and look again at the precompiled and
dynamically aggregated containers, I think you would find that they
could both be decomposed into aspects in a pretty similar way. The
difference is simply in the choice of how to implement those aspects.
The thing that I find exciting is that from only a little bit of reading
around aspects it looks as if it will soon be possible (if it is not
already) to weave the same set of aspects at either compile or
deploy/run time. Whether the aspect guys will be able to be as efficient
at deploy-time weaving as they can at compile-time is a matter for an
aspect list, but I suspect that compile time weaved aspects will not be
any slower than a custom compiled container and deploy-time weaving will
be considerable more efficient than existing run time interceptor
frameworks.
So, in short, I think that the gap between compile time and deploy time
container composition is probably shrinking into irrelevance, which is
good news as it means that both teams can concentrate on a single impl -
competition is good, but right now I think it should be all hands on
deck to get something out there...
Jules
Greg Wilkins wrote:
>
> Even if we are able to support two or more EJB containers, I would
> never recommend using different ones for development and deployment.
> That, as you say, is just asking for inconsistencies to cause grief.
>
> But some users may choose to give up the benefits of the dynamics
> during development for a compiled container - because either they
> really want/need every nano seconds of latency reduced or because
> their culture is opposed to dynamics on production machines.
>
> If there are really several diametrically opposed ways of doing
> EJBs - then it would be great if geronimo could support them all.
> But then I have little idea of the amount of work required to
> come up with AbstractEJBContainer.
>
> cheers
>
>
> Test Account wrote:
>
>> Greg,
>>
>> Absolutely, that was the gist of what I was trying to say, albeit,
>> somewhat poorly. You want the fast dynamic development deployment
>> capabilities while banging out endless refactorings. But when it
>> comes time
>> to deploy in a scalable environment you may need to eek every last
>> drop of
>> performance, so may need the compiled skeletons. It would be great
>> to have
>> both. The problem would be in guaranteeing consistency between the two
>> paths. I wouldn't want to get differing behavior when running in
>> development from when running in production.
>>
>> Enjoy,
>>
>> Craig
>>
>> ----- Original Message ----- From: "Greg Wilkins" <gr...@mortbay.com>
>> To: <ge...@incubator.apache.org>
>> Sent: Sunday, August 10, 2003 1:07 AM
>> Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>>
>>
>>
>>> I don't know if this falls into the "too much choice is a bad thing"
>>> arena, but would it not be good if we could have both a dynamic jboss
>>> inspired EJB container and a compiled EJB container (perhaps from
>>> or inspired by the JOnAS folks??).
>>>
>>> --
>>> Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
>>> Mort Bay Consulting Australia and UK. http://www.mortbay.com
>>>
>
>
--
/*************************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
* http://www.coredevelopers.net
*************************************/
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Greg Wilkins <gr...@mortbay.com>.
Even if we are able to support two or more EJB containers, I would
never recommend using different ones for development and deployment.
That, as you say, is just asking for inconsistencies to cause grief.
But some users may choose to give up the benefits of the dynamics
during development for a compiled container - because either they
really want/need every nano seconds of latency reduced or because
their culture is opposed to dynamics on production machines.
If there are really several diametrically opposed ways of doing
EJBs - then it would be great if geronimo could support them all.
But then I have little idea of the amount of work required to
come up with AbstractEJBContainer.
cheers
Test Account wrote:
> Greg,
>
> Absolutely, that was the gist of what I was trying to say, albeit,
> somewhat poorly. You want the fast dynamic development deployment
> capabilities while banging out endless refactorings. But when it comes time
> to deploy in a scalable environment you may need to eek every last drop of
> performance, so may need the compiled skeletons. It would be great to have
> both. The problem would be in guaranteeing consistency between the two
> paths. I wouldn't want to get differing behavior when running in
> development from when running in production.
>
> Enjoy,
>
> Craig
>
> ----- Original Message -----
> From: "Greg Wilkins" <gr...@mortbay.com>
> To: <ge...@incubator.apache.org>
> Sent: Sunday, August 10, 2003 1:07 AM
> Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>
>
>
>>I don't know if this falls into the "too much choice is a bad thing"
>>arena, but would it not be good if we could have both a dynamic jboss
>>inspired EJB container and a compiled EJB container (perhaps from
>>or inspired by the JOnAS folks??).
>>
>>--
>>Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
>>Mort Bay Consulting Australia and UK. http://www.mortbay.com
>>
--
Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Test Account <cm...@earthlink.net>.
Greg,
Absolutely, that was the gist of what I was trying to say, albeit,
somewhat poorly. You want the fast dynamic development deployment
capabilities while banging out endless refactorings. But when it comes time
to deploy in a scalable environment you may need to eek every last drop of
performance, so may need the compiled skeletons. It would be great to have
both. The problem would be in guaranteeing consistency between the two
paths. I wouldn't want to get differing behavior when running in
development from when running in production.
Enjoy,
Craig
----- Original Message -----
From: "Greg Wilkins" <gr...@mortbay.com>
To: <ge...@incubator.apache.org>
Sent: Sunday, August 10, 2003 1:07 AM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>
> I don't know if this falls into the "too much choice is a bad thing"
> arena, but would it not be good if we could have both a dynamic jboss
> inspired EJB container and a compiled EJB container (perhaps from
> or inspired by the JOnAS folks??).
>
> --
> Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
> Mort Bay Consulting Australia and UK. http://www.mortbay.com
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Greg Wilkins <gr...@mortbay.com>.
I don't know if this falls into the "too much choice is a bad thing"
arena, but would it not be good if we could have both a dynamic jboss
inspired EJB container and a compiled EJB container (perhaps from
or inspired by the JOnAS folks??).
--
Greg Wilkins<gr...@mortbay.com> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
I have to agree partially with Craig here. I would venture to say that
most of those many thousand users of JBoss use it for development where
they do not have to run a separate compiler (actually a code generator),
compile again, then package yet again and deploy. I agree that dynamic
proxies will be slower, but that doesn't mean that a class generator at
runtime couldn't take the place of that proxy. As a developer, I should
be able to take my EJBs, compiled once I might add, package and drop
into some deploy directory and let the container take it from there. It
is a massive time saver during development.
Robert
Test Account wrote:
> Reflection and dynamic proxies are a good thing in EJB containers. To
>bear this out, deploy and ear file on JBoss. Now deploy the same
>application on Orion/OC4J. Do this 1000s of times during development.
>Consider the time lost watching Orion complain and fail compiling generated
>classes. Consider the time the development team loses waiting for this step
>to occur repeatedly even when the deployment is successful. Now actually
>make a few requests on the application. Do you notice any difference?
> It seems that this issue may be related to the lazy loading development
>vs production deploy discussion in that a bifurcated deployment option *may*
>be of use. Anyone care to write an production option alternative to
>reflection because they believe in the savings? This is certainly something
>which can be done *should* it be demonstrable that reflection shows any
>degradation of performance in a working container.
>
>Craig
>
>
>
>
>
>----- Original Message -----
>From: "Aaron Mulder" <am...@alumni.princeton.edu>
>To: <ge...@incubator.apache.org>
>Sent: Saturday, August 09, 2003 9:38 AM
>Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>
>
>
>
>>On Sat, 9 Aug 2003, John C. Dale wrote:
>>
>>
>>>Microbenchmarks can in fact be misleading when we aren't talking about
>>>as much as a factor of 10! Reflection, in the best case scenario below,
>>>was a factor of 10 slower! The bottom line is that reflection takes a
>>>lot more electricity than does non-reflection.
>>>
>>>
>>No, really, it can be misleading by a factor of 10. The compiler
>>or VM can "do things" (like inlining a method when you're testing the time
>>it takes to call different kinds of methods) that totally defeat a
>>microbenchmark. I will certainly agree that "reflection is significantly
>>slower", but I don't think it's valuable to point to specific numbers on a
>>benchmark like you showed.
>>
>>
>>
>>>You are absolutely right in that the round trip to the database is going
>>>to consume more time for the life of the user request than is a sequence
>>>of reflection-based calls. That will always be the bottleneck in
>>>systems that don't have any kind of intelligent middle-tier cache - but
>>>wait, there's more!
>>>
>>>Entity EJBS are just that (a cache) aren't they? Through intelligent
>>>caching and good design of our applications, we're able to avoid the
>>>extra knocks on the database if the entity of our type with our PK has
>>>already been loaded. This, in my mind, is one of the chief advantages
>>>of using Entity Beans; throughput. This throughput will definitely be
>>>impacted negatively if there are several reflection calls for each user
>>>request as the system comes under (and maintains) load. Furthermore,
>>>although the bottleneck is clearly the round trip to the database for
>>>the hydration/storage of data, the time it takes to get to the point of
>>>JDBC query invocation will be effected negatively if reflection is used
>>>- this effect becomes more pronounced as the system comes under heavy
>>>load. The sooner the JDBC query starts, the sooner it will finish.
>>>
>>>
>>In my experience, slow EJB apps can be attributed to the frequency
>>and nature of the JDBC calls and/or application problems far more often
>>than the server technology. In other words, it's pretty rare to find an
>>EJB performance problem that can't be addressed without altering something
>>like whether the server uses reflection. And in response to "the JDBC
>>request that starts faster finishes faster", granted, but I refer you to
>>my response to Frankie -- you won't notice any difference if every JDBC
>>request finishes 0.00002 seconds faster (and that's being generous).
>>
>>
>>
>>>I would also note that 'optimizing away' performance issues due to
>>>reflection (assuming that the core of the system is based on reflection)
>>>is MUCH easier to type than it is to implement. If we see the train
>>>coming now, why don't we get out of the way...now?
>>>
>>>
>>You're implicitly asserting that reflection has no advantage.
>>Agreed, if reflection has no advantage and costs performance, we should
>>avoid it. I would argue that such is not the case, and the reflection
>>code:
>>
>> - is more straightforward/less buggy than generating custom Java code
>>during deployment (due to comments, exception handling, version control,
>>etc.)
>>
>> - is dramatically faster to start up then writing out Java code, running
>>the compiler, and reading the classes back in
>>
>> - reduces the amount of code an EJB client is required to have access to
>>(1 server JAR and the code written by the EJB developer, instead of 1
>>server JAR plus 1 server JAR per EJB JAR in addition to the code written
>>by the EJB developer)
>>
>> - has less of an impact on debugging (vs. getting errors originating in
>>classes that the server generated)
>>
>> - allows common code such as passing control to a chain of interceptors
>>to be written and compiled and tested in one place by a server developer,
>>instead of being generated into every method in every EJB
>>
>> - gives the server developers more options for how to handle the passing
>>of requests over the network, and again lets that code be written once and
>>version controlled and so on rather than forcing us to maintain the code
>>that writes the code.
>>
>>Well, that's what I can think of for now, and overall, I'd say
>>it's well worth a few microseconds on every request.
>>
>>Aaron
>>
>>
>>
>
>
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by "John C. Dale" <jc...@downinthedesert.com>.
Test Account wrote:
> Reflection and dynamic proxies are a good thing in EJB containers. To
>bear this out, deploy and ear file on JBoss. Now deploy the same
>application on Orion/OC4J. Do this 1000s of times during development.
>Consider the time lost watching Orion complain and fail compiling generated
>classes. Consider the time the development team loses waiting for this step
>to occur repeatedly even when the deployment is successful. Now actually
>make a few requests on the application. Do you notice any difference?
> It seems that this issue may be related to the lazy loading development
>vs production deploy discussion in that a bifurcated deployment option *may*
>be of use. Anyone care to write an production option alternative to
>reflection because they believe in the savings? This is certainly something
>which can be done *should* it be demonstrable that reflection shows any
>degradation of performance in a working container.
>
>Craig
>
>
>
>
Just one point on this. Any difference between the two containers would
never be noticed by a single human user/development. It is under load,
then thousands of potential concurrent users are dingin' the system that
we really might want to start being more frugal with CPU.
Your points are well taken, though.
John C. Dale
Professional Services
Compuware
>
>
>----- Original Message -----
>From: "Aaron Mulder" <am...@alumni.princeton.edu>
>To: <ge...@incubator.apache.org>
>Sent: Saturday, August 09, 2003 9:38 AM
>Subject: Re: Reflection Bad, OO and direct Method invocation Good...
>
>
>
>
>>On Sat, 9 Aug 2003, John C. Dale wrote:
>>
>>
>>>Microbenchmarks can in fact be misleading when we aren't talking about
>>>as much as a factor of 10! Reflection, in the best case scenario below,
>>>was a factor of 10 slower! The bottom line is that reflection takes a
>>>lot more electricity than does non-reflection.
>>>
>>>
>>No, really, it can be misleading by a factor of 10. The compiler
>>or VM can "do things" (like inlining a method when you're testing the time
>>it takes to call different kinds of methods) that totally defeat a
>>microbenchmark. I will certainly agree that "reflection is significantly
>>slower", but I don't think it's valuable to point to specific numbers on a
>>benchmark like you showed.
>>
>>
>>
>>>You are absolutely right in that the round trip to the database is going
>>>to consume more time for the life of the user request than is a sequence
>>>of reflection-based calls. That will always be the bottleneck in
>>>systems that don't have any kind of intelligent middle-tier cache - but
>>>wait, there's more!
>>>
>>>Entity EJBS are just that (a cache) aren't they? Through intelligent
>>>caching and good design of our applications, we're able to avoid the
>>>extra knocks on the database if the entity of our type with our PK has
>>>already been loaded. This, in my mind, is one of the chief advantages
>>>of using Entity Beans; throughput. This throughput will definitely be
>>>impacted negatively if there are several reflection calls for each user
>>>request as the system comes under (and maintains) load. Furthermore,
>>>although the bottleneck is clearly the round trip to the database for
>>>the hydration/storage of data, the time it takes to get to the point of
>>>JDBC query invocation will be effected negatively if reflection is used
>>>- this effect becomes more pronounced as the system comes under heavy
>>>load. The sooner the JDBC query starts, the sooner it will finish.
>>>
>>>
>>In my experience, slow EJB apps can be attributed to the frequency
>>and nature of the JDBC calls and/or application problems far more often
>>than the server technology. In other words, it's pretty rare to find an
>>EJB performance problem that can't be addressed without altering something
>>like whether the server uses reflection. And in response to "the JDBC
>>request that starts faster finishes faster", granted, but I refer you to
>>my response to Frankie -- you won't notice any difference if every JDBC
>>request finishes 0.00002 seconds faster (and that's being generous).
>>
>>
>>
>>>I would also note that 'optimizing away' performance issues due to
>>>reflection (assuming that the core of the system is based on reflection)
>>>is MUCH easier to type than it is to implement. If we see the train
>>>coming now, why don't we get out of the way...now?
>>>
>>>
>>You're implicitly asserting that reflection has no advantage.
>>Agreed, if reflection has no advantage and costs performance, we should
>>avoid it. I would argue that such is not the case, and the reflection
>>code:
>>
>> - is more straightforward/less buggy than generating custom Java code
>>during deployment (due to comments, exception handling, version control,
>>etc.)
>>
>> - is dramatically faster to start up then writing out Java code, running
>>the compiler, and reading the classes back in
>>
>> - reduces the amount of code an EJB client is required to have access to
>>(1 server JAR and the code written by the EJB developer, instead of 1
>>server JAR plus 1 server JAR per EJB JAR in addition to the code written
>>by the EJB developer)
>>
>> - has less of an impact on debugging (vs. getting errors originating in
>>classes that the server generated)
>>
>> - allows common code such as passing control to a chain of interceptors
>>to be written and compiled and tested in one place by a server developer,
>>instead of being generated into every method in every EJB
>>
>> - gives the server developers more options for how to handle the passing
>>of requests over the network, and again lets that code be written once and
>>version controlled and so on rather than forcing us to maintain the code
>>that writes the code.
>>
>>Well, that's what I can think of for now, and overall, I'd say
>>it's well worth a few microseconds on every request.
>>
>>Aaron
>>
>>
>>
>
>
>
>
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Test Account <cm...@earthlink.net>.
Reflection and dynamic proxies are a good thing in EJB containers. To
bear this out, deploy and ear file on JBoss. Now deploy the same
application on Orion/OC4J. Do this 1000s of times during development.
Consider the time lost watching Orion complain and fail compiling generated
classes. Consider the time the development team loses waiting for this step
to occur repeatedly even when the deployment is successful. Now actually
make a few requests on the application. Do you notice any difference?
It seems that this issue may be related to the lazy loading development
vs production deploy discussion in that a bifurcated deployment option *may*
be of use. Anyone care to write an production option alternative to
reflection because they believe in the savings? This is certainly something
which can be done *should* it be demonstrable that reflection shows any
degradation of performance in a working container.
Craig
----- Original Message -----
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Saturday, August 09, 2003 9:38 AM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...
> On Sat, 9 Aug 2003, John C. Dale wrote:
> > Microbenchmarks can in fact be misleading when we aren't talking about
> > as much as a factor of 10! Reflection, in the best case scenario below,
> > was a factor of 10 slower! The bottom line is that reflection takes a
> > lot more electricity than does non-reflection.
>
> No, really, it can be misleading by a factor of 10. The compiler
> or VM can "do things" (like inlining a method when you're testing the time
> it takes to call different kinds of methods) that totally defeat a
> microbenchmark. I will certainly agree that "reflection is significantly
> slower", but I don't think it's valuable to point to specific numbers on a
> benchmark like you showed.
>
> > You are absolutely right in that the round trip to the database is going
> > to consume more time for the life of the user request than is a sequence
> > of reflection-based calls. That will always be the bottleneck in
> > systems that don't have any kind of intelligent middle-tier cache - but
> > wait, there's more!
> >
> > Entity EJBS are just that (a cache) aren't they? Through intelligent
> > caching and good design of our applications, we're able to avoid the
> > extra knocks on the database if the entity of our type with our PK has
> > already been loaded. This, in my mind, is one of the chief advantages
> > of using Entity Beans; throughput. This throughput will definitely be
> > impacted negatively if there are several reflection calls for each user
> > request as the system comes under (and maintains) load. Furthermore,
> > although the bottleneck is clearly the round trip to the database for
> > the hydration/storage of data, the time it takes to get to the point of
> > JDBC query invocation will be effected negatively if reflection is used
> > - this effect becomes more pronounced as the system comes under heavy
> > load. The sooner the JDBC query starts, the sooner it will finish.
>
> In my experience, slow EJB apps can be attributed to the frequency
> and nature of the JDBC calls and/or application problems far more often
> than the server technology. In other words, it's pretty rare to find an
> EJB performance problem that can't be addressed without altering something
> like whether the server uses reflection. And in response to "the JDBC
> request that starts faster finishes faster", granted, but I refer you to
> my response to Frankie -- you won't notice any difference if every JDBC
> request finishes 0.00002 seconds faster (and that's being generous).
>
> > I would also note that 'optimizing away' performance issues due to
> > reflection (assuming that the core of the system is based on reflection)
> > is MUCH easier to type than it is to implement. If we see the train
> > coming now, why don't we get out of the way...now?
>
> You're implicitly asserting that reflection has no advantage.
> Agreed, if reflection has no advantage and costs performance, we should
> avoid it. I would argue that such is not the case, and the reflection
> code:
>
> - is more straightforward/less buggy than generating custom Java code
> during deployment (due to comments, exception handling, version control,
> etc.)
>
> - is dramatically faster to start up then writing out Java code, running
> the compiler, and reading the classes back in
>
> - reduces the amount of code an EJB client is required to have access to
> (1 server JAR and the code written by the EJB developer, instead of 1
> server JAR plus 1 server JAR per EJB JAR in addition to the code written
> by the EJB developer)
>
> - has less of an impact on debugging (vs. getting errors originating in
> classes that the server generated)
>
> - allows common code such as passing control to a chain of interceptors
> to be written and compiled and tested in one place by a server developer,
> instead of being generated into every method in every EJB
>
> - gives the server developers more options for how to handle the passing
> of requests over the network, and again lets that code be written once and
> version controlled and so on rather than forcing us to maintain the code
> that writes the code.
>
> Well, that's what I can think of for now, and overall, I'd say
> it's well worth a few microseconds on every request.
>
> Aaron
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Saturday, August 9, 2003, at 10:38 AM, Aaron Mulder wrote:
> On Sat, 9 Aug 2003, John C. Dale wrote:
>> Microbenchmarks can in fact be misleading when we aren't talking about
>> as much as a factor of 10! Reflection, in the best case scenario
>> below,
>> was a factor of 10 slower! The bottom line is that reflection takes a
>> lot more electricity than does non-reflection.
>
> No, really, it can be misleading by a factor of 10. The compiler
> or VM can "do things" (like inlining a method when you're testing the
> time
> it takes to call different kinds of methods) that totally defeat a
> microbenchmark. I will certainly agree that "reflection is
> significantly
> slower", but I don't think it's valuable to point to specific numbers
> on a
> benchmark like you showed.
To truly test the speed of a direct invocation you need to give the VM
something it cannot inline. The only way I know how to do that is to
make the method you are calling just under the maximum method size, 64k.
-dain
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Sat, 9 Aug 2003, John C. Dale wrote:
> Microbenchmarks can in fact be misleading when we aren't talking about
> as much as a factor of 10! Reflection, in the best case scenario below,
> was a factor of 10 slower! The bottom line is that reflection takes a
> lot more electricity than does non-reflection.
No, really, it can be misleading by a factor of 10. The compiler
or VM can "do things" (like inlining a method when you're testing the time
it takes to call different kinds of methods) that totally defeat a
microbenchmark. I will certainly agree that "reflection is significantly
slower", but I don't think it's valuable to point to specific numbers on a
benchmark like you showed.
> You are absolutely right in that the round trip to the database is going
> to consume more time for the life of the user request than is a sequence
> of reflection-based calls. That will always be the bottleneck in
> systems that don't have any kind of intelligent middle-tier cache - but
> wait, there's more!
>
> Entity EJBS are just that (a cache) aren't they? Through intelligent
> caching and good design of our applications, we're able to avoid the
> extra knocks on the database if the entity of our type with our PK has
> already been loaded. This, in my mind, is one of the chief advantages
> of using Entity Beans; throughput. This throughput will definitely be
> impacted negatively if there are several reflection calls for each user
> request as the system comes under (and maintains) load. Furthermore,
> although the bottleneck is clearly the round trip to the database for
> the hydration/storage of data, the time it takes to get to the point of
> JDBC query invocation will be effected negatively if reflection is used
> - this effect becomes more pronounced as the system comes under heavy
> load. The sooner the JDBC query starts, the sooner it will finish.
In my experience, slow EJB apps can be attributed to the frequency
and nature of the JDBC calls and/or application problems far more often
than the server technology. In other words, it's pretty rare to find an
EJB performance problem that can't be addressed without altering something
like whether the server uses reflection. And in response to "the JDBC
request that starts faster finishes faster", granted, but I refer you to
my response to Frankie -- you won't notice any difference if every JDBC
request finishes 0.00002 seconds faster (and that's being generous).
> I would also note that 'optimizing away' performance issues due to
> reflection (assuming that the core of the system is based on reflection)
> is MUCH easier to type than it is to implement. If we see the train
> coming now, why don't we get out of the way...now?
You're implicitly asserting that reflection has no advantage.
Agreed, if reflection has no advantage and costs performance, we should
avoid it. I would argue that such is not the case, and the reflection
code:
- is more straightforward/less buggy than generating custom Java code
during deployment (due to comments, exception handling, version control,
etc.)
- is dramatically faster to start up then writing out Java code, running
the compiler, and reading the classes back in
- reduces the amount of code an EJB client is required to have access to
(1 server JAR and the code written by the EJB developer, instead of 1
server JAR plus 1 server JAR per EJB JAR in addition to the code written
by the EJB developer)
- has less of an impact on debugging (vs. getting errors originating in
classes that the server generated)
- allows common code such as passing control to a chain of interceptors
to be written and compiled and tested in one place by a server developer,
instead of being generated into every method in every EJB
- gives the server developers more options for how to handle the passing
of requests over the network, and again lets that code be written once and
version controlled and so on rather than forcing us to maintain the code
that writes the code.
Well, that's what I can think of for now, and overall, I'd say
it's well worth a few microseconds on every request.
Aaron
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by "John C. Dale" <jc...@downinthedesert.com>.
Microbenchmarks can in fact be misleading when we aren't talking about
as much as a factor of 10! Reflection, in the best case scenario below,
was a factor of 10 slower! The bottom line is that reflection takes a
lot more electricity than does non-reflection.
You are absolutely right in that the round trip to the database is going
to consume more time for the life of the user request than is a sequence
of reflection-based calls. That will always be the bottleneck in
systems that don't have any kind of intelligent middle-tier cache - but
wait, there's more!
Entity EJBS are just that (a cache) aren't they? Through intelligent
caching and good design of our applications, we're able to avoid the
extra knocks on the database if the entity of our type with our PK has
already been loaded. This, in my mind, is one of the chief advantages
of using Entity Beans; throughput. This throughput will definitely be
impacted negatively if there are several reflection calls for each user
request as the system comes under (and maintains) load. Furthermore,
although the bottleneck is clearly the round trip to the database for
the hydration/storage of data, the time it takes to get to the point of
JDBC query invocation will be effected negatively if reflection is used
- this effect becomes more pronounced as the system comes under heavy
load. The sooner the JDBC query starts, the sooner it will finish.
I would also note that 'optimizing away' performance issues due to
reflection (assuming that the core of the system is based on reflection)
is MUCH easier to type than it is to implement. If we see the train
coming now, why don't we get out of the way...now?
Best,
John C. Dale
Professional Services
Compuware
Aaron Mulder wrote:
> First of all, can we agree that microbenchmarks are dangerous?
>
> But all that aside, try 1 million HTTP requests, or 1 million
>iterations of a JDBC query, and then provide a ratio between JDBC/HTTP
>time and reflection time. If you can perform a million requests of either
>type in 30 seconds I'd be shocked, and that's two orders of magnitude.
>
> IMHO, reflection is something that can be optimized away later,
>once it becomes the bottleneck on performance. I don't think we need to
>avoid it from the outset, because I don't think it will be the bottleneck
>at the outset.
>
>Aaron
>
>On Sat, 9 Aug 2003, John C. Dale wrote:
>
>
>>I'm concerned about your mention of reflection. I really like
>>reflection, and think it has many useful applications in the application
>>development space, but should be kept out of any runtime application
>>that has stringent scalability and performance requirements. Although
>>reflection allows an incredibly generic way to solve many difficult
>>problems, and really opens the door to completely grandios perfectly
>>idealistic genericititousness ;) , a straight-forward OO approach to
>>solving the problems would 1) be faster and 2) be easier to read and
>>maintain. I've seen reflection based approaches work, and I've seen
>>them bomb.
>>
>>One might argue that in a container based system that will eventually
>>support clustering and scalability doesn't have to worry about savoring
>>individual CPU cycles that might be expended needlessly with a
>>reflection-based design. Just add more hardware and the user experience
>>will be perpetually preserved. I would argue, however, that the
>>development community will be able to make better use of the product if
>>the rate at which additional hardware purchases becomes necessary
>>decreases. The philosophy, IMHO, should be to solve the problems at
>>hand with straight-forward OO solutions, and not to focus so much on
>>being generic and supporting n * infinity solutions up-front. Using
>>things like the Policy/Strategy pattern at well-selected locations will
>>afford the opportunity for pluggability without compromising
>>maintainability and performance.
>>
>>Here are some dramatic results:
>>
>>*Direct:*
>>
>>public void init()
>>{
>> customer = new Customer();
>>}
>>
>>public void run()
>>{
>> customer.work();
>>}
>>
>>
>>*Interface (Polymorphism):*
>>
>>public void init()
>>{
>> customer = new Customer();
>>}
>>public void run()
>>{
>> Person person = (Person) customer;
>> person.work();
>>}
>>
>>
>>*Reflection:*
>>
>>public void init()
>>{
>> customer = new Customer();
>> try
>> {
>> method = customer.getClass().getMethod("work", new Class[0]);
>> }
>> catch (Exception e)
>> {
>> }
>>
>> params = new Object[0];
>>}
>>
>>public void run()
>>{
>> try
>> {
>> method.invoke(customer, params);
>> }
>> catch (Exception e)
>> {
>> }
>>}
>>
>>
>>With 1000000 of the above code, here were the results:
>>
>>JDK DirectTest InterfaceTest ReflectionTest
>>*Sun 1.4* 52 ms 54 ms 543 ms
>>*Sun 1.4 -server* 26 ms 56 ms 279 ms
>>*Sun 1.3* 124 ms 128 ms 2168 ms
>>*Sun 1.3 -server* 41 ms 58 ms 2012 ms
>>*IBM 1.3* 75 ms 78 ms 2134 ms
>>
>>
>>Reflection will significantly effect the performance of the system and
>>should be avoided for any runtime operations. Where it should and could
>>definitely be applied is with the dynamic generation and compilation of
>>code, or generation of metadata. Otherwise, even at the recommendation
>>of Sun, it should be avoided for runtime operations.
>>
>>Best,
>>
>>John C. Dale
>>
>>Leo Simons wrote:
>>
>>
>>
>>>Jason Dillon wrote:
>>>
>>>
>>>
>>>>PS. Can someone write up something about the current state of the
>>>>major component containers out there with a feature blurb... no soap
>>>>boxes, just the facts jack.
>>>>
>>>>
>>>What, no soap boxes? How on earth can anyone comply with that? ;) No
>>>wait,
>>>you weren't asking me anyway, were you. Ah, e-mail already typed. Bummer.
>>>
>>>= My Opinion =
>>>
>>>You should *not* be evaluating component containers. You should save
>>>this discussion
>>>for a later date and just code your way to 1.0. The basic design idea
>>>overview
>>>below should show that most of the architectural concepts behind all
>>>these containers are
>>>very similar. I've been experimenting (no, I will not plug it, you
>>>will just get confused) with
>>>some reflection that will allow any component written for any of the
>>>below to run in any
>>>of the other containers, and that is feasible, straightforward and
>>>performant.
>>>
>>>So write your components to plug in whatever you have, do a nice IoC,
>>>SoC, SAI, AOP
>>>setup, and you will be able to defer refactoring around an external
>>>container until much later.
>>>
>>>But that's my opinion, and I have now said it three times, and your a
>>>responsible adult
>>>(yep, its a guess, you could also be 11 years old :D). Switching
>>>soapbox mode off.
>>>
>>>
>>>= Disclaimer =
>>>
>>>Comparing component containers is comparing apples with pears. Avalon
>>>is by far the
>>>biggest 'generic' project at the moment, for example, but recent
>>>developments utilize AOP
>>>and interceptor architecture to support a much 'lighter'
>>>container-component api and
>>>contract. Indeed, picocontainer was started by an avalon elder from
>>>the firm belief that
>>>things should be simpler and smaller. So to actually evaluate all this
>>>stuff, you really should
>>>spend a day or so delving into the websites and the code of all these
>>>projects, and backing
>>>tech like nanning (nanning.codehaus.org) and aspectj
>>>(www.aspectj.org). I would start
>>>by looking at pico/nano and xwork, then take a look at the tutorials
>>>for avalon-merlin.
>>>The other projects have a smaller community atm, and I tend to value
>>>community size
>>>and vibe.
>>>
>>>Furthermore, I have strong opinions about stuff, and allegations to
>>>various projects, hence
>>>this is not an objective overview, even though I tried to make it
>>>somewhat objective.
>>>
>>>
>>>= Features/ design idea shorthands =
>>>
>>>IoC = Inversion of Control, the idea that an application is controlled
>>>from the top down
>>>SoC = Seperation of Coccerns, the idea that a class (aspect) should do
>>>one job and do it well
>>>SAI = Seperation of API from Implementation, the idea that you define
>>>and code to work
>>> interfaces
>>>AOP = Aspect Oriented Programming, mostly lightweight nowadays where
>>>you add a chain
>>> of interceptors around a method call that can handle orthogonal
>>>concerns
>>>DecP = Declarative Programming, where you use a declarative-style
>>>language (usually xml) to
>>> determine things like component wiring (ie your average tomcat
>>>config file, generalized)
>>>EBP = Event Based Programming, basically making the inter-object
>>>method call asynchronous
>>> and encapsulating such a call into some kind of event object that
>>>can be queued, modfied,
>>> etc
>>>
>>>
>>>= No particular order, incomplete list =
>>>
>>>http://wiki.opensymphony.com/space/XWork - IoC, SoC, SAI, AOP, DecP,
>>>EBP. Nearing
>>>1.0 release. Used in webwork2 (a competitor to struts). EBP very basic
>>>only. Lean and mean,
>>>but not mature and some client-server web-layer specific assumptions.
>>>Don't like the XXXAware
>>>interfaces. Very vibrant and active community and many famous peeps
>>>with J2EE experience
>>>around at opensymphony.
>>>
>>>http://www.picocontainer.org/ and http://www.nanocontainer.org/ -
>>>IoC, SoC, SAI, AOP, DecP. 1.0 beta releases. Lean and mean and very
>>>extensible and
>>>embeddable, developed by smart XP peeps, some stuff already in use in
>>>some apps, but
>>>otherwise pretty much alpha. I love picocontainer and the way they're
>>>doing the project.
>>>The dev community is intentionally kept small atm, but many peeps are
>>>watching this one.
>>>
>>>http://plexus.codehaus.org/ - IoC, SoC, SAI, DecP. Container supporting
>>>avalon-framework components. Used to be
>>>yet-another-novel-avalon-container, but I
>>>think they're growing to be container-component-contract-agnostic.
>>>Corporate backed
>>>development. Smart guys, not so much focussed on releases as on
>>>getting all the
>>>functionality they need (which is a lot) in place. Very much a
>>>pragmatic project.
>>>
>>>http://www.jcontainer.org/ - Not yet public container development
>>>(dubbed 'loom' IIRC) by a smart ex-avaloner 'n others. Haven't seen
>>>any code yet
>>>but my guess is it'll be good. The website says "move along" so you
>>>prolly should.
>>>
>>>http://www.springframework.org/ - haven't looked at in too much depth.
>>>Seems similar to
>>>nanocontainer and xwork. Think it has one active developer and a beta
>>>release. Some
>>>smart points made, but too much xml for my taste. Hoping to see some
>>>of this rolled into
>>>Xwork and/or pico.
>>>
>>>http://avalon.apache.org/ - IoC, SoC, SAI, DecP, EBP (EBP for fortress
>>>only). By far
>>>the oldest 'generic container' project. Big committer base, mature
>>>codebase, mature
>>>ASF project (which can be a good thing and a bad thing ;) rather
>>>extensive
>>>'avalon-framework' (comparatively heavy compared to more recent
>>>developments)
>>>that defines the contracts between a component and a container. Has 3
>>>container projects to consider: avalon-phoenix, a mature microkernel
>>>design,
>>>avalon-fortress, similar in weight and featureset to something like
>>>nanocontainer with a
>>>1.0 release (successor to avalon-ecm, the container used in (among
>>>other projects)
>>>apache-cocoon), and avalon-merlin, a more recent development which we
>>>_seem_
>>>to be converging on as the successor to all other previously produced
>>>containers. Merlin
>>>is further described in the email by Stephen Mcconnell. Arguably the
>>>biggest,
>>>most extensive and most dynamic IoC container implementation around
>>>(and hence
>>>also the most complex). Re: my earlier blurb on 'geronimo and avalon'
>>>for more
>>>yadayada.
>>>
>>>http://jakarta.apache.org/commons/sandbox/hivemind - haven't looked at
>>>in much detail, but seems
>>>very similar in scope and setup to avalon at first glance. Framework
>>>being refactored out
>>>of hibernate, one developer, still in alpha with no releases I think.
>>>No offense to Howard
>>>intended, but I think he's cut himself a rather big piece of the
>>>puzzle to recode from scratch
>>>at once. But I am an uninformed whiner, so I'm not going to comment
>>>further in the hope that
>>>Howard will just eventually see the light and direct his energy
>>>towards collaboration with the
>>>avalon peeps :P
>>>
>>>
>>>I am spending too much time on writing messages to this mailing list
>>>(it is nearly 3am over here).
>>>I promise this is the last message from me for two weeks :D
>>>
>>>g'night,
>>>
>>>- Leo
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
Re: Reflection Bad, OO and direct Method invocation Good...
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
First of all, can we agree that microbenchmarks are dangerous?
But all that aside, try 1 million HTTP requests, or 1 million
iterations of a JDBC query, and then provide a ratio between JDBC/HTTP
time and reflection time. If you can perform a million requests of either
type in 30 seconds I'd be shocked, and that's two orders of magnitude.
IMHO, reflection is something that can be optimized away later,
once it becomes the bottleneck on performance. I don't think we need to
avoid it from the outset, because I don't think it will be the bottleneck
at the outset.
Aaron
On Sat, 9 Aug 2003, John C. Dale wrote:
> I'm concerned about your mention of reflection. I really like
> reflection, and think it has many useful applications in the application
> development space, but should be kept out of any runtime application
> that has stringent scalability and performance requirements. Although
> reflection allows an incredibly generic way to solve many difficult
> problems, and really opens the door to completely grandios perfectly
> idealistic genericititousness ;) , a straight-forward OO approach to
> solving the problems would 1) be faster and 2) be easier to read and
> maintain. I've seen reflection based approaches work, and I've seen
> them bomb.
>
> One might argue that in a container based system that will eventually
> support clustering and scalability doesn't have to worry about savoring
> individual CPU cycles that might be expended needlessly with a
> reflection-based design. Just add more hardware and the user experience
> will be perpetually preserved. I would argue, however, that the
> development community will be able to make better use of the product if
> the rate at which additional hardware purchases becomes necessary
> decreases. The philosophy, IMHO, should be to solve the problems at
> hand with straight-forward OO solutions, and not to focus so much on
> being generic and supporting n * infinity solutions up-front. Using
> things like the Policy/Strategy pattern at well-selected locations will
> afford the opportunity for pluggability without compromising
> maintainability and performance.
>
> Here are some dramatic results:
>
> *Direct:*
>
> public void init()
> {
> customer = new Customer();
> }
>
> public void run()
> {
> customer.work();
> }
>
>
> *Interface (Polymorphism):*
>
> public void init()
> {
> customer = new Customer();
> }
> public void run()
> {
> Person person = (Person) customer;
> person.work();
> }
>
>
> *Reflection:*
>
> public void init()
> {
> customer = new Customer();
> try
> {
> method = customer.getClass().getMethod("work", new Class[0]);
> }
> catch (Exception e)
> {
> }
>
> params = new Object[0];
> }
>
> public void run()
> {
> try
> {
> method.invoke(customer, params);
> }
> catch (Exception e)
> {
> }
> }
>
>
> With 1000000 of the above code, here were the results:
>
> JDK DirectTest InterfaceTest ReflectionTest
> *Sun 1.4* 52 ms 54 ms 543 ms
> *Sun 1.4 -server* 26 ms 56 ms 279 ms
> *Sun 1.3* 124 ms 128 ms 2168 ms
> *Sun 1.3 -server* 41 ms 58 ms 2012 ms
> *IBM 1.3* 75 ms 78 ms 2134 ms
>
>
> Reflection will significantly effect the performance of the system and
> should be avoided for any runtime operations. Where it should and could
> definitely be applied is with the dynamic generation and compilation of
> code, or generation of metadata. Otherwise, even at the recommendation
> of Sun, it should be avoided for runtime operations.
>
> Best,
>
> John C. Dale
>
> Leo Simons wrote:
>
> > Jason Dillon wrote:
> >
> >> PS. Can someone write up something about the current state of the
> >> major component containers out there with a feature blurb... no soap
> >> boxes, just the facts jack.
> >
> >
> > What, no soap boxes? How on earth can anyone comply with that? ;) No
> > wait,
> > you weren't asking me anyway, were you. Ah, e-mail already typed. Bummer.
> >
> > = My Opinion =
> >
> > You should *not* be evaluating component containers. You should save
> > this discussion
> > for a later date and just code your way to 1.0. The basic design idea
> > overview
> > below should show that most of the architectural concepts behind all
> > these containers are
> > very similar. I've been experimenting (no, I will not plug it, you
> > will just get confused) with
> > some reflection that will allow any component written for any of the
> > below to run in any
> > of the other containers, and that is feasible, straightforward and
> > performant.
> >
> > So write your components to plug in whatever you have, do a nice IoC,
> > SoC, SAI, AOP
> > setup, and you will be able to defer refactoring around an external
> > container until much later.
> >
> > But that's my opinion, and I have now said it three times, and your a
> > responsible adult
> > (yep, its a guess, you could also be 11 years old :D). Switching
> > soapbox mode off.
> >
> >
> > = Disclaimer =
> >
> > Comparing component containers is comparing apples with pears. Avalon
> > is by far the
> > biggest 'generic' project at the moment, for example, but recent
> > developments utilize AOP
> > and interceptor architecture to support a much 'lighter'
> > container-component api and
> > contract. Indeed, picocontainer was started by an avalon elder from
> > the firm belief that
> > things should be simpler and smaller. So to actually evaluate all this
> > stuff, you really should
> > spend a day or so delving into the websites and the code of all these
> > projects, and backing
> > tech like nanning (nanning.codehaus.org) and aspectj
> > (www.aspectj.org). I would start
> > by looking at pico/nano and xwork, then take a look at the tutorials
> > for avalon-merlin.
> > The other projects have a smaller community atm, and I tend to value
> > community size
> > and vibe.
> >
> > Furthermore, I have strong opinions about stuff, and allegations to
> > various projects, hence
> > this is not an objective overview, even though I tried to make it
> > somewhat objective.
> >
> >
> > = Features/ design idea shorthands =
> >
> > IoC = Inversion of Control, the idea that an application is controlled
> > from the top down
> > SoC = Seperation of Coccerns, the idea that a class (aspect) should do
> > one job and do it well
> > SAI = Seperation of API from Implementation, the idea that you define
> > and code to work
> > interfaces
> > AOP = Aspect Oriented Programming, mostly lightweight nowadays where
> > you add a chain
> > of interceptors around a method call that can handle orthogonal
> > concerns
> > DecP = Declarative Programming, where you use a declarative-style
> > language (usually xml) to
> > determine things like component wiring (ie your average tomcat
> > config file, generalized)
> > EBP = Event Based Programming, basically making the inter-object
> > method call asynchronous
> > and encapsulating such a call into some kind of event object that
> > can be queued, modfied,
> > etc
> >
> >
> > = No particular order, incomplete list =
> >
> > http://wiki.opensymphony.com/space/XWork - IoC, SoC, SAI, AOP, DecP,
> > EBP. Nearing
> > 1.0 release. Used in webwork2 (a competitor to struts). EBP very basic
> > only. Lean and mean,
> > but not mature and some client-server web-layer specific assumptions.
> > Don't like the XXXAware
> > interfaces. Very vibrant and active community and many famous peeps
> > with J2EE experience
> > around at opensymphony.
> >
> > http://www.picocontainer.org/ and http://www.nanocontainer.org/ -
> > IoC, SoC, SAI, AOP, DecP. 1.0 beta releases. Lean and mean and very
> > extensible and
> > embeddable, developed by smart XP peeps, some stuff already in use in
> > some apps, but
> > otherwise pretty much alpha. I love picocontainer and the way they're
> > doing the project.
> > The dev community is intentionally kept small atm, but many peeps are
> > watching this one.
> >
> > http://plexus.codehaus.org/ - IoC, SoC, SAI, DecP. Container supporting
> > avalon-framework components. Used to be
> > yet-another-novel-avalon-container, but I
> > think they're growing to be container-component-contract-agnostic.
> > Corporate backed
> > development. Smart guys, not so much focussed on releases as on
> > getting all the
> > functionality they need (which is a lot) in place. Very much a
> > pragmatic project.
> >
> > http://www.jcontainer.org/ - Not yet public container development
> > (dubbed 'loom' IIRC) by a smart ex-avaloner 'n others. Haven't seen
> > any code yet
> > but my guess is it'll be good. The website says "move along" so you
> > prolly should.
> >
> > http://www.springframework.org/ - haven't looked at in too much depth.
> > Seems similar to
> > nanocontainer and xwork. Think it has one active developer and a beta
> > release. Some
> > smart points made, but too much xml for my taste. Hoping to see some
> > of this rolled into
> > Xwork and/or pico.
> >
> > http://avalon.apache.org/ - IoC, SoC, SAI, DecP, EBP (EBP for fortress
> > only). By far
> > the oldest 'generic container' project. Big committer base, mature
> > codebase, mature
> > ASF project (which can be a good thing and a bad thing ;) rather
> > extensive
> > 'avalon-framework' (comparatively heavy compared to more recent
> > developments)
> > that defines the contracts between a component and a container. Has 3
> > container projects to consider: avalon-phoenix, a mature microkernel
> > design,
> > avalon-fortress, similar in weight and featureset to something like
> > nanocontainer with a
> > 1.0 release (successor to avalon-ecm, the container used in (among
> > other projects)
> > apache-cocoon), and avalon-merlin, a more recent development which we
> > _seem_
> > to be converging on as the successor to all other previously produced
> > containers. Merlin
> > is further described in the email by Stephen Mcconnell. Arguably the
> > biggest,
> > most extensive and most dynamic IoC container implementation around
> > (and hence
> > also the most complex). Re: my earlier blurb on 'geronimo and avalon'
> > for more
> > yadayada.
> >
> > http://jakarta.apache.org/commons/sandbox/hivemind - haven't looked at
> > in much detail, but seems
> > very similar in scope and setup to avalon at first glance. Framework
> > being refactored out
> > of hibernate, one developer, still in alpha with no releases I think.
> > No offense to Howard
> > intended, but I think he's cut himself a rather big piece of the
> > puzzle to recode from scratch
> > at once. But I am an uninformed whiner, so I'm not going to comment
> > further in the hope that
> > Howard will just eventually see the light and direct his energy
> > towards collaboration with the
> > avalon peeps :P
> >
> >
> > I am spending too much time on writing messages to this mailing list
> > (it is nearly 3am over here).
> > I promise this is the last message from me for two weeks :D
> >
> > g'night,
> >
> > - Leo
> >
> >
> >
> >
> >
>
>