Sounds good, I'll take a look. Longer term, the best option from the perspective of ORM is to simply drop HCANN altogether in favor of Jandex + JAXB. In fact, I am considering playing with that on top of your work. It would be awesome to start dropping the things that hold us to including dom4j
On Thu, Oct 22, 2020 at 8:02 AM Yoann Rodiere <yo...@hibernate.org> wrote: > 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 _______________________________________________ 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
