Hi, Looks good to me, but please ping me when you submit the PR. HCANN is used in Hibernate Search as well, and not just the ORM module. If we ever need to have two ORM modules in Hibernate Search (one for ORM 5 and one for ORM 6), I'll need to be sure that Hibernate Search can switch from HCANN 5 to 6 without recompiling...
Yoann Rodière Hibernate Team yo...@hibernate.org On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero <sa...@hibernate.org> wrote: > 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@lists.jboss.org > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
