Daniel John Debrunner wrote:
Jeremy Boynes wrote:
Think of the carnage if it was java_14208_b13.sql_300.Connection
It's actually instructive to look how Java solves this:
- The interface is kept upwards compatible, by following rules such as
only new methods/fields etc.
Then to look at how a consumer, Derby, deals with the fact of multiple
versions of the interface:
- Derby only provides and uses the functionality to match the version of
the interface (java.sql.Connection) loaded, determined at runtime.
I'd thought this was a workable direction being proposed about six
thousand message ago, upwards compatible apis and the ability for a
consumer to handle a lower version. Not sure what derailed it.
Dan.
I'm not sure if this will help or hinder with your considerations but . . .
Compatible type evolution is described in the Java Serialization Spec.
The reason it is described there is because the problem arises when
Class A is compiled against a particular version of Class B but then at
run-time an instance of A encounters (through class loading upon
de-serialization, for example) an instance of some other version of
Class B.
These type compatibility rules can be found here:
http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419
M.
--
M. Mortazavi
+1 408 276 7205 (office)
+1 408 421 4093 (mobile)
