Hi, as discussed here: http://markmail.org/message/kca64ojdvb6em367?q=[core]+performance: +TagAttributeImpl+part+II:+object+allocations#query:[core]%20performance %3A%20TagAttributeImpl%20part%20II%3A%20object%20allocations+page:1 +mid:kca64ojdvb6em367+state:results
and here: http://markmail.org/search/?q=TagAttributeImpl+part+II%3A+object +allocations+%28cache+ELExpressions%29#query:TagAttributeImpl%20part% 20II%3A%20object%20allocations%20%28cache%20ELExpressions%29%20from%3A% 22Leonardo%20Uribe%22+page:1+mid:pmurllp3w73q6c6s+state:results we need to avoid unnecessary ValueExpression instances. Here is one idea: because we cannot wait for JCP (or I don't want to), prototype some improvements in sandbox, for example: 1) we can create MyFacesExpressionFactory with methods createTagValueExpression, createLocationValueExpression, createResourceLocationValueExpression .... 2) In myfaces-core-impl then create default implementation with same code as TagAttributeImpl.getValueExpression(FaceletContext, Class) has currently. 3) create new module myfaces-integration with additional implementations of MyFacesExpressionFactory. For example JUELOWBMyFacesExpressionFactory - create* methods of such implementation will create not wrapped expression but one instance of JUELCODIValueExpression. JUELCODIValueExpression will use inheritance from JUEL internal API (and some code from OWB). Of course it will need cooperation with JUEL/OWB developers (for example because de.odysseus.el.TreeValueExpression from JUEL is final class). Solution with inheritance is proposal only, I didn't try it yet. User must be sure that no other library wants to wrap ValueExpression. WDYT? Kočičák
