Question

I have a rather big number of source files that I need parse and extract all string literals and put them in a file as play old java constant.
For exemple:

Label l = new Label("Cat");

Would become:

Label l = new Label(Constants.CAT);

And in Constants.java I would have:

public final static String CAT = "Cat";

I do not want the strings to be externalized in a property text file.
One reason is for consistency and code readability.
The other is that our client code uses GWT, which does not support Java property text file mechanism.

I could write some sort of parser (using ant replace task maybe)?
But I wondered if an IDE already does this sort of thing automatically.

Was it helpful?

Solution

To complete Peter Kelley answer, you might consider for eclipse IDE the AST solution.

You might then write an AST program which parse your source code and does what you want.

A full example is available in this eclipse corner article, also more details in the eclipse help.
And you can find some examples in Listing 5 of the section "Implementation of in-place translation" of Automating the embedding of Domain Specific Languages in Eclipse JDT, alongside multiple examples in GitHub projects.

OTHER TIPS

Eclipse does do this automatically. Right-click the file, choose "Source", then "Externalize strings"

This doesn't do exactly what you requested (having the strings in a Constants.java file as Strings) but the method used is very powerful indeed. It moves them into a properties file which can be loaded dynamically depending on your locale. Having them in a separate Java source file as you suggest means you'll either have ALL languages in your application at once or you'll ship different applications depending on locale.

We use it for our applications where even the basic stuff has to ship in English and Japanese - our more complicated applications ship with 12 languages - we're not a small software development company by any means :-).

If you do want them in a Java file, despite the shortcomings already mentioned, it's a lot easier to write a program to morph the properties file into a Java source file than it is to try and extract the strings from free-form Java source.

All you then need to do is modify the Accessor class to use the in-built strings (in the separate class) rather than loading them at run time.

There are some good reasons why you wouldn't want to do this. Aside from the fact that any such generated file (I didn't know about the eclipse function)is not going to distinguish between strings that you're setting, for example, as constructor args in test classes and things you actually want to have as constants, the bigger issue is that all of your public static finals are going to be compiled into your classes, and if you want to alter the classes behaviour you'll need to alter not only the class holding the constants but everything that references it.

I fully acknowledge what Pax Diablo said. We're using that function too.

When applied to a class file the function "Externalize strings" will create two files, a class Messages.class and a properties file messages.properties. Then it will redirect all direct usages of string literals to a call to Messages.get(String key) and using the key you entered for the string in the "Ext. String" wizard.

BTW: What's so bad about property files? As he said, you can just change the properties file and don't have to change the class if you need to change the text.

Another advantage is this one: The way of extracting the string literals into a property file leaves you free to translate the source language in any language you want without modifying any code. The properties file loader loads the target language file automatically by using the corresponding file with the language iso code. So you don't have to worry about the platform your code runs on, it will select the appropriate language (nearly) automatically. See documentation of class ResourceBundle for how this works in detail.

You may want to check out the Jackpot source transformation engine in NetBeans which would allow you to script your source transformations.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top