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
