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

[Eamonn McManus]

Jaroslav, I can act as sponsor for this change. 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: [EMAIL PROTECTED] 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