Continuing the wave of annotation support for developers from all kinds of libraries, Maik Schreiber has has added annotation support to DWR, which released the functionality in the second milestone release of DWR 2.0. Exposing functionality via AJAX is now a matter of adding @Create and @RemoteMethod.

To make a simple class available for remote access, use the @Create and @RemoteMethod annotations:

@Create public class RemoteFunctions { @RemoteMethod public int calculateFoo() { return 42; } }To make simple bean classes available for remote access, use the @Convert and @RemoteProperty annotations:@Convert public class Foo { @RemoteProperty private int foo; public int getFoo() { return foo; } @RemoteProperty public int getBar() { return foo * 42; } }

What do you think of this use of annotations?

1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation 2) This is a good use of annotations, as annotations were intended for use 3) I love DWR, at least until I read up on the google toolkit more.

1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation

2) This is a good use of annotations, as annotations were intended for use

3) I love DWR, at least until I read up on the google toolkit more.

You can still configure DWR using dwr.xml, and sometimes this will be the prefered option. Having a centralized configuration point makes audit easier. On the other hand Annotations are easier to use. Joe. http://getahead.ltd.uk/dwr/

1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation

You *could* use annotations for configuration, but that would be poor use of it. You could just as easily use properties files for code: sql.query=SELECT * FROM ACCOUNT ---- stmt.execute (props.get("sql.query")) ; Is that a good reason to hate properties files because they're used for code? And for what it's worth, the separation between code and data (ergo configuration) is really arbitrary, and the art of programming is knowing where to draw that line.

1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation

On the whole I think there are two types of uses for annotations. The first is as a replacement for configuration - which can make your applications more compact, at the expense of a little less flexibility, as you rightly observe. The second is to replace code that you would otherwise have to write. In Strecks (a set of Java 5 extensions to Struts based largely on annotations - see http://strecks.sourceforge.net/), I am using annotations to replace code, and also to wire up the application in ways that would not be possible without annotations, at least not in a very intuitive way. Viewing annotations as only purely a replacement for XML configuration is quite narrow. Phil Zoio http://www.realsolve.co.uk/

1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation

On the whole I think there are two types of uses for annotations. The first is as a replacement for configuration - which can make your applications more compact, at the expense of a little less flexibility, as you rightly observe.

The second is to replace code that you would otherwise have to write. In Strecks (a set of Java 5 extensions to Struts based largely on annotations - see http://strecks.sourceforge.net/), I am using annotations to replace code, and also to wire up the application in ways that would not be possible without annotations, at least not in a very intuitive way.

Viewing annotations as only purely a replacement for XML configuration is quite narrow.

Phil Zoio
http://www.realsolve.co.uk/

I have said it many times : 1) Use annotations for declarative programming. 2) Prefer XML for configuration (or Java if the configuration is dynamic and necessitate some conditionnal logic). Of course, the line is sometimes flew behind the two but it's a good starting point. Since this is declarative programming, I think this is a great use of annotations.

http://en.wikipedia.org/wiki/Declarative_programming Declarative programming only really has benefits when the programming environment has one key aspect: it's interpreted (Ruby, etc) or dynamically compiled (JSP). JAVA IS NOT EITHER OF THOSE. If you change one of the declarative/annotative sections in Ruby or JSP (assuming its not an include...argh, or did they fix that?), boom, next execution of the code, its fixed. But core java classes must be recompiled, jar/ear/war packaged, server deployed (I'm assuming a hot deploy to be nice). That's not declarative programming. It also opens up the whole Domain-Specific Language pandora's box. Sure, DSLs can provide compact syntax, but from a code maintenance standpoint, they also allow infinite numbers of dialects directly injected into Java. I have the same issues with the infinite numbers of JSP Taglibs out there. Java, despite its fragmented, multi-toolkit/framework state, has lots of basic paradigms shared across those frameworks, so picking them up is relatively basic.

First, why 2 different annotations (@create and @convert) for similar results? Second, aren't these 2 annotation names too short/simple, with a much higher risk of name clashing with other annotation libraries?

First, why 2 different annotations (@create and @convert) for similar results?

There are 2 quite different things that DWR does with your objects. @Create allows objects of the given type to be created and the methods remoted. @Convert allows objects of the given type to be marshalled from Java to Javascript.

Second, aren't these 2 annotation names too short/simple, with a much higher risk of name clashing with other annotation libraries?

