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 
sysinfo?
>   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,
-Rick
>
>
>
>
> Thanks
>
> Kathey
>
>
>
>


Mime
View raw message