Home » Language IDEs » Java Development Tools (JDT) » APT processing on Local Variables (was Modeling Local Variables)
| APT processing on Local Variables (was Modeling Local Variables) [message #257832] |
Tue, 16 December 2008 14:54  |
Eclipse User |
|
|
|
Hi,
I was working on a project last year (2007) and decided to use API
tools to generate some resource bundles (.properties files) for Exceptions
and Errors. I dislike the idea has to go to different .property files to
edit the
the error message and format. It is kind of cumbersome, awkward and error
prone. I then discovered that with Sun's Java jdk 5 mirror APT api doesn't
process local variable annotations. Later (2008) I switched to Sun's
Javac API using JDK 6. still no support with Local Variable annotation
(hope someone tell me that I was wrong on this). I sort of get by with
static field but not really satisfied with it.
The static fields usually are at beginning of the class or on separate
interface, which still not convenient for developers.
I was hoping the annotation can be directly put at the code where the
exception are about to be thrown.
For example,
public void doSomething() {
String tobeTested = "this";
if (!testCondition(tobeTested)) {
@ErrorMessage(messageFormat = "Test Condition is not met with
argument {0}")
String errorCode = "101";
throw new MyException (errorCode, tobeTested);
}
}
Decided to look further to see if anyone has done something on this, I
found the following exchanges between Compl and Jess in 2005 in
jdt-apt-dev group.
I would like to follow-up with this thread to see any progress have
been made on this issue in last 2-3 years.
Thanks
Chester
---------------------------------------cut ---------------------
Re: [jdt-apt-dev] Modeling Local Variables
* From: Compl Yue Still <complystill@xxxxxxxxxxxx>
* Date: Sun, 13 Nov 2005 01:46:36 -0800 (PST)
* Delivered-to: jdt-apt-dev@eclipse.org
* Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;
d=yahoo.com.cn;
h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Cont ent-Type:Content-Transfer-Encoding;
b=eP90Xcn8BJ1u5Y00LEGsNIP+Jac0T6H2LQD+mWA6f5R9LnNJAa77oKwgit 6lwqSkcU5DZs15fUdEZtpKzfyRC0I9L5BtEAVo93PyXw6xta3da4rAh64nB1 adVPLrHMOtW0B0zQ6IPKxpGcLpZwwgyZ5NiUJ0Oo3llMMWCdDKxJE=
;
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
* Prev by Date: RE: [jdt-apt-dev] Modeling Local Variables
* Next by Date: [jdt-apt-dev] About
TypeDeclaration.getActualTypeArguments()
* Previous by thread: RE: [jdt-apt-dev] Modeling Local Variables
* Next by thread: [jdt-apt-dev] About
TypeDeclaration.getActualTypeArguments()
* Index(es):
o Date
o Thread
|
|
|
| Re: APT processing on Local Variables (was Modeling Local Variables) [message #257841 is a reply to message #257832] |
Thu, 18 December 2008 03:13  |
| Eclipse User |
|
|
|
"Chester Chen" <cchen@ascentmedia.com> wrote in message
news:6a3e15e33cf99613bae1c7fd981385d4$1@www.eclipse.org...
> I then discovered that with Sun's Java jdk 5 mirror APT api doesn't
> process local variable annotations. Later (2008) I switched to Sun's Javac
> API using JDK 6. still no support with Local Variable annotation (hope
> someone tell me that I was wrong on this).
Sorry, but you are not wrong.
The APT API is designed to present a view of the typesystem, not a view of
the code. That is, it shows essentially the same view that you would get
via reflection, or the same view that type "A" has of type "B". There is no
visibility into the internals of methods, nor into anonymous classes, etc.
> I would like to follow-up with this thread to see any progress have been
> made on this issue in last 2-3 years.
This is not an issue that "progress" is going to be made on; it's
intentional in the design of the API. There are a variety of reasons for
it - for instance, the APT API is designed to be able to present information
about binary types (.class files) as well as types being compiled, and local
variable information may not be present there.
As Jess suggested in that earlier thread, if you need access to method
internals, such as local variables, you should use the AST.
|
|
|
Goto Forum:
Current Time: Sat Apr 19 13:26:01 EDT 2025
Powered by FUDForum. Page generated in 0.02835 seconds |
Home