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 18:13:47 GMT
On 9/26/11 9:32 AM, Kathey Marsden wrote:
> 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.
Can you refresh my memory: why is sysinfo included in all of our jars? 
Why can't we ask people to wire in the tools jar if they want to run 
>   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?
Constants should be ok. They are compiled out so that no run-time 
resolution is needed.
> 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.
This is a variable, not a constant. Don't let the capitalization 
convention confuse you.
> /**
>     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;
It would be easy to write a utility which performed a pair-wise 
intersection of our jar files, looking for violations of the general 
rule that a given class should appear in only one jar. If we want to 
create exceptions to this rule, we could list those exceptions and 
exclude them from analysis by the utility.

> Thanks
> Kathey

View raw message