I'd suggest taking a look at guidelines that other Java projects have established to get an idea of consequences.
Here is the one for Eclipse: http://wiki.eclipse.org/Evolving_Java-based_APIs There are probably some Apache projects that publish something similar. Mark On Fri, Mar 26, 2010 at 7:27 PM, Hyrum K. Wright <hyrum_wri...@mail.utexas.edu> wrote: > Mark, > A couple of months ago, you mentioned the avenue of interface-izing the > various objects that are part of the public API, such as the callbacks and > the client interface. In thinking a bit more about this, and given my > general lack of Java background (in spite of the recent commits to the > contrary) I've got a question about backward compat in this scenario. > > In creating an interface (which we have) for our client API, we could also > create interfaces for the objects that interface references. The primary > reason for doing so is enabling third-party implentors to do so without > having to actually use any of our objects, giving them (and us, ultimately) > more flexibility for compatibility. > > This does add an additional question: if third-parties are implementing these > interfaces, and we chose to add more functionality them (and hence more APIs) > to the interfaces, does this break backward compat? Code that formerly > compiled against an interface which now includes another function definition > would no longer compile, yes? If so, does that consistute a broken backward > compat? What if somebody just dropped in the new jar, and didn't recompile? > > If adding interfaces to the JavaHL API means that we'll need to rev them (not > just extend them) in the event we add more data to those interfaces/objects, > I don't know that it's worth the work. > > Thoughts? > > -Hyrum -- Thanks Mark Phippard http://markphip.blogspot.com/
