[hibernate-dev] Re: HCANN evolution

Hi all, While investigating a case of too much memory being held after boot, I noticed Hibernate Commons Annotations's old design and patterns are a strong contributor to the problem. We talked many times about getting rid of it, yet we know it's not easy as we have a high level of coupling - but I believe we can achieve it in iterative steps, reducing the coupling. I now have a draft of patches which remove its capability to load classes and packages "by name"; this implies it removing any interaction with classloaders, and associated complexity; this will of course require some adaptation in ORM but it turns out its own code is also cleaner as a result (ORM's ClassLoaderService is preferred), so I'd like to proceed. Unless there are strong objections, I'll mark all those classes which I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN master (6). Then I'll release the next 5.x and propose the adaptation PR to ORM; since I'm not actually removing the functionality yet we still have the option to keep the ORM patches limited to a smaller scope, should there be any concerns regarding specific details (to be discussed in PRs), but I don't believe this should be necessary. I'd also like to release an HCANN 6 preview and have ORM6 use it. Among other benefits, this will leave the HCANN codebase significantly smaller and more focused on its core goals; I believe after this cleanup it looks much better and we might not need to fully get rid of it, for example it does solve the generics problem quite elegantly, so there's no need to throw that out too. Thanks, Sann _______________________________________________ hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s