Subject: Re: PL/Java new build plugin
To: Kartik Ohri <kartikohri13@gmail.com>
References: 
 <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
 <5F0734AD.7060001@anastigmatix.net>
 <CAASLQ4PDcaAJ8fEwXXFW6XPakc7GCNVgPNGCxA8KYMzPDZw4+w@mail.gmail.com>
 <5F077926.2050806@anastigmatix.net>
 <CAASLQ4OuFQCiSMeypQtfRaAvj-4H-EAgszLwdAo6Tc1zS9B66g@mail.gmail.com>
 <5F07C2D5.5050904@anastigmatix.net>
 <CAASLQ4PSizkzBKyyfkp9ccJ1qDPLRLu6g2bo9cN-XuTzGQFGfQ@mail.gmail.com>
 <CAASLQ4P9zGxHda=HAGJ2eAa-oMmJtnPm=4a14mj4P-QpfFsYxg@mail.gmail.com>
 <5F0D35BA.30904@anastigmatix.net>
 <CAASLQ4NmornyOW8n-qyneLpDVPgV0Js=+=Eys6bw3Y-ZiVbVjA@mail.gmail.com>
 <CAASLQ4OYvTQL7ssG4=QyEqhaB71=AM-svBUYj3uRdWXWoQgBPw@mail.gmail.com>
 <5F0E3972.5070609@anastigmatix.net> <5F0F2DA2.5090603@anastigmatix.net>
 <CAASLQ4N40xn-0S4Nsy0Ld75=Ny719MPUE7_aRP_5nAcAqkAqoQ@mail.gmail.com>
 <CAASLQ4OiWCQQwYFnxAQBe2dC6Ms803RjCMX-9AC2=1m0ZzeDhA@mail.gmail.com>
 <5F12FF49.6090906@anastigmatix.net> <5F12FF80.5020208@anastigmatix.net>
 <CAASLQ4MqSVnhK_GMgq03HcmOKk7a-v7b4L0yfPbtRO=mpqoQtA@mail.gmail.com>
Cc: pljava-dev@lists.postgresql.org
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5F1338F8.6030506@anastigmatix.net>
Date: Sat, 18 Jul 2020 14:01:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
 <CAASLQ4MqSVnhK_GMgq03HcmOKk7a-v7b4L0yfPbtRO=mpqoQtA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 07/18/20 13:24, Kartik Ohri wrote:
> What surprised me is that the only entry in the first case is present in
> the second case but still the second fails, Am I missing something here ?

I am guessing a little bit from the output your code is showing without
seeing the actual code, but as I refer back to the commit comments for
6cd539b, it seems that the key thing Java 9 changed was that Nashorn
went from the boot classpath (the one with classloader null) to the
application classpath (the one implemented by
jdk.internal.loader.ClassLoaders$AppClassLoader).

I don't think the Nashorn engine is found in any of the specific
URLs that you see when you enumerate the classpath; it's still
internal to the Java installation, somewhere the AppClassLoader just
knows about.

In the Maven case, I think the key thing is some change in the rule
for delegating to the AppClassLoader. In the output you've shown,
I assume that java.net.URLClassLoader is the one you created from
explicit URL list, and you made its parent the classloader you were
initially given, which would be that ClassRealm instance. I see that
it has the AppClassLoader as its parent, and the "normal" Java
classloading rule is you ask your parent first, then only look in
your own places if the parent drew a blank. But I think the ClassRealm
changes that rule in some way. There was something in that MANTRUN-200
issue suggesting they did that because they wanted Maven builds to be
predictable regardless of what was on the application class path.
(Which, ok, I guess, but ... seriously ... ?)

But I would really like to know what ends up happening when a Maven
classpathref is passed to Ant, and ends up solving the problem.
What is a Maven classpathref? Is it just a list of URLs, or some
other object?

I wonder if it ends up working sort of by accident, maybe Ant uses
the classpathref to make a more usual classloader structure that has
the same URLs as the ClassRealm loader, but delegates from there to
the AppClassLoader instead of the ClassRealm. That could be plausible,
as Ant came first and wouldn't know about a ClassRealm. It would be
good to see it in the code though.

Ultimately we want a classloader that will work whether the engine
is part of the application classpath (as Nashorn on Java <15) OR is
in one of the explicit classpath jars (as in Java 15 if we download
Graal's js-scriptengine, or if we play with jshell-scriptengine).

Regards,
-Chap