db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Tue, 13 Sep 2005 22:34:01 GMT
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.

  - 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 
  - 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 
  - 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


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 

Approach 2
  - No new jar files, everything looks the same
  - Ordering of jar files does not matter, everything works fine


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)

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.



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

View raw message