David W. Van Couvering wrote:
Yes it's true that we can't control the ordering of a classpath, and we
do need to address this. However, most version policies I have worked
with let an old version of a consumer work with a new version of
producer, but if a new version of consumer tries to use an old version
of producer it gets an exception. Even today if a new version of Derby
finds an old version of a database file, it performs some form of
upgrade before it will work with it (right?) rather than continuing to
work with the old format (right?).
With soft upgrade no upgrade is done, the code must work with the old
format, so that a previous version of the server can still access the
database. With respect to database files, we never expect an old
server to be able to access a "new" format - so once you allow
hard upgrade "upgrade=true", you can't go back.
Maybe you have an idea of how to make it easy to accomplish, but as far
as I can see, it's a big burden on the developers of consumer classes to
know how to "work with" older versions of common services, especially
when this type of configuration (with mixed versions of jar files) is
such an edge case.
That said, I think it's not right for the user to get some strange
NoSuchMethodException when the new consumer tries to use a method that
doesn't exist in the old producer. So it seems to me we need some type
of service manager (I'm not committing to which one yet, I need to do
some investigation) that allows you to say something like "give me an
implementation of this interface at this version level or higher". If
the service manager says "I don't have that" then we can throw an
exception saying something like "Unable to load version 10.2 of the
Message Service. It is probable that your classpath has older versions
of Derby jar files listed first; please check your classpath and make
sure that all Derby jar files are listed ahead of older versions."
David
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.
