From: | Kartik Ohri <kartikohri13(at)gmail(dot)com> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | pljava-dev(at)lists(dot)postgresql(dot)org |
Subject: | Re: PL/Java new build plugin |
Date: | 2020-07-19 06:28:11 |
Message-ID: | CAASLQ4O=tYGASWB6F+PTiB2L3RbmHcVX8XAbKHyhwBDOodH1zg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pljava-dev |
>
> Aha! And it generates that using getPathFromArtifacts(), which just goes
> through its own dependency list and collects the jar names (which are
> maybe the exact same jar names its current ClassRealm loader is using).
>
> I wonder what would happen just making a dead-simple ClassLoader with
> two "parents" and otherwise no functionality of its own. Of course it
> could only have one real parent and an instance field for the 'extra' one.
>
> Create it so one 'parent' is the ClassRealm loader that loaded us, and the
> other is from getSystemClassLoader() (they changed the official name to
> "application class loader" but didn't rename the method). Have its
> findClass
> method just say "either parent A has it or parent B has it or I haven't
> heard of it, sorry."
>
> (In fact, findClass doesn't get called until the 'real' parent has already
> been checked, so it doesn't need to do anything besides check the 'extra'
> parent and return what it finds, if anything.)
>
There is an issue with calling findClass on the instance field because it
has protected visibility. loadClass on the other hand is public.
From | Date | Subject | |
---|---|---|---|
Next Message | Kartik Ohri | 2020-07-19 06:44:21 | Re: PL/Java new build plugin |
Previous Message | Chapman Flack | 2020-07-18 20:28:52 | Re: PL/Java new build plugin |