Jigsaw spec clarifications

[Alan Bateman]

On 20/01/2012 14:54, Jesse Glick wrote:
> On 01/20/2012 07:28 AM, Alan Bateman wrote:
>>>> provides service S1 with S;
>>>> provides service S2 with S;
>>
>> probably won't be too common (either S is an interface
>
> Impossible; it must be a concrete class.
There was a typo in my mail, I meant that S1 may be an interface of course.


> :
>
> (This does lead to a subtle point: currently ServiceProvider.load will 
> always instantiate a fresh copy of each service implementation class 
> every time you call it. This means that nonstatic fields in a S.I. 
> class, or an explicit constructor, are usually signs of a logic error. 
> In the above example, it means that client code would get a different 
> FrobnitzHandler instance for reading vs. for writing. I do not think 
> there is any reason to change this policy when SL is used in a modular 
> environment, but it should at least be documented whether SL 
> may/must/must not cache instances. This is especially true since a 
> system using dependency injection for the same purpose would likely 
> behave differently.)
This is something that comes up from time to time and I think we'll need 
to support singleton services at some point.

>
>> I don't think the current spec mandates that the the service 
>> implementation have a public no-arg constructor. javac doesn't check 
>> for this
>> currently so it's possible to get a ServiceConfigurationError at 
>> runtime for this case
>
> Seems like a defect in the spec. If there is some problem with the 
> signature of the service that can reliably be detected at compile 
> time, it should be treated as an error.
Yes, I think so too.

-Alan.