You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by bu...@apache.org on 2005/08/31 14:46:49 UTC

DO NOT REPLY [Bug 34855] - [attributes] Add support for statements

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34855>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34855

leo.sutic@inspireinfrastructure.com changed:

------- Additional Comments From leo.sutic@inspireinfrastructure.com 2005-08-31 14:46 -------
That is an interesting idea. One could, for example, imagine replacing the
doPrivileged method with:

String password = getPasswordFromUser ();
@@Privileged("userpermission.setpassword")
{
... set the user's password ...
}

However, this is quite a radical new thing:

+ Java's reflection capabilities do not extend to the individual statement
level.

+ There is no defined domain object for statements. We have Class, Method,
Field, but no Statement. Essentially, we need a full syntax tree to be able to
figure out the proper context. This is a pretty big thing to add to C-A.

+ Even if there were such things, you need to run the Java code in a VM that
can understand the annotations and adapt the execution based on them. There is
no such thing commercially available.

+ Parsing of the actual source code is not supported in any existing Javadoc
parser and would increase the complexity of the compiler.

I think, given the newness of this idea, that the best thing to do to achieve a
similar effect, is this:

+ Replace an annotated statement with a call to an annotated method.

+ Use aspects to push/pop certain attributes on/off a ThreadLocal stack on
method entry/exit. That stack can then be interrogated to find the execution
context.

I'll mark this bug as WONTFIX, not because I think it is a bad idea - I just do
not think that it fits with the goals of C-A. The additional code required for
this is immense and I think such an undertaking should be done separately, just
because it is so blasted hard to get it *right*.

I'm also interested in your dissertation - do you have a link to it?

/LS

--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org