David W. Van Couvering wrote: > This contribution provides mechanisms and guidelines, such as > guidelines and tools for supporting forward and backward > compatibility, to help ensure that Derby jars with different versions > can be loaded in a Java VM without having to use specialized > classloaders. If an incompatibility exists between versions, it will > be clearly documented. Any undocumented incompatibilities will be > treated as a bug. > > However, not all issues can be resolved. For example it is possible > for "shadowing" to take place if there are different versions of > network client and embedded client in the same VM, and each provides a > different implementation of the same common method. > I think that it would be good to communicate that in such cases regardless of the order the jars are loaded, functionality will not be affected at the lower revision level for either the embedded or client jar. The higher revision behaviour can be used if the higher revision jar is loaded first.
Is that true? And if so can we include it in the vote? For instance if I have a 10.2 derbyclient.jar and a 10.3 derby.jar in the same JVM, everything should work ok at the 10.2 level regardless of class loading order, but If I put derby.jar first, the embedded application should be be able to function at the 10.3 level and the client at the 10.2 level. Thanks
