One slightly better way to get more eyes on an issue
is to file it in the JSF spec project on www.java.net.
Then it'll go off to the full "dev" list, and will be officially
tracked.
That said, it's rather unlikely that anything will happen
for JSF 1.2. At this point, it'd have to be a rather crit
Adam Winer wrote:
Fair enough, but as with most performance questions.
actual numbers are of the essence. I've had thoroughly
brilliant (so I thought) insights into how to make code faster
that, after measuring, didn't do a darn thing. And since
you're adding memory allocations (which, at high
Fair enough, but as with most performance questions.
actual numbers are of the essence. I've had thoroughly
brilliant (so I thought) insights into how to make code faster
that, after measuring, didn't do a darn thing. And since
you're adding memory allocations (which, at higher
server loads, will
Hi Adam,
Thanks very much for taking a look at this patch.
I agree that when explicitly avoiding a return value the patch causes
two String "header" objects and one char array to be created: a string
header + char-array when the prefix is added, and then a string header
(but no data buffer) w
This seems of questionable utility for performance. On the one hand,
yes, you're avoiding invoking the ValueBinding. On the other hand,
you're now creating somewhere around three bonus objects (two
String objects and one char array) every time you set *any* attribute,
value-bound or not. (Object
[ http://issues.apache.org/jira/browse/MYFACES-920?page=all ]
Simon Kitching updated MYFACES-920:
---
Attachment: _ComponentAttributesMap.java.patch.txt
UIComponentTagUtils.java.patch.txt
> Avoid invoking value-bindings during component in
