db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: More. Trouble with JVMInfo
Date Mon, 26 Sep 2011 13:34:22 GMT
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:


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.


View raw message