Sure, I'll do that. Regarding Validator, I believe it doesn't use it?
On Thu, 22 Oct 2020 at 14:02, 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
