db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: More. Trouble with JVMInfo
Date Mon, 26 Sep 2011 16:32:56 GMT
On 9/26/2011 6:34 AM, Rick Hillegas wrote:
>
> 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.
>
I think the reason for these classes being in all the jars is because 
sysinfo is included in all the jars so that users can run java 
org.apache.derby.tools.sysinfo and get something no matter what jars 
they have in their classpath.   I think sysinfo was thought to be stable 
but because it uses classes like JVMInfo that are used for other things, 
it is not.   How would this plan work in relation to the single sysinfo 
invocation?

I was thinking instead sysinfo  might just need to be very isolated and 
use classes only it its own package and then again hope it is stable and 
make sure method signatures, etc are not changed and only methods added 
if need be.


Also with regard to files with constants that we do share, do we need to 
have a rule that constants cannot be removed? This I think is the 
problem with this particular issue:

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.

/**
     JDBC Boolean type - Types.BIT in JDK1.1&  1.2&  1.3, Types.BOOLEAN in JDK1.4
	*/
	public static final int JAVA_SQL_TYPES_BOOLEAN;




Thanks

Kathey




Mime
View raw message