2011/1/26 Oleg Kalnichevski <[email protected]>: > >> The fact is that probably ServiceLoader was required in the previous >> design, using Abstract classes. That design is the only I'm aware of >> that would have allowed future releases to add more methods to each >> class without breaking compatibility with older sources. Now that you >> removed this possibility by switching everything to interfaces I >> understand that the ServiceLoader seems "horrid". Most stuff I did in >> the dom package has been done with this precise goal, so I can't >> "defend" that code if we remove the goal :-) That said you also >> should understand that the ServiceLoader, like most SPI model out >> there, is simply an abstraction layer. You are free to directly >> instantiate the implementation. >> >> >> I didn't (and I currently don't) know a better way to create a forward >> compatible, yet extensible, API, but I'm far from being an expert API >> designer. >> > > Stefano > > I am sorry I do not see how the service locator pattern can help with > maintaining forward compatibility between releases. I always thought > that it's goal was primarily to decouple layers and to enable multiple > implementations of a service interface. > > http://en.wikipedia.org/wiki/Service_locator_pattern
I wrote "the ServiceLoader, ..., is simply an abstraction layer." so I'm in line with wikipedia, I'm sorry if I mislead you with some other sentence. I try to explain with other words: - abstract model was there to allow forward compatibility (it is the only way I know that allows adding a method in the model without breaking everything) - service locator adds "indirection" (decoupling) You need both if you want to "publish" a single package and you don't want this package to have direct dependencies on the implementation. The 2 patterns are extensively used in the standard java class library and in many common libraries (I can't take the merit for mixing them ;-) ). I'm not sure I understand what part of the ServiceLocator is "horrid" in your opinion (I don't want to force you explaining anything or to waste your time, but I'm always interested learning from other developers). >> > How do you want me to proceed now? >> >> I'm happy to see you pushing. *Go* *ahead* :-) I just explained why I >> did things in a given way and how I evaluate changes. This was not a >> comment to stop you, but just something to let you be more informed. >> As long as 0.7 will support the Monitor object, the fixed headless >> parsing and the fixed field folding I will be happy (I currently have >> 0.7-SNAPSHOT as dependency for this and not for the DOM abstraction). >> >> Stefano > > I do not want to 'push' if there is no consensus that I am pushing in > the right direction. You should ;-) - You have the time to prepare a next release - You are a project committer - No one is vetoing your changes The fact that I prefer the "previous" design and I don't see critical "inconsistencies" in that design is just a comment (an IMHO). I accept to loose that stuff as in turn you'll give me back a release soon. So I think for both me and the community having a release with the many bugfix/features introduced in trunk is a big win. (hope this makes sense) Stefano
