Admittedly I approach this mostly from an app server perspective, but I
prefer
--Create a common package and put all common code there
--Make a separate jar with this stuff in it
--Leave the common classes out of derby.jar and derby-client.jar
--For users convenience in standalone apps produce an additional jar
that includes everything from common, derby, derby-client, network,
drda, etc etc. This would not be used if you are concerned about
classpaths and versions or the smallest possible footprint.
--Make sure that all the jars have clear version numbers in their names.
I think you are asking for major classloader trouble including the same
classes in 2 different jars (doesn't this produce a sealing or signing
problem?) and I think the package-name munging approach is really ugly
and twisted.
thanks
david jencks
On Sep 13, 2005, at 3:34 PM, David W. Van Couvering wrote:
Hi, Kathy, thanks for your email. The timing is actually pretty good,
I was just talking with Francois trying to understand his concerns
better.
After quickly describing the two approaches, I'd like to summarize the
experience/impact of these approaches from the perspectives of the end
user, the developer/maintainer, and the test developer/runner.
Goal:
- Reduce code duplication while continuing to support different
versions of client and embedded driver in the same VM
Approach 1:
- Create a common package and put all common code there
(org.apache.derby.common)
- Use compatibility guidelines to ensure backward compatibility and
some degree of forward compatibility
- Common classes are embedded in derby.jar and derby-client.jar
(based on lots of negative feedback for having a separate jar)
Approach 2:
- Create a common package and put all common code there
(org.apache.derby.common)
- During build process, "clone" all common classes into at least two
generated packages, one for the engine and one for the network client
(org.apache.derby.engine.common and org.apache.derby.client.common).
- This approach avoids having to implement compatiblity
guidelines/constraints and guarantees, as the engine and client
continue to be fully isolated
USER EXPERIENCE
Approach 1
- No new jar files, everything looks the same
- For the vast percentage of users who don't mix versions in the same
VM, everything works great
- For the small percentage of users who mix versions, the order in
which jar files are loaded. For example, if they want to use
derby-10.2.jar and derby-client-11.0.jar, then if derby-10.2.jar is
first in the classpath, they will get an exception saying that the
client code is incompatible with the common code and that they need to
re-order their jar files, whereas it will work fine if the order is
reversed.
Approach 2
- No new jar files, everything looks the same
- Ordering of jar files does not matter, everything works fine
DEVELOPER EXPERIENCE
Approach 1
- Pretty much as it is today, nothing surprising
Approach 2
- When navigating code either during source browsing or debugging,
they will see the *generated* common code, not the master common code.
- If a developer is not aware of how things work, or just forgets,
he/she will try to edit this generated code, and will be confused and
surprised when his/her changes disappear after a build
- Stack traces will point to generated code, and the developer will
have to remember to translate that back to the master version.
- The generation process must be very careful not to adjust line
numbers or all stack traces will be off and misleading. This means
for instance we can't add comments saying "THIS IS GENERATED CODE, DO
NOT EDIT"
- We may need to generate more copies if different types of version
mixing are required (e.g. if the tools.jar and derby.jar need to be at
different versions)
TESTER EXPERIENCE
Approach 1
- We would have to build and run compatibility tests to make sure
that compatible versions run correctly and incompatible ones correcty
raise the exception
Approach 2
- No real change, although debugging of tests may be confusing due to
issues I already listed under developer experience
I also am uncomfortable with the "twistiness" of approach 2. There is
something to be said for a clean architecture and build environment.
I have seen time and again that a good architecture allows you to
scale and grow, whereas "twisty" architectures tend to wrap you up and
tie you down at some point. I think this has to be taken into
consideration.
My main question is: is it OK to sometimes throw an exception for the
small set of users who mix versions, and for them to then have to
rearrange their jar ordering. If the answer is that this is not
acceptable and would be considered a showstopper regression for some
part of our user base, then I think we have no choice but to go with
Approach 2, even if we do risk painting ourselves into an
architectural corner. Otherwise, it is my strong recommendation to go
with Approach 1.
Thanks!
David
Kathy Saunders wrote:
David W. Van Couvering wrote:
Well, we're at a bit of a standoff here. What I'm looking for is a
nail-in-the-coffin data point that would move us in one direction or
the other.
I've been following this discussion with some interest as my
background is technical support. In fact, I supported Cloudscape for
the first 4 years (from release 1.0 of Cloudscape). My experience is
that developers (particularly Java developers) really liked
Cloudscape (now Derby) because it was so easy to use and deploy.
And, I found historically that one of the most common issues to come
up were classpath issues (in particular we got in trouble a few times
when we introduced something that caused the order of the jar files
to be important). You should note that I'm not, and never have been,
a Derby developer, so I don't claim to be an expert on what's correct
and best from a development perspective.
I'm a bit concerned because I see a lot of discussion about what is
good from a derby development perspective, but not so much how these
changes may affect users of Derby. Although some Derby users have
complex applications (like application servers), many are
implementing much more simple solutions.
Having said that, I'm a bit lost in what is being proposed from the
user/functional perspective. David, as soon as you have a more
concrete proposal (may not be the time yet), can you post that
information? Could you provide information on what the users of
Derby will have to do with this change (how would our documentation
need to be changed) and maybe footprint, performance, etc. impacts
vs. the benefits from making this change. I'd like to be able to
provide my input from a usability/documentation perspective.
In addition, I work on Derby now in the testing area, so I'd also
like to understand the implications for what additional testing might
need to be done. If we create more jar files, is there more testing
requirements for different combinations?
Thanks,
Kathy
<david.vancouvering.vcf>
