db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Sharing code
Date Fri, 02 Sep 2005 17:35:06 GMT
I like the idea of a version number in the interface. We could provide a 
utility method so that, at startup, the client and server could complain 
if the interface wasn't capable enough. It could work like this:

o The client/server startup code would call this utility method, passing 
in the actual and expected version numbers of the interface.

o If the actual version number was less than the expected number, then 
the utility could throw an exception.

o The exception would complain that the classpath was mis-wired and 
explain how to wire it correctly.

In any event, we should add test cases to our (upcoming) compatibility 
test suite.

-Rick

Daniel John Debrunner wrote:

>David W. Van Couvering wrote:
>
>  
>
>>Hi, all.  Yes, it's your favorite topic.  :)
>>
>>    
>>
>
>[snipped - good shared code proposal]
>
>  
>
>>The common classes will be placed into both derby.jar and
>>derbyclient.jar.  When you have a classpath with a network client at one
>>revision and the embedded driver at another revision, the jar with the
>>highest revision should always go first,
>>    
>>
>
>The issue is how to enforce that. I think it's impossible to enforce
>that or guarantee any class path ordering. Remember class path problems
>are by far the leading cause of technical support calls related to Java
>programs.
>
>What it means is that the interface needs to have a version number that
>can be obtained easily, and thus the caller must only use the interface
>to the level offered. If a caller was written against version 3, but
>only version 2 is available then it can only use version 2 functionality.
>
>Dan.
>
>  
>


Mime
View raw message