Re: [jdt-apt-dev] Modeling Local Variables

[Compl Yue Still <complystill@xxxxxxxxxxxx>]

Jess,

   Very glad to hear from you! First I apologize for my late response, I struggled unstable of the
NIC driver in my personal server the passed days.

   And I also thought over the mechanism I mentioned in the first post, some of the advantages can
also be available if the annotations just be applied to static fields, while able to process local
annotation will gain more. So I spent this weekend writing a prototype of this idea and the
annotation processor works now to process annotated fileds.

   Let me try further explaination with the code samples and processing output here.

First let's see the main testing class:
<pre>
package test.text;

import av.msg.Messager;
import av.msg.MsgText;

public class MsgTest
{
    private static final Messager msg = Messager.get(MsgTest.class);

    /**
     * Today is ${date}, I spent ${num-hours} hours working about this
     * mechanism. I have solved ${num-solved-cp} of the total ${num-cp} critical
     * points.
     * 
     * @usage This is a message describing how the author is going on with the
     *        mechanism, his effort output, the overall critical points and how
     *        many of them have been solved. It's to be displayed on an
     *        interactive command line session.
     * @arg date = ${bsf return new Date();} : the current date
     * @arg num-solved-cp = 21 : number of critical points already solved
     * @arg num-cp = 51 : total number of critical points the mechanism met
     */
    @MsgText(location = "..")
    public final static String msgDailyEffort = "MsgTest001";

    public static void main(String[] args)
    {
        System.out.println(msg.formatMsg(msgDailyEffort, "num-hours", 5,
                "num-solved-cp", 25));
    }

}
</pre>

Here we have a "public final static String msgDailyEffort" field defined and assigned
the constant value "MsgTest001". We annotate it with @MsgText, which triggers our processor.
The location=".." spec may be some confusing, it's here just to tell the processor to store this
text message in the resource of the package (test.text). Storing at the package level favors 
another class in the same package that able to reference the same message:

<pre>
package test.text;

import av.msg.Messager;
import av.msg.MsgText;

public class AnotherMsgTest
{
    private static final Messager msg = Messager.get(AnotherMsgTest.class);

    @MsgText(location = "..")
    public final static String msgDailyEffort = "MsgTest001";

    public static void main(String[] args)
    {
        System.out.println(msg.formatMsg(msgDailyEffort, "num-hours", 5,
                "num-solved-cp", 35));
    }
}
</pre>

Upon compilation with apt enabled, the processor generates the resource file
/__generated_src/test/text.msg.xml with the following content:

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<java>
	<text>
		<MsgTest001>
			<![CDATA[Today is ${date}, I spent ${num-hours} hours working about this mechanism. I have
solved ${num-solved-cp} of the total ${num-cp} critical points.]]>
			<args>
				<date default-value="${bsf return new Date();}">the current date</date>
				<num-solved-cp default-value="21">number of critical points already solved</num-solved-cp>
				<num-cp default-value="51">total number of critical points the mechanism met</num-cp>
			</args>
			<usage>This is a message describing how the author is going on with the mechanism, his effort
output, the overall critical points and how many of them have been solved. It's to be displayed on
an interactive command line session.</usage>
			<defined>test.text.MsgTest(MsgTest.java:28)</defined>
			<used>test.text.MsgTest(MsgTest.java:28)</used>
			<used>test.text.AnotherMsgTest(AnotherMsgTest.java:15)</used>
		</MsgTest001>
	</text>
</java>
</pre>

And such like resource files can then be the start point of l10n team for message localization, 
to produce text_zh_CN.msg.xml, text_de_DE.msg.xml and more. At runtime Messager class will
format the messages in a locale sensitive way.

I surprisely found this already gain most of the advantages I mentioned in the first post, 
but it has to get each message a class fields defined, while static, it can be not so costly.
If local annotations can be processed, extra advantages are there that bring the msg declarations
to local variables. The one is that free the constantly held space by class fields, and another
maybe
the more significant one, that the declaration can appear more close to where it is used, as there
are always long method bodies, define the message just above the line it's used will free the
programmer
from scrolling the window up and down to define/modify messages. And even the 'defined' and 'used'
node in
the resource xml file will be more precisely telling the reviewer when a l10n staff querys about a
message.

I think the sample code is some self-explaining, I'm open to any ideas and querys.

Thanks very much to your attention! Let's make things better :)

   Cheers,
   Compl

---
Compl - 

Thanks for the suggestions! You are correct that sun's APT and JSR-269 do not expose local 
annotations, but that with Eclipse's compiler it is feasible.

Could you include a concrete sample of the source code containing the annotations you suggest? I'm

having a little trouble figuring out if we can support all the use cases you describe.

Thanks,
Jess



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com