Re: A way to opt out of access restrictions on non-exported members.

[Peter Levart]

On 11/16/2015 07:57 PM, Alan Bateman wrote:
On 16/11/2015 17:48, Neil Bartlett wrote:
Alan,

In your consideration does the following declaration break 
encapsulation of a module, assuming that package “org.example.impl” 
is not exported?

    module foo {
        provides org.example.api.ServiceInterface with 
org.example.impl.ServiceImpl;
    }

This appears to allow the ServiceLoader to punch through 
encapsulation and obtain instances of a non-exported type.
Sure, but this just part of the support for services. In this example 
then the service provider is fully encapsulated. The consumer of the 
service can't access ServiceImpl, it instead accesses it via 
ServiceInterface (assuming of course that the consumer reads the 
module with ServiceInterface and org.example.api is exported to the 
consumer).

How does this differ from a declaration that one might see in a 
Dependency Injection framework such as Spring? I.e. something like:

    <bean class=“org.example.impl.ServiceImpl”> …

There isn't way to give Spring super powers so this needs foo to 
export org.example.impl to Spring.

-Alan.

Hi,

Just a thought (and I don't know yet if it is a good idea)...

ServiceLoader currently has the following method:

    public static <S> ServiceLoader<S> load(Class<S> service, 
ClassLoader loader)

With the following overload:

    public static <S> ServiceLoader<S> load(Class<S> service, 
ClassLoader loader, Function<Stream<Class<?>>, Stream<Class<?>>> 
streamManipulator)

We (or Spring) could use it like:

    ServiceLoader<ServiceInterface> loader = ServiceLoader.load(
        ServiceInterface.class,
        classLoader,
        stream -> stream.filter(implClass -> 
implClass.getName().equals("org.example.impl.ServiceImpl"))
    );

This could also be used to code various other strategies for service 
lookup, for example:

    public @interface Order {
        int value() default 100;
    }

    ServiceLoader<ServiceInterface> loader = ServiceLoader.load(
        ServiceInterface.class,
        classLoader,
        stream -> stream.sorted(
            comparing(implClass -> 
implClass.getAnnotation(Order.class), comparing(Order::value))
        )
    );


This way the powers of instantiating the implementation classes are left 
to ServiceLoader, but client can decide what implementation classes are 
chosen.


Regards, Peter