Thanks for writing up a proposed solution, I was getting a little tired
of putting up targets for others to shoot down.
I agree with this wholeheartedly this was what I have wanted to do
(although perhaps not as well communicated and there are some details
here that are new and which seem really good/interesting).
You say Java does this -- is this documented somewhere? I'd love to have
that as a reference.
First of all, Kathey was concerned we wouldn't be able to follow this
kind of discipline.
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL
PROTECTED]
But I'll also show where I saw this get tripped up:
> * a consumer expecting X.Y will work with X.Y' when Y' < Y by version
> detection and degraded functionality (Y' level). If Y level function
> is required then it will gracefully die (able to detect rather
> than AbstractMethodError)
In my original proposal:
* compatibility will be strongly encouraged but not guaranteed
against previous minor versions (e.g. a 10.2 consumer works
with 10.1 common classes, but a 10.3 consumer has a hard
dependency on new methods, it can not work with 10.2
common classes).
Perhaps I remember incorrectly, but I remember us (or enough of us)
generally agreeing that gracefully dying when Y level function was
required was not acceptable, as this was a regression of existing
behavior. This was the "nail in the coffin" for my original proposal.
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL
PROTECTED]
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL
PROTECTED]
Unless you can address these issues I think we're back at square one...
David
Further asides below:
As a quick braindump:
* there are rules that restrict changes to the interface going forward
* Sun (et al) stick to those rules even when it is painful
* no class/method is removed without being deprecated first
* the JVM supports version skew a little by not requiring an
implementation to implement all methods in a interface (at runtime)
That's nice to know, I didn't know that
* the interfaces often provide a mechanism to determine what features of
an API the implementation implements
* frameworks can utilize multiple classloaders to load multiple versions
of a class into the VM - tools have developed to simplify this
I don't know much about such frameworks and tools, but I don't think
this solves Dan's problem of "accidentally" loading multiple versions.
I think we can support a scenario where:
* a comsumer expecting version X.Y will work with any implementation
X.Y' when Y' >= Y
* X.Y defines the interface version, i.e. X.Y.Z works with X.Y.Z' for
all Z'
* X defines the compatibility level i.e. X and X' are not guaranteed
to work together (although we will try to ensure they do)
Basic rules:
* at the Z level, no API change is allowed, just implementation changes
* at the Y level, additive API changes are allowed but must be
accompanied by support in the versioning mechanism so that they can be
detected. Things can be deprecated
* at the Z level, incompatible changes are allowed. Items deprecated in
version X can be removed in version X+2 (implicitly (X+2).0.0).
This all applies to operation in a single classloader. Where multiple
classloaders are involved (inside one VM or in multiple VMs) a different
set of versioning behaviours applies to the wire protocol.
--
Jeremy
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
