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: VOTE: Approach for sharing code
Date Thu, 08 Sep 2005 20:19:50 GMT
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.
>
>  
>

Mime
View raw message