On 9/23/11 1:31 PM, Knut Anders Hatlen wrote:
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 onhttps://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.
We have a similar problem with other classes in the same package:
ProductVersionHolder
Version
The remaining class in that package (PropertyNames) should not cause
problems as long as it just holds constants.
We might be able to fix this brittleness by cloning eveything in this
package into separate *Client, *Engine, and *Tools versions:
1) Rename all of these files to have a .shr extension rather than .java.
2) Write a simple-minded ant task which does the following:
a) Constructs a list $L of all the files in the package which end with
the .shr extension.
b) For each of the files, create a separate *Client, *Engine, and *Tools
version. For instance, Version.shr would be cloned into
VersionClient.java, VersionEngine.java, and VersionTools.java. The
clones would be written into the generated source tree of the build.
c) In each of the clones, for each name $N in $L, we would replace $N
with the appropriate $NClient, $NEngine, or $NTools string.
3) The references to each of these classes across the rest of the code
would have to be changed to references to the appropriate clone.
Thanks,
-Rick
