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