On Tue, 19 Jan 2010 17:03:47 -0200, Howard Lewis Ship <[email protected]>
wrote:
I'm doing some interesting work with changes to
ComponentClassTransformer right now; part of what I'm doing is to set
the stage for moving away from Javassist in the future.
Nice!
Increasingly, I'm building up new APIs that allow the transformations
on the component class to be expressed in terms of interfaces and
callbacks, and I'm decreasing the amount of "Javassist-psuedocode"
that gets written.
I have some experience in code generation (that's what I did in my
master's course) and I think you're in the right path: keep the generated
code to a minimum. Just glue code being generated, just link
PropertyConduitSource does. I guess this approach could also be used to
improve proxy generation, including annotations in service implementation
methods.
I wonder if this is worth pursuing; it's a lot of work. Done a
reduction in memory overhead and some of the other aspects (such as
page pool maintenance) justify the overhead for field access? Plus
there are some areas I'm not sure how to handle.
Tapestry doesn't use much memory nor CPU now. Considering it would take a
lot of time to be implemented, I think your time would be better spent in
other areas, even considering your idea something very interesting. I
don't think the method call overhead would be significant.
I suggest putting this suggestion in the roadmap for some not yet defined
future Tapestry release.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
