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: Putting all messages in messages.properties?
Date Tue, 04 Apr 2006 19:17:58 GMT
I think perhaps you misunderstand.  I know nothing about stored 
procedure calls to get messages.  I have a properties file called 
clientmessages.properties that has the messages used by the network 
client code, and they are loaded directly as a resource.

I have updated splitmessages.java in the build directory to copy 
messages from messages_XX.properties over to 
clientmessages_XX.properties (for each locale).

What I'm doing right now is if there are messages that are new for the 
client code and not currently being used by the engine, I am manually 
adding those to clientmessages.properties, and splitmessages is then 
appending to this.

What I am suggesting is that I put *all* messages in 
messages.properties, and the splitmessages.java copies them all over. 
No manually adding messages to clientmessages.properties any more.

It will likely increase the size of derby.jar by ~200 messages x ~80 
bytes each or 16K.  The derbyclient.jar will increase by 16K also (this 
is regardless of what approach we choose), but this is offset by the 
fact that hardcoded strings are now being removed from the Java code.


Kathey Marsden wrote:
> David W. Van Couvering wrote:
>>I would like to understand what resistance there might be to putting
>>all messages in the single properties file, messages_XX.properties,
>>and using a build script to copy over the appropriate messages for the
> How much would this increase the size of client and server?  I had
> always thought that if it didn't  cause too much bloat, this would be a
> good solution, because it might also potentially mean we could get rid
> of the horrible stored procedure call for client messages.    I  have
> always been big fan of build based code sharing.  All the other
> strategies seemed awfully cumbersome to users and developers to me.
> Kathey

View raw message