db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Size of common jar file
Date Thu, 21 Jul 2005 06:29:41 GMT

>> David Van Couvering wrote:
>>
>>> I'd like to understand the issues and concerns of the size of a
>>> common jar file.  Further inspection has shown that pulling in
>>> Monitor results in a large subset of the iapi and impl packages being
>>> pulled into the common area.  This will result in a larger footprint
>>> for the client.  Is this a showstopper?  I'd like to know before I
>>> spend too much time refactoring.
>>>
>>
>> It is concerning but I wouldn't classify as a showstopper. It does
>> perhaps imply more coupling than ideal between the embedded JDBC
>> driver and the underlying engine. Perhaps footprint can be constrained
>> with some small but crucial refactoring?

David, you may want to step back and see what you are trying to do. I
think the original goal is to have the messages/exceptions localized
from the client.

If you look at the other Derby code you see that for message handling
each time the original code (for the engine) has been cloned so as not
to share it. Now cloning/copying code is generally bad, but this is
pretty simple & stable code.

So my viewpoint you seem to be putting a lot of effort in for very
little gain in value, most likely especially when you see that the exact
model used by the engine may not be well suited to the client. The
engine hashes its messages into 50 message files, so as not to have a
huge Properties object in memory for the messages. Now I would expect
the client to have few messages so hashing into separate files may not
be worth it.

So in summary, a shared code plan seems to be a lot of work, introduce
several problems and solve little.

Dan.


Mime
View raw message