Maintenance Reviews was: [PATCH] Enhance ServiceLoader to understand factory methods

[Jaroslav Tulach]

Dne Wednesday 22 October 2008 18:55:03 Eamonn McManus napsal(a):
>  Jaroslav,
>
> I can act as sponsor for this change.

Excellent. I'll prepare better description of the change over the weekend. 
Thanks.
-jst


>
> My understanding from looking at the code is that the change is as follows.
> Today, you can supply an implementation of the SPI com.example.Foo by
> putting a jar file in the classpath (etc) that contains a file called
> META-INF/services/com.example.Foo which might contain lines like:
>
> com.example.providers.Bar
>
> To instantiate this provider, ServiceLoader loads the class
> com.example.providers.Bar and instantiates its public no-arg constructor.
> The Bar class must be a subtype of com.example.Foo.
>
> With your proposed change, the above will still be possible, but
> additionally the file can contain lines like:
>
> com.example.providers.Bar.baz()
>
> To instantiate this provider, ServiceLoader loads the class
> com.example.providers.Bar and calls its public static method baz(). The Bar
> class does not have to be a subtype of com.example.Foo but the return type
> of baz() does.
>
> Can you say a bit more about the rationale here? I understand why SPIs
> should be defined with abstract classes rather than interfaces, but
> ServiceLoader already supports both classes and interfaces. I can see why
> final classes might be of interest (so you can add new methods without
> fearing a clash with an existing subclass method name), and I guess you
> have in mind that such classes could have their behaviour defined via
> constructor parameters, with each new version adding a new constructor; but
> rather than guessing it would be nice to see an example.
>
>  Regards,
>
> Éamonn McManus · JMX Spec Lead · http://weblogs.java.net/blog/emcmanus
>
>
>  Jaroslav Tulach wrote:
> Thanks for the clarification, Mark. I've heard about some umbrella JSR for
> each release of the JDK before and I was hoping that my proposed change
> could be covered as part of it. Thanks for confirming that such aggregation
> is possible.
>
>
> With regard to this particular proposal, as the original author of ...
>
>
> OK, I can promise that I will work hard on polishing my proposal. I can
> improve the code, I can add more documentation, I can write more tests,
> change the new API semantics, etc. I just need a sponsor to tell me what to
> change and where and then take and apply my final patch.
>
> Thanks in advance for your help.
> -jst
>
> Dne Friday 17 October 2008 06:24:13 Mark Reinhold napsal(a):
>
> Date: Fri, 17 Oct 2008 05:56:13 +1000
> From: david.holmes at sun.com
>
> If this is a modification to the API not just a patch for the
> implementation then the short answer is No.
>
> Well, not exactly.
>
>
>                                            API changes have to be made
> via a JSR.
>
> ... or in a Maintenance Review of an existing JSR.
>
> Small API revisions and additions do not require their own JSR; that
> would be ridiculously inefficient.  Instead we roll them up into a
> series of Maintenance Reviews of the previous Platform JSR [1].
>
> There have already been many small API changes in the JDK 7 codebase.
> Suggested patches for further such changes are welcome, and will be
> discussed and judged on their own technical merit.  All implemented
> changes will, in due course, be aggregated into an appropriate JCP
> Maintenance Review.
>
> With regard to this particular proposal, as the original author of
> the class in question I suppose I should have an opinion about it,
> but that's a topic for a different message.
>
> - Mark
>
>
> [1]
>
>
> http://weblogs.java.net/blog/mreinhold/archive/2006/03/mustang_mainten.html