> 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 > > > > 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. Oleg
