tags:

views:

39

answers:

4

Is there a way to automatically clean/show unused properties in a messages.properties file, that file is huge atm, but the system have changed a lot and some of them are not being used, doing it by hand would take a long time in code inspection, and personally i dont like having waste around, any suggestions?

to put you in context im working on a seam project, but this could be valid to other java projects

+1  A: 

I didn't find any tool for this and I do not believe their exists one 100% correct. You could write your own parser that would search all source files for all message keys. As you find them, you can delete from the list, to progress faster.

Those that remain should be manually verified.

However, this will save a lot of time.

thelost
This is the approach I would use but one thing it wouldn't account for is cases where the message key is dynamically constructed
matt b
Dynamically constructed by using other message keys, right ? In this case, if the "sub-keys" appear to be used, then the constructed message should be preserved as well. Am I missing something ?
thelost
+2  A: 

No, there isn't. And yes, it's really one of the tasks/responsibilities you get paid for.

To ease maintenance now and in the future, I myself use a tree-oriented convention in message keying, so that I (and my successors) can easily correlate the location/use of the messages in the view side. A bit in the style of pagename.parentid.childtype.childname.attributename

E.g. a home.login.label.username.tooltip key which points to a home.jsp with:

<form id="login">
    <label for="username" title="${text['home.login.label.username.tooltip']}">

Keep this convention consistently and you'll find that it becomes more easy to maintain this all.

Logging property access isn't going to be a quick help. You'll end up wasting more time.

BalusC
+2  A: 

I think the way to go would be to write a wrapper around a Properties object so that you can instrument (i.e. log) all accesses to properties in that object. Run your program through its normal operations, and then analyze your log to find out which properties were actually used.

As a refinement, you could extend the Properties object with a tally that keeps track of useage in itself, and a method which writes all used properties out to a file for you on demand. That would save you from having to fiddle with the log file.

Carl Smotricz
Except that by volume the biggest use of properties is message externalization (relevant given the asker's filename, `messages.properties`), and a large chunk of that is usually error messages. So running your program through "its normal operations" will be dreadfully insufficient.
Mark Peters
A: 

If you have access to bash (on Windows, you do if you install Git, on Mac/Linux, you already have it) then this little one-liner can do a half-decent job of narrowing down the search:

YOURPROPS=messages.properties
SRCDIR=src
egrep -v "($(
    cut -s -d = -f 1 <$YOURPROPS | 
        while read prop; do 
            grep -q -d recurse '"'"$prop"'"' $SRCDIR && echo "$prop"; 
        done | xargs echo | sed 's/ /|/g'))" $YOURPROPS | cut -s -d = -f 

(This assumes all properties are written like name=value with no extra spaces around the equals sign, that you use equals sign rather than colon or space for separator, etc.)

It will output all properties which don't appear enclosed in double quotes in any file in the $SRCDIR. This means that it will might give some false positives. For example, if you have something like this:

String msg = I18n.getString("foo.bar." + "baz");

... it will think the property foo.bar.baz doesn't appear in the source directory. But as I said, it helps narrow down the search a bit.

gustafc