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: [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
