Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Using AspectJ for internationalization

Hi,

It sounds like you tried an advice that uses execution(String.new(..)).  I'm not entirely sure, but I believe the reason this is not working for you is because this method does not exist in your project (it is defined in Java's rt.jar), meaning the compiler will not deal with it when weaving occurs.  Note however that an advice that uses call(String.new(..)) will be woven properly, but only for string constructions of the form String str = new String(...), and not for String str = "..." (since this doesn't directly use the new method). 

There is a way to expose the rt.jar to the weaving process such that using and advice with execution(String.new(..)) would work, but doing so seems like a bad idea because modifying the rt.jar would modify the way all java projects run on your system, not just this project you are working on. 

So I'm not sure what the best approach would be to advice statements such as String str = "...", but I hope this helped you understand why your attempts have not worked so far.

Arjun

On 12/15/06, Bo Zimmerman < bo.zimmerman@xxxxxxxxxxxxxxxxxxxxx> wrote:
Hello all you AOP gurus.
 
An amusing idea occurred to me, and I'm doing my darndest to try and implement it, but having troubles...
 
My idea is to use AspectJ as an internationalization mechanism for Java programs to go multi-lingual "on the cheap".  It would work by putting Around pointcuts for string literal references that will, when they are referenced, get themselves replaced with a matching hashed string from a ResourceBundle in another language.
 
The idea is simple.  The idea is beautiful.  The implementation is neither.
 
My first idea was to capture String.new(..) calls, assuming that, when a string literal like:
String STR="blah blah"
.. occurs, there is a string creation for the STR variable, and another for the "blah blah" literal, which is then copied into the s under the covers.
 
The idea then would be to detect and ignore STR's creation, and advise the creation of "blah blah" by returning a string different than the one created.
 
Such detection becomes even more vital when one considers the following example:
 
String INPUT=new BufferedReader(System.in).readLine();
if(!INPUT.equals("GOODINPUT"))
    System.out.println("Your input, "+INPUT+", was not GOODINPUT.");
 
In this case, we would need to advise the creation of literals "GOODINPUT", "Your input," and ", was not GOODINPUT" but *ignore* the creation of INPUT itself and any value it is assigned.
 
This is also why it is insufficient to advise System.out.println(String) calls -- since by the time it gets to that point, the string has been mangled with the users INPUT, and is no longer in a translatable state.
 
So that's the plan: what have I tried?
 
1. I can advise StringBuffer calls, which appear to occur when a String needs to manipulate itself by appending data and the like.
2. I can advise System.out.println(..) calls, for what good that's worth (NONE).
3. I can NOT advise java.lang.String.new(..) init()'s.  They are ignored, utterly, completely, and always.
 
That last is my real sticking point.  I was hoping to somehow capture those String inits and somehow (don't know how) "detect" whether the init is of a string literal, or a new user variable.
 
Good input is, as always, greatly appreciated.
 
- Bo Zimmerman
 
 
 

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users




Back to the top