On Thu, 22 Oct 2020 at 14:50, Steve Ebersole <st...@hibernate.org> wrote: > > Sounds good, I'll take a look.
Thanks, here is a draft PR for ORM master: - https://github.com/hibernate/hibernate-orm/pull/3608 > > 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 +100 :) Further such steps should be easier after this. N.B. I'm considering these steps as a preparation step, I didn't yet address the core of the memory retention issue - I'll get to that next, having simplified the problem first. > > 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
