On Fri, 2011-09-23 at 08:02 -0700, Rick Hillegas wrote: > On 9/23/11 7:26 AM, Katherine Marsden wrote: > > I don't have Internet connectivity from my computer but hit a serious > > problem with mixed jars trying to test 10.8 client with 10.5 server > > that I wanted to share as I will likely be disconnected until Monday. > > > > If I have 10.8 derbyclient.jar followed by 10.5 derbyrun.jar in my > > classpath and try to make even an embedded connection, I get a > > NoSuchFieldError for JVMInfo.JAVA_SQL_TYPES_BOOLEAN. > > > > This field was required for 10.5 but removed sometime before 10.8. > Hi Kathey, > > That field was needed to support JDK 1.3. The field was removed in 10.7 > by the work on https://issues.apache.org/jira/browse/DERBY-4868. > > JVMInfo is one of the classes which is included in multiple Derby jar > files: derby.jar, derbyclient.jar, derbytools.jar. References to JVMInfo > will be resolved in a way which depends on the order of your classpath. > Assumptions about the behavior of the shared classes appear to me to be > brittle, poorly tested, and poorly documented.
I agree. It sounds like the problem is that the client and the engine share the JVMInfo class, not that we modify the class. Any changes to that class could cause problems in such mixed setups. If we add fields/methods, it would be problematic to have the old version first in the classpath (as seen in DERBY-5429). If we remove fields/methods, it would be problematic with the new version first (as seen in this thread). Not to mention what happens if the value of a field, or the implementation of a method, changes between two versions. The rule we have followed so far, has been that only interfaces that contain constants only, can be present in more than one jar file. (An exception was made for the sanity classes, since they'll only be in the debug jars, which was thought to be less serious.) So JVMInfo shouldn't be used by the client according to that rule. But even if we fix this on trunk so that the client doesn't use that class, there could still be collisions between old clients and new engines (but not the other way around), unless we also rename the JVMInfo class on trunk. -- Knut Anders
