RFR: 8167180: [JVMCI] Exported elements referring to inaccessible types in jdk.vm.ci

[Doug Simon]

Another alternative name is JVMCIServiceLocator:

/**
 * Service-provider class for the runtime to locate providers of JVMCI services where the latter are
 * not in packages exported by the JVMCI module. As part of instantiating
 * {@link JVMCIServiceLocator}, all JVMCI packages will be {@linkplain Services#exportJVMCITo(Class)
 * exported} to the module defining the class of the instantiated object.
 *
 * While the {@link #getProvider(Class)} method can be used directly, it's usually easier to use
 * {@link #getProviders(Class)}.
 */
public abstract class JVMCIServiceLocator

> On 11 Oct 2016, at 14:26, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 
>> On 11 Oct 2016, at 13:57, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 10/10/2016 21:18, Doug Simon wrote:
>> 
>>> Please review this change which JVMCI API changes to address lint warnings introduced by https://bugs.openjdk.java.net/browse/JDK-8153362.
>>> 
>>> JVMCI currently exports a few service types that are in exported packages so that a ServiceLoader can load them. The problem is that some of these service types reference other JVMCI types that are not in exported packages as reported by the new lint check. To address this mixing of exported and non-exported types, this webrev introduces a new (meta) service, jdk.vm.ci.services.JVMCIAccess, that is now used to get providers for all other services:
>>> 
>>> jdk.vm.ci.runtime.JVMCICompilerFactory
>>> jdk.vm.ci.hotspot.HotSpotVMEventListener
>>> 
>>> All uses of JVMCIAccess are subject to SecurityManager checks.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8167180
>>> http://cr.openjdk.java.net/~dnsimon/8167180/
>>> 
>> I skimmed over the webrev. My only real comment is on JVMCIAccess where there may be alternative names that work better (it feels more like a JVMTIServicesFactory or JVMTIProviderFactory). The class description probably needs a bit of wordsmithing too, esp. "Service for the runtime …".
> 
> Yes, I was struggling with the naming and terminology. Some of the confusion comes from the fact that “service” in this context is used to refer to both ServiceLoader services and services that are accessed by JVMCIAccess.getProvider instead of ServiceLoader. 
> 
> In terms of the class description, I was approximating the javadoc for FileSystemProvider.
> 
> Maybe you could help me with the word-smithing. Here’s an attempt to incorporate your feedback:
> 
> /**
> * Service-provider class for the runtime to look up providers of JVMCI services where the
> * latter are not in packages exported by the JVMCI module. As part of instantiating a
> * {@link JVMCIServiceProvider}, all JVMCI packages will be {@linkplain Services#exportJVMCITo(Class) exported}
> * to the module defining the class of the instantiated object.
> *
> * While the {@link #getProvider(Class)} method can be used directly, it's usually easier to use
> * {@link #getProviders(Class)}.
> */
> public abstract class JVMCIServiceProvider { ... }
> 
> -Doug