Re: PL/Java new build plugin

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.

In response to

Responses

Browse pljava-dev by date

  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