db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Fri, 09 Jun 2006 01:10:42 GMT
David Van Couvering wrote:

>
>
> Kathey Marsden wrote:
>
>> David Van Couvering (JIRA) wrote:
>>
>>> I'd like to revisit our beloved issue of code sharing.
>>>  
>>>
>> [snip details on code sharing proposal that does not negatively 
>> impact users. Hooray!]
>>
>> I personally prefer an approach similar to the obfuscation tools, where
>>
>> 1) All the code imports the checked in files and  is built to the 
>> classes directory as normal.  Just as if we had no code sharing 
>> concerns.
>>    Developers can point to the classes and debug and edit as normal.
>>
>> 2) In the  jar build, after building the classes the code is copied  
>> and modified as needed to create a separate name space under 
>> production/java
>>   and then built to production/classes.  The jars are built from 
>> production/classes.   For running derbyall  developers are instructed 
>> to point  to the jars to catch any troubles in this  process.
>
>
> Hi, Kathey.  When you say the "code is copied and modified as needed" 
> what exactly are you thinking of here.  Is this byte-code 
> modification, or are you proposing a source-code copy/modify.  If the 
> latter, wouldn't this require also modifying all classes depending 
> upon the shared classes to use the new package name?
>
> I don't know how obfuscation works, but I think this is a byte-code 
> change, right?  I'll go take a look at obfuscation tools to get a 
> sense of what they do.
>
>>
>> Maybe some of the newer obfuscation tools have something more clever, 
>> but since essentially what we are doing is obfuscating  these classes 
>> so they don't conflict , I think this might be a good approach that 
>> will  impact developers less.   The only downside  I see is build 
>> time when building jars, but that will be required only before 
>> running tests.
>>
>
> Well, the other downside is that when you get a stack-trace, you won't 
> be able to find the source referred to in the trace, and you have to 
> manually translate to the actual classes. That's one of the things I 
> disliked about obfuscators -- what the heck is a.b.c.Connection.x()?

Right, but the only translation is that your trace in test failures and 
production systems say:

org.apache.derby.shared.generated.client.common.DavidUtil

but you have to know the code lives in:
org.apache.derby.shared.common
So the deobfuscation algorithm is pretty easy, you just take out "generated.<client|net|tools>".
 All non-shared classnames stay the same.


> This is similar with the approach I proposed, except that the 
> generated classes are still around, and for instance in an IDE you can 
> double-click and get taken directly to a source file to inspect, even 
> if it's not the source file you should ultimately be modifying.
>
In my proposal if you point your IDE to the cllasses directory, you can  
double click and get taken directly to the source file that you can 
edit, which is the main advantage.  Also when pointing to classes 
classnames in traces etc match up exactly.




Mime
View raw message