On Thu, 22 Oct 2020 at 14:50, Steve Ebersole <steve(a)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 <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
>> _______________________________________________
>> 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