db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@ORACLE.COM>
Subject Re: More. Trouble with JVMInfo
Date Fri, 23 Sep 2011 20:31:19 GMT
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

View raw message