> On 26 Feb 2017, at 13:22, Doug Simon <doug.si...@oracle.com> wrote:
>
>>
>> On 26 Feb 2017, at 13:08, Alan Bateman <alan.bate...@oracle.com> wrote:
>>
>> On 26/02/2017 11:20, Doug Simon wrote:
>>
>>> While trying to get upstream Graal working again with JDK 9, I'm having
>>> problems with service loading. Graal uses a LayoutFactory service defined
>>> by Truffle where the latter also includes a provider. The relevant parts of
>>> the module-info descriptors are:
>>>
>>> module com.oracle.truffle.truffle_api {
>>>
>>> exports com.oracle.truffle.object;
>>> exports com.oracle.truffle.object.basic;
>>>
>>> uses com.oracle.truffle.api.object.LayoutFactory;
>>> provides com.oracle.truffle.api.object.LayoutFactory with
>>> com.oracle.truffle.object.basic.DefaultLayoutFactory;
>>>
>>> }
>>>
>>> module jdk.internal.vm.compiler {
>>> requires transitive com.oracle.truffle.truffle_api;
>>> uses com.oracle.truffle.api.object.LayoutFactory;
>>>
>>> }
>>>
>>> However, looking up a provider in Graal[1] returns no providers. As far as
>>> I understand service loading with modules, this is because
>>> jdk.internal.vm.compiler is loaded via the platform class loader while
>>> truffle is loaded via the app class loader as shown by the output of trace
>>> statements I added:
>>>
>>> GraalTruffleRuntime.class.getClassLoader() ->
>>> jdk.internal.loader.ClassLoaders$PlatformClassLoader@366e2eef
>>> LayoutFactory.class.getClassLoader() ->
>>> jdk.internal.loader.ClassLoaders$AppClassLoader@6df97b55
>>>
>>> This ability of a platform loaded class to depend on an app loaded class is
>>> probably due to the soon-to-be-disabled mechanism[2] we use for overriding
>>> the version of Graal bundled with JDK 9.
>>>
>>> Is there some command line magic I can use to make this case work now or do
>>> I have to wait until [2] is addressed? If the latter, how will it work then?
>>>
>> An upgraded moduledefined to the platform loader can link to types in
>> modules defined to the app loader. So I wouldn't expect issues there.
>>
>> Can you track down the code that uses ServiceLoader.load to load the
>> LayoutFactory providers?
>
> The code is in the first link of my previous message:
>
> https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693
>
>> It might be using loadInstalled or invoking it with the platform class
>> loader and that would explain what you are seeing.
>
> Thanks - using LayoutFactory.class.getClassLoader() works. So the general
> rule is to use the leaf most class loader the service client knows about?
If that's the case, does that mean I could pick up any provider on the app
class path? Seems a little risky. Is there some way to confine it to modules
the service user trusts (by virtual of being a module in its dependency graph)?
-Doug
