> On 26 Feb 2017, at 13:26, Doug Simon <doug.si...@oracle.com> wrote:
>
>>
>> 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)?
Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be
loaded along with the providers on my module path?
-Doug
