8182482: Module System spec updates

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mardi 20 Juin 2017 13:30:20
> Objet: Re: 8182482: Module System spec updates

> On 20/06/2017 11:39, Remi Forax wrote:
>> Hi Alan,
>> the doc is clearly better.
>>
>> Can you change
>>    A service is a single type, usually an interface or abstract class. A concrete
>>    class can be used, but this is not recommended.
>> to
>>    A service is a single type, usually an interface. An abstract class or a
>>    concrete class can be used, but this is not recommended.
>>
>> An abstract class has a constructor so you can observe when a service
>> implementation is instantiated by the ServiceLoader, which may make the code
>> dependent of the loading order of the service implementations. So using an
>> abstract class for a service implementation is also a bad idea.
>>
> There shouldn't be any issue using an abstract class as the service.
> Sure, most developers will choose an interface but we have many examples
> where the service type is an abstract class (and there are corner cases
> with security where enforcement isn't possible when using an interface).

Abstract classes are evil when the abstract class and the concrete class are not maintained by the same people,
if the code of the abstract class change for whatever reason, it will break the subclasses. It's just bad design.

And the code that enforce security do not have to be in the abstract class constructor, debugging a constructor in general is harder than any other methods because the object is partially initialized. When you are executing the constructor of an abstract class the object corresponding to this is not fully initialized. You can always 'layer up' and use factories instead.
 
> 
> The service provider can be abstract class too but only when it defines
> a public static provider method.

yes, here, it's less problematic because in that case the abstract class and all subclasses will be maintained together.

> 
> I don't understand your point about an abstract class having a
> constructor. If it doesn't a static provider method then it won't
> compile as a module (it won't run either as it can't be instantiated).

ok, let's focus on abstract class defining a service.

> 
> -Alan

Rémi