Jigsaw spec clarifications
Alan.Bateman at oracle.com
Fri Jan 20 07:26:30 PST 2012
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.
More information about the jigsaw-dev