Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jx2oO-0004jB-1H for pljava-dev@arkaria.postgresql.org; Sun, 19 Jul 2020 06:28:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jx2oK-0007v6-A3 for pljava-dev@arkaria.postgresql.org; Sun, 19 Jul 2020 06:28:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jx2oK-0007uz-2A for pljava-dev@lists.postgresql.org; Sun, 19 Jul 2020 06:28:32 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jx2oD-0007sS-Er for pljava-dev@lists.postgresql.org; Sun, 19 Jul 2020 06:28:30 +0000 Received: by mail-ej1-x62b.google.com with SMTP id n22so12011033ejy.3 for ; Sat, 18 Jul 2020 23:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FZ19fq5lHi6DplwIH3K5tCZfoECtlIJu9CHX12iD4KU=; b=WG+Flz8VjPR6bmBwfuWKvJaJX8bynz6sn4UW2prcjAMm5AVsqao/xZQvml8twT5xuU /MAdhn2uVoIp31LPvLzeQbeR4hyLiFAwB4tVvbA3VXvc/l1UP83RSCwqVvO8NG1ee2GF X/OccebWRUTeLNFwiADbtNZUGCI39vB7RwHrV5YQ9zgHvUjW9JiCh6sfHWnSDFqVCPQM MJbptZ1esLKOYgu3i8hWPfdNaO0MjinaoEUcajGz7jDQ212KQIJk7TLFhJ8qRwh9ahVt 5qeDgEqaXW0mEwZovt1Oz/nLZ+4W7kk9wUTlbHBUCknATbr9tUDeg+o+Bw9DWbmf3FiI s/Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FZ19fq5lHi6DplwIH3K5tCZfoECtlIJu9CHX12iD4KU=; b=OMO+z3/yLiPYxhqc/urCZ4bftANQjC+iUHIvw5FZcPeGFmWCcZIsrEu65JahDn25s9 Sx/BVPSunLX3vwQJDW7DRfKgYpC+52lWZZ/UMP05bx7zIUrwNt9EEQHC77zcuY2GyMpA UFIOw22aIOaFbdeJEYu24YCcz7u+JfUWSzu6BuISEY6ie22Xih+/13kOGUWnVjsyyZ25 3h+JSAe1xKxRmil5WBhIrcmh6fsHAUuxMt607RJUkoLc9kWljujGUMnH6XEcu9skFxvF c4rubJ0pE4YEevO/T4KUQO59VkbdUwfHAQIu7O9Q8mqNBW+/jsKM1hE+Domw9Gd9AXLv f8qA== X-Gm-Message-State: AOAM530Eut7iUOJOSyQrJBojjFdaLBcbT9xuivuE/CjxyaXrtSPcDuPM KaAlIeVkUnAbUP7ZSvBs8tHwxLMWXrMvhR0IxNGkSVed X-Google-Smtp-Source: ABdhPJz64gTuSYXbw859qd5cdcFXsh0V2+uWjqvsr793TvQIG/cjKJl96YYNzNMzC1EE77K3PyFU1DEFmO1F0zHzbbQ= X-Received: by 2002:a17:906:b15:: with SMTP id u21mr15951717ejg.520.1595140102732; Sat, 18 Jul 2020 23:28:22 -0700 (PDT) MIME-Version: 1.0 References: <5F077926.2050806@anastigmatix.net> <5F07C2D5.5050904@anastigmatix.net> <5F0D35BA.30904@anastigmatix.net> <5F0E3972.5070609@anastigmatix.net> <5F0F2DA2.5090603@anastigmatix.net> <5F12FF49.6090906@anastigmatix.net> <5F12FF80.5020208@anastigmatix.net> <5F1338F8.6030506@anastigmatix.net> <5F135B84.8070302@anastigmatix.net> In-Reply-To: <5F135B84.8070302@anastigmatix.net> From: Kartik Ohri Date: Sun, 19 Jul 2020 11:58:11 +0530 Message-ID: Subject: Re: PL/Java new build plugin To: Chapman Flack Cc: pljava-dev@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000030c1da05aac57ff5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000030c1da05aac57ff5 Content-Type: text/plain; charset="UTF-8" > > 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. --00000000000030c1da05aac57ff5 Content-Type: text/html; charset="UTF-8"
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.
--00000000000030c1da05aac57ff5--