From rgomes1997 at yahoo.co.uk Sat Feb 2 22:44:39 2008
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Sun, 3 Feb 2008 03:44:39 +0000
Subject: [JSR308] Custom annotations?
Message-ID: <200802030344.39749.rgomes1997@yahoo.co.uk>
Hi All,
I was able to get JSR-308 annotation checkers working fine.
The test program below uses @NonNull to make sure the environment is correctly
set. The test is intended to exercise if we can detect the wrong use of
Double variables which have different semantics.
My question is: how can I turn on type checkings relative to the annotations
@Rate and @Volatility I've defined?
Thanks in advance.
=== Main.java ==============================
import checkers.quals.NonNull;
public class Main {
private void calculate(@Rate Double rate, @Volatility Double vol) {
System.out.println(Math.pow(vol, rate));
}
private void allTests() {
@Rate Double rate = 0.45;
@Volatility Double vol = 0.5;
@NonNull Double d = null; // Yeah! I've got a compiler error! :)
calculate(rate, vol); // Pass
calculate(vol, rate); // Should give a compile error <<<< =====
}
public static void main(String[] args) {
Main test = new Main();
test.allTests(); // Why I've got (defer.invalid) here??? <<<< =====
}
}
=== Rate.java ==============================
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.FIELD, ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER })
public @interface Rate {
// No methods - Tagging annotation
}
=== Volatility.java ==============================
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.FIELD, ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER })
public @interface Volatility {
// No methods - Tagging annotation
}
=================================
--
Richard Gomes
http://www.linkedin.com/in/rgomes
M: +44(77)9955-6813
H: +44(870)068-8205
sip:200200 at jquantlib.org
What is VoIP?
See my project on Quantitative Finance
http://www.jquantlib.org/
From mernst at mpi-sws.mpg.de Thu Feb 7 08:14:17 2008
From: mernst at mpi-sws.mpg.de (Michael Ernst)
Date: Thu, 7 Feb 2008 14:14:17 +0100
Subject: [JSR308] Custom annotations?
In-Reply-To: <200802030344.39749.rgomes1997@yahoo.co.uk>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
Message-ID: <18347.1065.852181.418958@swsmde.ds.mpi-sws.mpg.de>
Richard-
> I was able to get JSR-308 annotation checkers working fine.
Great! I'm glad to hear that.
> My question is: how can I turn on type checkings relative to the annotations
> @Rate and @Volatility I've defined?
Please see Section 8, titled "How to write a checker plugin", of the "JSR
308 Type-checkers and Framework" document, which is linked from the JSR 308
webpage (http://groups.csail.mit.edu/pag/jsr308/).
Here are direct links (but they're subject to change, so if at some point
they do not work, just follow the links from the main JSR 308 page).
The "JSR 308 Type-checkers and Framework" document is
http://groups.csail.mit.edu/pag/jsr308/dist/manual.pdf
http://groups.csail.mit.edu/pag/jsr308/dist/manual.html
Here's a direct link to Section 8, "How to write a checker plugin":
http://groups.csail.mit.edu/pag/jsr308/dist/manual.html#writing-a-checker
You'll also find the distributed checkers helpful as examples (especially
the simple ones like Interned).
If you still have questions after examining these, please ask again, and
we'll do our best to help.
> public static void main(String[] args) {
> Main test = new Main();
> test.allTests(); // Why I've got (defer.invalid) here??? <<<< =====
> }
The checker outputs "deref.invalid", not "defer.invalid".
"deref.invalid" is short for "dereference.invalid", meaning that this
dereference (namely, invoking a method on the "test" variable) might throw
an exception at run time.
The reason for this is that the type of the "test" variable is "@Nullable
Main", meaning that it might be null. You can change the declaration to
"@NonNull Main" to eliminate the checker warning.
You don't always have to write "@NonNull" for local variables that are
never null. The checker deduces some such facts for you, and it should do
so in your example. I've added it to our test suite so it will be corrected
in a future release.
-Mike
From rgomes1997 at yahoo.co.uk Sun Feb 10 16:40:08 2008
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Sun, 10 Feb 2008 21:40:08 +0000
Subject: [JSR308] Custom annotations?
In-Reply-To: <18347.1065.852181.418958@swsmde.ds.mpi-sws.mpg.de>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<18347.1065.852181.418958@swsmde.ds.mpi-sws.mpg.de>
Message-ID: <200802102140.08376.rgomes1997@yahoo.co.uk>
Hi Mike,
Thank you for your directions.
It should be very convenient to detect that ...
@Rate double rate = 1.0;
@Volatility double vol = rate;
.... cannot compile because the variables are semantically different,
nevertheless both are represented internally as floating point numbers.
I was thinking to create an annotation intended to mark another annotations as
typecasts:
@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Typecast {
// Marks other annotations as 'typecasts'
}
It implies to say that the second annotation is simply a tagging interface.
For instance:
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.FIELD,
ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER })
@Typecast
public @interface Rate {
// No methods - Tagging annotation
}
Once @Rate, @Volatility, etc are defined as @Typecast, an annotation processor
would include all these annotations in its processing task, in a similar way
that there's an annotation processor which recognizes the specific annotation
@NonNull, for instance.
Do you know if there's something similar already being done by someone else?
(In fact, I have only the idea... no single line of code on it.)
What do you think about this idea?
Thank you again and kind Regards,
--
Richard Gomes
On Thursday 07 February 2008 13:14:17 Michael Ernst wrote:
> Richard-
>
> > I was able to get JSR-308 annotation checkers working fine.
>
> Great! I'm glad to hear that.
>
> > My question is: how can I turn on type checkings relative to the
> > annotations @Rate and @Volatility I've defined?
>
> Please see Section 8, titled "How to write a checker plugin", of the "JSR
> 308 Type-checkers and Framework" document, which is linked from the JSR 308
> webpage (http://groups.csail.mit.edu/pag/jsr308/).
>
> Here are direct links (but they're subject to change, so if at some point
> they do not work, just follow the links from the main JSR 308 page).
> The "JSR 308 Type-checkers and Framework" document is
> http://groups.csail.mit.edu/pag/jsr308/dist/manual.pdf
> http://groups.csail.mit.edu/pag/jsr308/dist/manual.html
> Here's a direct link to Section 8, "How to write a checker plugin":
> http://groups.csail.mit.edu/pag/jsr308/dist/manual.html#writing-a-checker
>
> You'll also find the distributed checkers helpful as examples (especially
> the simple ones like Interned).
>
> If you still have questions after examining these, please ask again, and
> we'll do our best to help.
>
> > public static void main(String[] args) {
> > Main test = new Main();
> > test.allTests(); // Why I've got (defer.invalid) here??? <<<<
> > ===== }
>
> The checker outputs "deref.invalid", not "defer.invalid".
> "deref.invalid" is short for "dereference.invalid", meaning that this
> dereference (namely, invoking a method on the "test" variable) might throw
> an exception at run time.
>
> The reason for this is that the type of the "test" variable is "@Nullable
> Main", meaning that it might be null. You can change the declaration to
> "@NonNull Main" to eliminate the checker warning.
>
> You don't always have to write "@NonNull" for local variables that are
> never null. The checker deduces some such facts for you, and it should do
> so in your example. I've added it to our test suite so it will be
> corrected in a future release.
>
> -Mike
From Tom.Ball at Sun.COM Sun Feb 10 17:52:32 2008
From: Tom.Ball at Sun.COM (Tom Ball)
Date: Sun, 10 Feb 2008 14:52:32 -0800
Subject: [JSR308] Custom annotations?
In-Reply-To: <200802102140.08376.rgomes1997@yahoo.co.uk>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<18347.1065.852181.418958@swsmde.ds.mpi-sws.mpg.de>
<200802102140.08376.rgomes1997@yahoo.co.uk>
Message-ID: <47AF8030.70705@Sun.COM>
Richard Gomes wrote:
> Hi Mike,
>
> Thank you for your directions.
>
> It should be very convenient to detect that ...
>
> @Rate double rate = 1.0;
> @Volatility double vol = rate;
>
> .... cannot compile because the variables are semantically different,
> nevertheless both are represented internally as floating point numbers.
It had better compile, as annotations aren't supposed to change
compilation behavior. Your error detector could certainly flag it as an
error, however.
Tom
From rgomes1997 at yahoo.co.uk Sun Feb 10 20:28:47 2008
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Mon, 11 Feb 2008 01:28:47 +0000
Subject: [JSR308] Custom annotations?
In-Reply-To: <47AF8030.70705@Sun.COM>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<200802102140.08376.rgomes1997@yahoo.co.uk>
<47AF8030.70705@Sun.COM>
Message-ID: <200802110128.47687.rgomes1997@yahoo.co.uk>
On Sunday 10 February 2008 22:52:32 Tom Ball wrote:
> Richard Gomes wrote:
> > Hi Mike,
> >
> > Thank you for your directions.
> >
> > It should be very convenient to detect that ...
> >
> > @Rate double rate = 1.0;
> > @Volatility double vol = rate;
> >
> > .... cannot compile because the variables are semantically different,
> > nevertheless both are represented internally as floating point numbers.
>
> It had better compile, as annotations aren't supposed to change
> compilation behavior. Your error detector could certainly flag it as an
> error, however.
>
> Tom
Hi Tom,
JSR-308 is very interesting for our project because we are able to reach very
strong type checking whilst producing small, fast, clear, organized and well
documented code. More info at
http://www.jquantlib.org/index.php/DeveloperCorner
In the future we will have to implement the annotation processor and cause
compilation errors wherever necessary.
Thanks you
--
Richard Gomes
From Tom.Ball at Sun.COM Mon Feb 11 11:47:42 2008
From: Tom.Ball at Sun.COM (Tom Ball)
Date: Mon, 11 Feb 2008 08:47:42 -0800
Subject: [JSR308] Custom annotations?
In-Reply-To: <200802110128.47687.rgomes1997@yahoo.co.uk>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<200802102140.08376.rgomes1997@yahoo.co.uk> <47AF8030.70705@Sun.COM>
<200802110128.47687.rgomes1997@yahoo.co.uk>
Message-ID: <47B07C2E.6050802@sun.com>
Richard Gomes wrote:
> On Sunday 10 February 2008 22:52:32 Tom Ball wrote:
>> Richard Gomes wrote:
>>> Hi Mike,
>>>
>>> Thank you for your directions.
>>>
>>> It should be very convenient to detect that ...
>>>
>>> @Rate double rate = 1.0;
>>> @Volatility double vol = rate;
>>>
>>> .... cannot compile because the variables are semantically different,
>>> nevertheless both are represented internally as floating point numbers.
>> It had better compile, as annotations aren't supposed to change
>> compilation behavior. Your error detector could certainly flag it as an
>> error, however.
>>
>> Tom
>
> Hi Tom,
>
> JSR-308 is very interesting for our project because we are able to reach very
> strong type checking whilst producing small, fast, clear, organized and well
> documented code. More info at
> http://www.jquantlib.org/index.php/DeveloperCorner
>
> In the future we will have to implement the annotation processor and cause
> compilation errors wherever necessary.
All of your work looks good, but you can't modify the behavior of
Java-compatible compilers. JSR-308 gives error checkers additional
support, but compliant Java compilers cannot change their behavior based
on different annotation values. Now, there may be OpenJDK
implementations which may do that in the future, but they can't be
considered compatible with Java until the specification of Java changes
to allow annotations to change compiler behavior.
Tom
Tom
From James.Gosling at Sun.COM Mon Feb 11 12:21:40 2008
From: James.Gosling at Sun.COM (James Gosling)
Date: Mon, 11 Feb 2008 09:21:40 -0800
Subject: [JSR308] Custom annotations?
In-Reply-To: <47B07C2E.6050802@sun.com>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<200802102140.08376.rgomes1997@yahoo.co.uk> <47AF8030.70705@Sun.COM>
<200802110128.47687.rgomes1997@yahoo.co.uk> <47B07C2E.6050802@sun.com>
Message-ID: <11FC3FE1-9E48-4253-A5FD-2F27EFC404BC@sun.com>
On Feb 11, 2008, at 8:47 AM, Tom Ball wrote:
> Richard Gomes wrote:
>> On Sunday 10 February 2008 22:52:32 Tom Ball wrote:
>>> Richard Gomes wrote:
>>>> Hi Mike,
>>>>
>>>> Thank you for your directions.
>>>>
>>>> It should be very convenient to detect that ...
>>>>
>>>> @Rate double rate = 1.0;
>>>> @Volatility double vol = rate;
>>>>
>>>> .... cannot compile because the variables are semantically
>>>> different,
>>>> nevertheless both are represented internally as floating point
>>>> numbers.
>>> It had better compile, as annotations aren't supposed to change
>>> compilation behavior. Your error detector could certainly flag it
>>> as an
>>> error, however.
>>>
>>> Tom
>>
>> Hi Tom,
>>
>> JSR-308 is very interesting for our project because we are able to
>> reach very
>> strong type checking whilst producing small, fast, clear, organized
>> and well
>> documented code. More info at
>> http://www.jquantlib.org/index.php/DeveloperCorner
>>
>> In the future we will have to implement the annotation processor
>> and cause
>> compilation errors wherever necessary.
>
> All of your work looks good, but you can't modify the behavior of
> Java-compatible compilers. JSR-308 gives error checkers additional
> support, but compliant Java compilers cannot change their behavior
> based
> on different annotation values. Now, there may be OpenJDK
> implementations which may do that in the future, but they can't be
> considered compatible with Java until the specification of Java
> changes
> to allow annotations to change compiler behavior.
It's not quite that dire: they can at least issue warnings, as
@Override and @Deprecated do.
>
>
> Tom
>
> Tom
>
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
From mernst at mpi-sws.mpg.de Mon Feb 11 13:54:56 2008
From: mernst at mpi-sws.mpg.de (Michael Ernst)
Date: Mon, 11 Feb 2008 19:54:56 +0100
Subject: [JSR308] Custom annotations?
In-Reply-To: <47B07C2E.6050802@sun.com>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<200802102140.08376.rgomes1997@yahoo.co.uk>
<47AF8030.70705@Sun.COM>
<200802110128.47687.rgomes1997@yahoo.co.uk>
<47B07C2E.6050802@sun.com>
Message-ID: <18352.39424.159760.727856@swsmde.ds.mpi-sws.mpg.de>
> Compliant Java compilers cannot change their behavior based
> on different annotation values.
More specifically, when javac is run without an annotation processor
(that is, without a type-checking plug-in), then the presence/absence of
annotations cannot change what errors/warnings javac emits.
If you use an annotation processor with javac, via "javac -processor ...",
then the processor is permitted to issue additional errors/warnings.
I suspect that when Richard said, "[this code] cannot compile", he was
thinking of the situation where a type-checking annotation processor is
being used.
-Mike
From rgomes1997 at yahoo.co.uk Mon Feb 11 17:57:52 2008
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Mon, 11 Feb 2008 22:57:52 +0000
Subject: [JSR308] Custom annotations?
In-Reply-To: <18352.39424.159760.727856@swsmde.ds.mpi-sws.mpg.de>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<47B07C2E.6050802@sun.com>
<18352.39424.159760.727856@swsmde.ds.mpi-sws.mpg.de>
Message-ID: <200802112257.53587.rgomes1997@yahoo.co.uk>
Hi Mike,
That's correct.
I'm thinking to raise error messages when the annotation processor is being
used. At the moment, I'm inserting annotations as directed by JSR-308 guide,
in a preparation for a further step.
Thanks
--Richard
On Monday 11 February 2008 18:54:56 Michael Ernst wrote:
> > Compliant Java compilers cannot change their behavior based
> > on different annotation values.
>
> More specifically, when javac is run without an annotation processor
> (that is, without a type-checking plug-in), then the presence/absence of
> annotations cannot change what errors/warnings javac emits.
>
> If you use an annotation processor with javac, via "javac -processor ...",
> then the processor is permitted to issue additional errors/warnings.
>
> I suspect that when Richard said, "[this code] cannot compile", he was
> thinking of the situation where a type-checking annotation processor is
> being used.
>
> -Mike
From mernst at mpi-sws.mpg.de Tue Feb 12 15:50:00 2008
From: mernst at mpi-sws.mpg.de (Michael Ernst)
Date: Tue, 12 Feb 2008 21:50:00 +0100
Subject: [JSR308] Custom annotations?
In-Reply-To: <200802102140.08376.rgomes1997@yahoo.co.uk>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<18347.1065.852181.418958@swsmde.ds.mpi-sws.mpg.de>
<200802102140.08376.rgomes1997@yahoo.co.uk>
Message-ID: <18354.1656.11276.279399@swsmde.ds.mpi-sws.mpg.de>
Richard-
> It should be very convenient to detect that ...
>
> @Rate double rate = 1.0;
> @Volatility double vol = rate;
>
> .... cannot compile because the variables are semantically different,
> nevertheless both are represented internally as floating point numbers.
Yes, this is easy. The simple checker attached (as VolatilityChecker.java)
does this in our current framework (version 0.4). To use it, run the
following commands:
# First, compile the Volatility annotation and the checker.
javac Volatility.java VolatilityChecker.java
# The test program compiles without warnings using ordinary javac.
javac VolatilityTest.java
# The checker warns of a type mismatch in the annotations.
javac -typeprocessor VolatilityChecker VolatilityTest.java
Here is a transcript of the output:
% javac Volatility.java VolatilityChecker.java
% javac VolatilityTest.java
% javac -typeprocessor VolatilityChecker VolatilityTest.java
VolatilityTest.java:5: (assignment.invalid)
@Volatility double vol = rate;
^
1 error
%
With just a few more lines of code you can add additional functionality:
special checking at certain operations; treating certain expressions as
automatically having the @Volatility annotation; or enabling the
framework's flow-sensitive analysis. The manual gives some guidance, but
let us know if you get stuck. You could write another checker for @Rate
via cut-and-paste from the one for @Volatility. (All this will become
easier in future releases of the framework, but as you see it is pretty
easy even now.)
-Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VolatilityChecker.java
Type: application/octet-stream
Size: 1158 bytes
Desc: not available
Url : https://lists.csail.mit.edu/pipermail/jsr308/attachments/20080212/de59dbeb/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Volatility.java
Type: application/octet-stream
Size: 69 bytes
Desc: not available
Url : https://lists.csail.mit.edu/pipermail/jsr308/attachments/20080212/de59dbeb/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VolatilityTest.java
Type: application/octet-stream
Size: 143 bytes
Desc: not available
Url : https://lists.csail.mit.edu/pipermail/jsr308/attachments/20080212/de59dbeb/attachment-0002.obj
From mernst at csail.mit.edu Tue Feb 12 16:15:44 2008
From: mernst at csail.mit.edu (Michael Ernst)
Date: Tue, 12 Feb 2008 22:15:44 +0100
Subject: [JSR308] Custom annotations?
In-Reply-To: <200802121537.25068.rgomes1997@yahoo.co.uk>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<200802110128.47687.rgomes1997@yahoo.co.uk>
<47B07C2E.6050802@sun.com>
<200802121537.25068.rgomes1997@yahoo.co.uk>
Message-ID: <18354.3200.166659.839390@swsmde.ds.mpi-sws.mpg.de>
Richard-
I think our messages regarding implementation strategy may have crossed.
(Sorry for my slow responses to your messages; I am suffering from poor
Internet connectivity at the moment.)
> The basic idea is:
> I have one annotation which tells other annotations are 'much like a
> typecast' , as we have in C++. Recapping from previous thread:
I don't think that you need to add a Typecast annotation or to tie the Rate
and Volatility annotations together. The two can be checked independently.
In particular, this:
double rate = 1.0;
@Volatility double vol = rate;
is as much an error as this:
@Rate double rate = 1.0;
@Volatility double vol = rate;
In either case the problem is that the vol variable is being assigned from
a value whose type lacks the @Volatility annotation (regardless of what
annotation, if any, its type has).
> 2. Is it correct to say that's enough to have RetentionPolicy=SOURCE for
> @Rate and @Volatility annotations? My aim is to avoid any performence
> penalty as possible at runtime due to performance concerns.
That's should work fine if you always compile your entire codebase from
.java files, without ever reading pre-compiled .class files. If you want
to do the latter, then you'll probably want to retain the annotation at
least into the class files, so that the compiler can read the annotations
on signatures and verify the correctness of method calls into libraries.
You also might want to experiment to see whether a different
RetentionPolicy has a significant impact in your domain.
-Mike
From rgomes1997 at yahoo.co.uk Tue Feb 12 10:37:24 2008
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Tue, 12 Feb 2008 15:37:24 +0000
Subject: [JSR308] Custom annotations?
In-Reply-To: <47B07C2E.6050802@sun.com>
References: <200802030344.39749.rgomes1997@yahoo.co.uk>
<200802110128.47687.rgomes1997@yahoo.co.uk>
<47B07C2E.6050802@sun.com>
Message-ID: <200802121537.25068.rgomes1997@yahoo.co.uk>
I plan to make the compiler give errors/warnings when the annotation processor
is being used. The code should compile without the annotation compiler,
anyway.
If possible, I'd like to ear suggestion from you guys on a tentative idea of
implementation I had.
The basic idea is:
I have one annotation which tells other annotations are 'much like a
typecast' , as we have in C++. Recapping from previous thread:
@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Typecast {
????????// Marks other annotations as 'typecasts'
}
Then I could define some tagging annotations, used much like a typecast:
@Typecast
@Retention(RetentionPolicy.SOURCE)
@Target({ ElementType.FIELD,
? ? ? ? ? ? ? ? ?ElementType.LOCAL_VARIABLE,
? ? ? ? ? ? ? ? ?ElementType.PARAMETER })
public @interface Rate {
????????// No methods - Tagging annotation
}
@Typecast
@Retention(RetentionPolicy.SOURCE)
@Target({ ElementType.FIELD,
ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER })
public @interface Volatility {
// No methods - Tagging annotation
}
Finally, I'd like to raise a compiler error when I try to assign not
semantically equivalent fields, like this:
@Rate double rate = 1.0;
@Volatility double vol = rate; // cannot compile!
I'd like to ear from you guys about some doubts... only some overall
directions, as I know I will have to browse the examples anyway.
1. How many phases the compiler performs and how the annotation processor
plugs into the compiler in order to process the code generation tree? I mean:
@Typecast must be declared/defined in order to give meaning to @Rate and
@Volatility, which must be declared/defined in order to give meaning to the
assignment statement which will end up failing. I add that @Typecast must be
declared in the source code and already known (semantic meaning defined) by
the annotation processor in order to verify if @Rate and @Volatility were
properly declared (without any methods, I mean). Once @Rate and @Volatility
have been accepted, they will be ready to give semantic meaning to fields in
assignments and so on.
2. Is it correct to say that's enough to have RetentionPolicy=SOURCE for @Rate
and @Volatility annotations? My aim is to avoid any performence penalty as
possible at runtime due to performance concerns.
Thank you all and be sure that any suggestion/opinion/critics is highly
appreciated.
-- Richard
On Monday 11 February 2008 16:47:42 Tom Ball wrote:
> Richard Gomes wrote:
> > On Sunday 10 February 2008 22:52:32 Tom Ball wrote:
> >> Richard Gomes wrote:
> >>> Hi Mike,
> >>>
> >>> Thank you for your directions.
> >>>
> >>> It should be very convenient to detect that ...
> >>>
> >>> @Rate double rate = 1.0;
> >>> @Volatility double vol = rate;
> >>>
> >>> .... cannot compile because the variables are semantically different,
> >>> nevertheless both are represented internally as floating point numbers.
> >>
> >> It had better compile, as annotations aren't supposed to change
> >> compilation behavior. Your error detector could certainly flag it as an
> >> error, however.
> >>
> >> Tom
> >
> > Hi Tom,
> >
> > JSR-308 is very interesting for our project because we are able to reach
> > very strong type checking whilst producing small, fast, clear, organized
> > and well documented code. More info at
> > http://www.jquantlib.org/index.php/DeveloperCorner
> >
> > In the future we will have to implement the annotation processor and
> > cause compilation errors wherever necessary.
>
> All of your work looks good, but you can't modify the behavior of
> Java-compatible compilers. JSR-308 gives error checkers additional
> support, but compliant Java compilers cannot change their behavior based
> on different annotation values. Now, there may be OpenJDK
> implementations which may do that in the future, but they can't be
> considered compatible with Java until the specification of Java changes
> to allow annotations to change compiler behavior.
>
> Tom
>
> Tom
--
Richard Gomes
http://www.jquantlib.org/
http://www.linkedin.com/in/rgomes
H:+44(870)068-8205
T:+44(77)9955-6805
From rgomes1997 at yahoo.co.uk Wed Feb 13 18:24:15 2008
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Wed, 13 Feb 2008 23:24:15 +0000
Subject: [JSR308] Lazily compiling the tools
Message-ID: <200802132324.15631.rgomes1997@yahoo.co.uk>
I should have done at the first attempt... :) but I've done now when I
compiled the annotation checkers v0.4
http://www.jquantlib.org/index.php/IDE
Enjoy
--
Richard Gomes
From rgomes1997 at yahoo.co.uk Thu Feb 14 17:02:54 2008
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Thu, 14 Feb 2008 22:02:54 +0000
Subject: [JSR308] Lazily compiling the tools
In-Reply-To: <18356.13551.870318.123370@swsmde.ds.mpi-sws.mpg.de>
References: <200802132324.15631.rgomes1997@yahoo.co.uk>
<18356.13551.870318.123370@swsmde.ds.mpi-sws.mpg.de>
Message-ID: <200802142202.55059.rgomes1997@yahoo.co.uk>
Hi Mike,
On Thursday 14 February 2008 12:32:47 Michael Ernst wrote:
> Richard-
>
> Thanks for the script that automates installation of the JSR 308 tools and
> prevents the need to follow each of the instructions at
> http://groups.csail.mit.edu/pag/jsr308/#Download .
>
> (By the way, the above summary would be very useful at the top of your
> webpage http://www.jquantlib.org/index.php/IDE ! Right now the purpose of
> the shell script is a bit obscure, as is even how to run it.)
Yes. I will complement soon. It was late at night and I was really tired.
>
> A quick question: Were you able to simply follow all the instructions (and
> distill them into one place)?
Waht do you mean exactly?
> Or, did you find any problems with the
> installation instructions that we should correct in future releases?
The instructions are OK to me. When I first went thru them I simply executed
each step as directed and everything worked fine at the first attempt. But I
found the process annoying and time consuming.
I suggest:
1. A 'Requirements' section which mentions that one needs Ant, JDK6 and JDK7
installed. By the way, my script will fail if Ant is not installed .. it
should give an error message and quit properly.
2. Direct links to jdk7 download page and possibly direct links to JDK7 on
windows and linux on Intel platforms.
3. An 'Overview' section (before Requirements) explaining in one paragraph and
no more than 5 small items what will be done.
4. You can provide my shell script to the lazy and really impatient ones, like
me. :)
Kind Regards
-- Richard
>
> Thanks,
>
> -Mike
--
Richard Gomes
http://www.linkedin.com/in/rgomes
M: +44(77)9955-6813
H: +44(870)068-8205
sip:200200 at jquantlib.org
What is VoIP?
See my project on Quantitative Finance
http://www.jquantlib.org/
From mpapi at csail.mit.edu Mon Feb 25 11:46:47 2008
From: mpapi at csail.mit.edu (Matt Papi)
Date: Mon, 25 Feb 2008 11:46:47 -0500
Subject: [JSR308] New releases of the JSR 308 implementation and checkers
Message-ID: <47C2F0F7.7050209@csail.mit.edu>
We have released new versions of the JSR 308 prototype implementation,
three type checkers for finding and preventing errors, and a framework
for writing your own checkers.
The JSR 308 prototype implementation is available at:
http://groups.csail.mit.edu/pag/jsr308/releases/jsr308-langtools.zip
The type checkers we have built and the framework for writing your own
checkers are available at:
http://groups.csail.mit.edu/pag/jsr308/releases/jsr308-checkers.zip
The checkers distribution contains 3 type checkers:
* for null pointer errors
* for equality testing (interning) errors
* for mutability errors (incorrect side effects), based on IGJ
Installation instructions, changelogs, and documentation for both of the
above distributions are included in the zip files themselves and are
also available on the web at:
http://groups.csail.mit.edu/pag/jsr308/
- Matt
From subanark at gmail.com Fri Feb 29 20:20:06 2008
From: subanark at gmail.com (Artemus Harper)
Date: Fri, 29 Feb 2008 17:20:06 -0800
Subject: [JSR308] Wrapper types
Message-ID: <60005e7e0802291720k7512d93nbac7074213b2c74a@mail.gmail.com>
Is there any plan to add wrapper types for each of these annotations.
E.g.
public class ReadonlyWrapper
{
private final T value;
public ReadonlyWrapper(T value)
{ this.value = value; }
public T unwrap()
{ return value; }
}
which would allow encapsulating the meta data at runtime (so I could put
these in List