Hm, interesting ideas. I would be much happier generating two source
files from a single initial source, the reason being that if we
transmogrify package names or generate bytecode then debugging using
stack traces and/or visual debuggers becomes much more difficult.
I would say the motivation for sharing is primarily to confuse users... :)
Seriously, the motivation is primarily to reduce code duplication, which
requires extra engineering resources both during development and
particularly during maintenance. I used to work in maintenance for
connectivity at Sybase and we had two exact copies of the same network
code for Unix and VMS and it was nasty nasty nasty. I am not so
concerned about reducing static/runtime footprint, although it would be
nice.
We would have to find a way to ensure naive developers don't
accidentally modify the generated code when they are doing maintenance,
vs. modifying the primary source code.
I'd like to hear what others have to say about this.
After another day of emails, I'm going to try and capture the issues
brought out and their resolutions and see if we're ready for a final vote.
David
Daniel John Debrunner wrote:
Kathey Marsden wrote:
I liked your idea of adding just the needed classes to the existing
jars. The trick is to find a way to get Derby to always load the class
from the same jar file first, then no versioning is needed.
Suddenly, creating separate package namespaces for the common package
in the jars as last step of the jar build doesn't seem so weird to me.
I've been thinking about suggesting that as well, e.g. the same code
would be generated into two source java files in two (etc.) packages:
org.apache.derby.engine.common
org.apache.derby.client.common
As I said in an earlier e-mail, you can share at many levels, a lot
depends on why you are sharing? Is it to reduce development effort,
reduce static/runtime footprint, add confusion for the user?
Obfuscators rename packages all the time and are widely accepted.
And we already have generated code, so we handle that currently, ie. the
java files from the parsers.
It could even happen as a special releasejar target so it wouldn't
confuse day to day development.
I don't agree with this, a single build process is much better, it
nmeans the normal development testing is in line with the released builds.
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
