Re: [jbosscache-dev] New collections

Jason T. Greene wrote: >>> Ok, today I went ahead and made these changed (commit 6536). So >>> in case anything breaks, you know why :) I did run through the >>> unit tests locally though, with no failures. >> >> I think it did break a few things - see the tests in >> o.j.c.notifications. :-) > Ok, I'll take a look at those. I remember them passing for me before. This is fixed now. I never saw the failure because the failing test because I was executing the wrong test profile. I thought it finished a little too early :)

>> Also, looking at Immutables.immutableMapCopy(), isn't it >> inefficient that you attempt to call clone() using reflection, >> catch exceptions on failure, then try a copy constructor, catch >> exception on failure, and finally attempt a new HashMap()? Given >> that this would most likely be used with either a FastCopyHashMap >> or a HashMap, shouldn't we just check for instanceof of these >> types and use the copy constructor directly, especially given that >> there is hardly any performance diff between FCHM.clone() and it's >> copy constructor? > Yeah I was originally planning on doing a instanceof check on known > types, I just forgot to commit that update. It is using clone though. This is done now. It uses clone because the copy-ctor of almost all the maps increases the size of the table.

>> Cloneable is such an arse interface - they really should have >> exposed clone() as a public method there. Solves a lot of >> problems, no need for reflection, etc. > Yeah I agree it's a screwed up design. The other day I was thinking this would be so easy to fix in the JDK. Add a new interface called ReallyCloneable that extends Cloneable and requires the clone method. Then introduce a System.clone(Object object) which is smart enough to try ReallyCloneble first, and then barring that use reflection.