Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [jdt-apt-dev] Modeling Local Variables

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

-----Original Message-----
From: jdt-apt-dev-bounces@xxxxxxxxxxx [mailto:jdt-apt-dev-bounces@xxxxxxxxxxx] On Behalf Of Compl Yue Still
Sent: Monday, November 07, 2005 4:10 AM
To: jdt-apt-dev@xxxxxxxxxxx
Subject: [jdt-apt-dev] Modeling Local Variables

Hi,

   After some study, I finally found that SUN apt doesn't model local variables into the dom of
their mirror api, as they do present a ElementType.LOCAL_VARIABLE for targets of the annotation
spec. That's some confusing. After study on the scsl source of SUN apt and javac, I can understand
that coz executable statements inside the method body are not realized before the bytecode
generation pass, so local variables are still not in the ast at the time annotations are
processed. And from the viewing of jsr-269(http://www.jcp.org/en/jsr/detail?id=269), I feel even
little hope in the furture evolution of annotation processing api to get local variable
annotations availiable to the processors.

   I turned to eclipse JDT apt implementation after this disappointment, I know JDT apt aims to be
compatible with SUN apt interface, so is not modeling local variables at present. But I think it's
worth to support, as it not so difficult based on eclipse JDT ast compares to based on javac ast.
   A significant and obvious advantage of local variable annotation processing support can be seen
as an i18n message infrastructure I'm prototyping now, it's expected to beat the standard java
ResourceBundle mechanism in the following aspects:
   1. Hands free from editing separate resource files. Just define the message id as a constant
value assigned to a final String mymsgid = "mymsgid"; variable, and present the message content as
the main doc comment of this variable. This avoids creating and maintainence of separate resourse
java classes or .properties files, and programmers will have all in-context to define, modify and
use the message.
   2. Easy collaboration for programmers and l10n teams. Programmers can write meta info about the
message through doc comment tags, i.e. explaing how this message will be output or presented to
the end user, what's more, message parameters (in form like {0}, {1} for standard java
MessageFormat) can be more explicitly specified by names other than a single index, this is very
important and straight forward in a muti-language fashion, sentence sturctures always differ in
different languages, ha? Programmers define the message can in advance denote the parameters by 
comment tags to make it more clear to l10n teams. And since the resource files will be generated
by annotation processing, souce position that where the message is defined(and mostly where it's
used) will be recorded in the resource file. At last a l10n staff will see more descriptive info
about the messages he's localizing and he also can directly tell the author/programmer who defined
the message where in the source the msg is defined when doubting about it.
   3. Easy resource file organization and maintainence. Also, doc comment tags can be used to
specify where the defined message is to be located, a programmer can define a message text for the
underlying class, or the whole package, or even arbitarary levels of parent packages, he can
define it in a single java source file and reference the same message text through its txtid. The
annotation processing occurs together with compilation of the java source file, if conflicts or
incontigious detected it can product warnings even errors to prevent the malformed message
resource get built.
   4. Precise message reference. Message ids are separately specified in the resource bundle and
referencing code other than this final String local variable style of defination and reference.
This semantic guarantees that what it references is what is to be defined.
   5. Easy l10n. The annotation processing of such message definition can product resource files
in xml format of UTF-8 or native encoding, l10n staff can use just plain text editors to
accompalish his work other than use third party softwares to edit .properties file full of \uXXXX
chars. Even use the native2ascii tool provided by jdk is not so convenient.

   After all this explaining, please JDT/apt staff consider adding local variable annotation
processing ability to the JDT/apt plugin as it evolves, I'm open to any discussion and query about
the ideas. 
   But I noticed JDT dom even doesn't get a local variable and the javadoc comment before it
paired with eachother, this may need some modification to get supported in favor that the
annotation processors on local variables would like to get javadoc associated with the local
variable to function. At least the processor I'm suggesting would.

   Thanks in advance to all designers and developers, it is YOU that made it possible!

   Sincerly,
   Compl



	

	
		
___________________________________________________________ 
雅虎免费G邮箱-中国第一绝无垃圾邮件骚扰超大邮箱 
http://cn.mail.yahoo.com

_______________________________________________
jdt-apt-dev mailing list
jdt-apt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-apt-dev



Back to the top