Okay, not to crap on everyone... So that method (List.size()) was 20% of the runtime for whatever reason.
As an experiment, I changed getChildren() to getChildrenMap() in NodeImpl, so I could mix in NodeSPI. Then I fixed up a few classes here and there. Life seemed good. This method seemed fixable...
But then... I reran the tests, but they failed. Oops! I fixed some casts in the LockingInterceptor. Tests hang. Curious, I searched for any additional dependencies on TreeCacheProxyImpl. Eclipse found like 93 references (many casts) to TreeCacheProxyImpl. All those would have to be changed for me to go futher...
My immediate reaction was: Fuck. 90 places in the code now depends directly on this class, I don't know how many are casts.
The only refactoring that makes sense is to fix existing node classes, retrofit TreeCache with CacheSPI and get rid of this shit. There's just no way I'd run 2.0 seeing what's in the sausage now.
And I don't see the value of the new API if it's just a ugly retrofit with worse performance. "-1" as they say...
Yeah, a lot of this is due to be sorted out now that 2.0.0 is in focus again. The TCPI stuff has been a bit of a hack as a temporary fix to get around making specific design decisions - such as methods like getChildren() and the bazillion casts. A lot of this goes away once we identify better what needs to be in the SPI interface. I don't expect there to be more than a couple of casts to TCPI, if at all, as this breaks the whole purpose of the interface.
You are looking at incomplete code, stitched together to make the Cache interface workable. Once the internals are complete things will be a lot quicker.