The good news is that annotations are used by import statements so there is namespacing for them. Joe.

I agree with Henrique's point Even if import statements give you namespacing, modern IDEs provide import-shortcuts (like "Organize Imports" in eclipse, or automatically importing when you use code completion for the class/annotation type) that make it pretty easy to import the wrong package once in a while (and annoying at other times when you have to consistenly pick the type from a drop down box). Also, if for some reason you do have a class that uses two seperate annotations called.. say... @RemoteProperty - you will have to fully qualify their types in each declaration. (Obviously if you're using a templating style for creating new classes or use few libraries - this isn't that much of an issue.) In any case, this isn't the biggest deal one way or the other - but since you don't have backwards-compatibility issues to worry about at this point, why not call these annotations something that plays nice from the beginning? ideas: Simple variation: @DWRCreate, @DWRemoteMethod, @DWRConvert, @DWRemoteProperty.... Or here are even better psssibilities in my opinion: @Create ->@AjaxRemoteClass or @DWRClass or @DWRLogic or @DWRCallable @RemoteMethod ->@AjaxRemoteMethod or @DWRMethod @Convert ->@AjaxBean or @DWRBean (I would have this with a field called exposeAllProperties=true/false that defaults to false, since -from personal experience- i have found it annoying to have to type out the same annotation for multiple properties in a bean (although obviously some times you really do only want to expose specific properties, which is why I would default it to false) @RemoteProperty ->@AjaxProperty or @DWRProperty -my 3 cents Gary B

While I like this idea, the implementation seems like it could be better. If I choose to use DWR annotations, I still have to specify which classes are annotated in web.xml. One of the reasons folks like annotations is because they give you better refactoring support. Continuing to require configuration in XML files somewhat negates this. Of course, if you're using IDEA, their refactoring supports parsing/changing your XML files, so it's somewhat of a moot point. AFAIK, Eclipse still does not support refactoring w/in XML files. Holy sh** - there's a fricken' preview button!

dwr.xml support is still available, and I have to say prefered by me because it is a central audit point that helps security. So assuming that answers everyone that says "Annotations are Evil", what can we do to make our implementation better? We could search the entire class hierachy for classes with annotations to answer Matt's point. Might be slow. Is there a better way to do this? The reason we chose Create and Convert was to match the element names in dwr.xml. Is name clashes really a problem?

Hi! I think it is better to have annotations look like this: @DWRClass(create=session) public class RemoteFunctions { @RemoteMethod public int calculateFoo() { return 42; } } If none of the public functions are annotated with @RemoteMethod, then all of them are exposed. "create" is an enum with the values {application,session,request,page}. One of them should be default. Not sure which. Joe should know. I'm willing to discuss this further, because I think the current proposal is a naming mistake. Big mistake! Mats

Hi!

I think it is better to have annotations look like this:

@DWRClass(create=session)
public class RemoteFunctions {
@RemoteMethod
public int calculateFoo() {
return 42;
}
}

If none of the public functions are annotated with @RemoteMethod, then all of them are exposed. "create" is an enum with the values {application,session,request,page}. One of them should be default. Not sure which. Joe should know.

I'm willing to discuss this further, because I think the current proposal is a naming mistake. Big mistake!

Mats

My reasoning was as follows: - having the same naming between dwr.xml and @Annotaions is a good thing - although dwr.xml naming is not perfect (particularly ) it isn't too bad. My current feeling is that is isn't broken enough to need fixing. - Naming clashes are not an issue because there is package scoping to annotations anyway. What did I get wrong?

The problem I have with the @Create annotation is that it isn't possible to understand by itself. The case in dwr.xml is different, because there you have a context. The element in dwr.xml can be understood by the fact that it exists in the dwr.xml context, i.e. if you see , then you know it has something to do with DWR by the mere fact that it exists in the dwr.xml file. This is not the case for the @Create annotation. It can be added to ANY class, so what am I to expect if I see it added to a class? I would be bewildered! Create what? Also, I still don't understand what it means. Of course an object must be Created for its member functions to be used, but is it per session, per call, or what? Also, @Create is a verb. Most annotations I've seen so far are adjectives or substantives. It think that is also a hint that @Create isn't a good choice. I have tons of them listed here: http://www.crisp.se/utbildning/StateOfTheArtInServerSideJava.pdf Mats