Hi Why do you think that the changes proposed has no reason behind? The change was not made for improve speed. Instead, the change was done to minimize the key size stored into session. There is always one key per view stored into session, so this part can quickly grow. I think the change has a lot of sense, and I have checked it using memory profilers.
The problem described in MYFACES-3638 can be solved just doing a null check before try to calculate the hash code. The inner classes are there and not outside the class, because only the state saving implementation needs to know that detail. I would like to keep the code in that way, even if it is a little bit verbose. Please take a look at: https://issues.apache.org/jira/browse/MYFACES-3563 You can see that the patches and the comments related to each design decision. If you want to propose something else, we can discuss it. I would like to keep in sync 2.0.x and 2.1.x as much time as possible, so if we do some changes, the preferred way is provide a patch so we can apply it in both branches. I know it is something bothersome, but there are people who appreciate that. Please reconsider the changes committed in MYFACES-3638. regards, Leonardo Uribe 2012/11/13 Mark Struberg <[email protected]>: > Hi folks! > > It is perfectly fine if we disable some debug and reload stuff if we are in > ProjectStage.Production. > > But imo we are currently switching around way too much functionality. E.g. I > see absolutely no reason for changing the caching key strategy dynamically. > That makes it almost impossible to get proper results and the performance > benefit is really negligible. > > Wdyt, should we revise all the usages of those cases? > > LieGrue, > strub >
