[jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

"alesj" wrote : "david.lloyd(a)jboss.com" wrote : | | What if there was a substantial speed increase and memory footprint decrease associated with doing so? That's the question I think we need to explore here. | | | No. | | As all the complex/slow processing should be done by the tool, pre-runtime. | Deserializing + reattaching annotation repository is O(1). | Again that's your opinion, but spec compliance isn't optional and this is what we all agreed to accomplish. If you want to reopen the question, go for it. "alesj" wrote : Sure, but that doesn't mean you should rewrite everything that you don't like. ;-) | btw: how is Remoting3 coming along ... :-) What else does it mean? I'm not rewriting things I don't like, I'm rewriting things that are not doing the job they're supposed to be doing, so that they do. I'm not arbitrarily picking on projects. I'm measurably improving things. Every single thing I've rewritten is measurably better than it was before. Logging is 10%+ faster and now supports JDK logging as well as Log4j, and is fully integrated with MC. Threads are now fully POJO-ized as well, and abstracted behind a clean and simple API which makes it very easy to plug in alternate implementations - without adding lots of extra abstraction. VFS is next because it's the next-most-significant blip on the radar in terms of performance problems which is something we are all supposed to be working towards fixing. Remoting is coming along quite well. The Marshalling subproject (another evil rewrite!) is now being used by Infinispan (another evil rewrite!) with some great performance numbers. The XNIO subproject is also successful and will be the core of network configuration on AS 6. Were it not for the VFS work I'm doing now, I'd have 3.1 released already. Not all rewrites are bad. It is not reasonable to maintain a deathgrip on existing code out of a sense of personal attachment. One must always be ready to throw away what they have if it's defective in design. Knowing this makes one rethink design in terms of avoiding lock-in. That's why my projects all have so few dependencies and impose few or no dependencies on their consumers. My experience shows that it's more cost-effective in the long run to get rid of problems early on, rather than continually applying small patches. I'm sorry if you disagree but I think my approach is fairly well proven at this point, and I can and have been able to back that up with numbers rather than just a stream of increasing problems and complaints, which is what I think the logical culmination of the "use existing codebases at all costs" approach. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261330#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...