[hibernate-dev] Re: HCANN evolution
Sure, I'll do that.
Regarding Validator, I believe it doesn't use it?
On Thu, 22 Oct 2020 at 14:02, Yoann Rodiere <yoann(a)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
> yoann(a)hibernate.org
>
>
> On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero <sanne(a)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(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