JavaHL and interfaces, backward compat question

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

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

Re: JavaHL and interfaces, backward compat question

[Craig L Russell <Cr...@Sun.COM>]

To avoid this problem, you can write abstract classes that implement  
the interfaces. If third party implementations then extend the  
abstract class there's no backward compatibility issue.

Of course, if you add functionality to the interface that needs to  
have a specific implementation (not just the no-op in the abstract  
class) then yes, you have broken backward compatibility. But usually  
this kind of feature addition happens at major releases and it's  
presumed to be ok.

Craig

On Mar 27, 2010, at 8:42 AM, Mark Phippard wrote:

> 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
> <hy...@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/

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!

Re: JavaHL and interfaces, backward compat question

[Mark Phippard <ma...@gmail.com>]

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
<hy...@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/