Pondering About JSR-315, the New Servlet 3.0 Specification

Home

News: Pondering About JSR-315, the New Servlet 3.0 Specification

  1. The new specification for Servlets 3.0 is coming, and Roy van Rijn takes a good look at it. He sees some good things, but also something that makes him want to stand up and make an alternative proposal. Here it is. Read the article

    Threaded Messages (38)

  2. What?![ Go to top ]

    JSR 135 is a completely different beast: http://jcp.org/en/jsr/detail?id=135 ;)
  3. Re: What?![ Go to top ]

    JSR 135 is a completely different beast: http://jcp.org/en/jsr/detail?id=135 ;)
    Seriously, TSS. Hire an editor. Posting crap verbatim from Joe Schmuck only ends up with crap like this making the front page. This is sadly not the first time something like this has made the front page. It is, however, a good example of why I visit this site less and less.
  4. Re: What?![ Go to top ]

    JSR 135 is a completely different beast: http://jcp.org/en/jsr/detail?id=135 ;)
    For anyone interested, who isn't already aware, the correct JSR is 315.
  5. Re: What?![ Go to top ]

    Hmm, somebody at TSS who's bit dyslexic has edited the article apparently and changed 315 into 135... The only reference left to 135 now is the image above the article. Anyway, I'm very curious to know your opinions on this (ab)use of annotations! Do you like the proposed additions or not? I'd rather see people here giving opinions and thinking about the future of Java then complaining about mistakes from the editor. :)
  6. Why?[ Go to top ]

    I have to agree with the other posters - what's wrong with interfaces? Annotations have their place, and I've found them extremely useful for some things, but it really seems that in this case, they're being used as a replacement for interfaces. One of the things that I really like about java is the strong typing and this seems to be just throwing that out the window. That being said, the annotations seem useful for the mappings. We can discuss the merits of that approach (security, debugging, etc), and I probably wouldn't use it very often, but a lot of people seem to find that sort of thing useful.
  7. Re: What?![ Go to top ]

    Anyway, I'm very curious to know your opinions on this (ab)use of annotations! Do you like the proposed additions or not?
    I agree with the article. Using annotations for things that are truly meta data helps a lot. For instance, annotations make EJB and JPA a real pleasure to use. On the other hand, using annotations like @Get to designate a method to something special is questionable. Interfaces already exist for that. Of course, annotations are finer grained. With interfaces you MUST implement all methods. This too, can sometimes be a problem; it can simply be tedious to implement 10 methods when you're only interested in one of them. But it can also be really problematic if you simply don't know how to implement a certain method and just want the framework to do some default thing instead of calling your method. A major problem with annotations is that you can't easily specify the signature of the method to which they apply. If only you could specify an annotation like this: [code]@Target({METHOD="void doGet(HttpServletRequest, HttpServletResponse res"}, METHOD-MUL="1")public @interface GET {}[/code] That way, the proposed Servlet 3.0 annotations would be quite useful indeed.
  8. Re: New Servlet Spec[ Go to top ]

    I agree to the points made by the author. As many pointed out, web development has moved away from a pure servlet model. Do you really want to add annotations just because it could be? I would just leave the way it works. May be the mapping info is a little useful, but I like configuring servlets in web.xml. I like to stay as far away from annotations as possible. I think it adds more confusion due to little IDE support. Can anybody tell what is the advantage of adding servlets at runtime?
  9. Re: What?![ Go to top ]

    A major problem with annotations is that you can't easily specify the signature of the method to which they apply.
    I agree with you, there is no gain, an interface based approach (HttpServletInterface or similar) with methods doGet and doPost is more expressive and calling these methods is by far easier.

  10. @Target({METHOD="void doGet(HttpServletRequest, HttpServletResponse res"}, METHOD-MUL="1")public @interface GET {}
    why complicate things so much? to have your job security ? Soon there will be some nut case on sourceforge who will add configuration file to this mess under the name of "reuse the annotations" and that will result into annotations of annotations and the complication just goes on..... no one theese days wants to keep it simple .. Servkets shoudnt be dealing with anythng but reading req params, do some filtering n stuff , call some business services/beans and respond back to the caller ...
  11. This is a world where every J2EE project is using very established Web frameworks like Struts, Spring MVC etc and why the hell in the whole world [other than someone looking for job safety and keep making changes to something very matured]anyone should think of changing these stuff? Ya right, whenever we have projects upgrade happening from different versions of J2EE specs or application server, architects/developers like me can go to conference rooms and present to the manager and developers "Application Migration to new version of J2EE/App Server - pros and cons" and then show off!!!! Have been working with J2EE since its 1.0 version and i believe effort can focused on many other features missing from the spec. Thanks -Mahesh Chalil
  12. Woah, wait a minute, hold up... so I can have servlets and filters in my mobile media applications now?!? Awesome! This spec rules! That's just what I've been waiting for! Java on the Jesus Phone, here I come! Oops, sorry, let me try that again... Woah, wait a minute, hold up... so I can have servlets and filters in my mobile media applications now?!? Awesome! This spec rules! That's just what I've been waiting for! Java on the Jesus Phone, here I come!
  13. I agree with the author of the article. I also think it's very bad the whole world jumped on the annotation happiness train. And why? Nobody knows. It looks like the Servlet EG looked at the Spring MVC annotations, thought "We also need this", but in the hurry have forgotten why those annotations add value to Spring MVC. An advantage of using annotations in Spring MVC is that you gain a lot of flexibility when defining your @RequestMappings. With annotations, you use a lot of strong typing which is one of the strong points of Java in the first place. If you don't want this, don't use Java. You lose many refactoring opportunities and let's not forget to mention the dangerous classpath scanning. I would suggest, don't change the Servlets programming model. It only makes things worse. Instead, try to make the other specs (that build on it) better, like Web Beans, JSF 2.0, Bean Validation, EJB 3.1...
  14. I agree with the author of the article. I also think it's very bad the whole world jumped on the annotation happiness train. And why? Nobody knows.
    I agree. Why do we need to overuse annotations while we could simply use interfaces (to implement)?
  15. I agree with the author of the article. I also think it's very bad the whole world jumped on the annotation happiness train. And why? Nobody knows.

    I agree.
    Why do we need to overuse annotations while we could simply use interfaces (to implement)?
    Well, we may need a policy for interface/annotation co-existence. IMHO, annotations supersede interface tagging and is a (meta)model for creating contract-DSLs. Then, I see one use of a annotation set/contract like a configuration of such contract. Following that idea, interfaces and annotations could be used together: one idea could be to use interfaces for coarse-grained tagging and annotations for finer-grained tagging. Unfortunately, the weak point with annotations is that, if annotations have special syntax built-in into Java language for expressing them, there is no special syntactical sugar for querying, just as simple as "instanceof" for interface tagging... Both, interfaces and annotations, look like just 2 contract-like implementations that still need to learn to live together. Dominique http://www.jroller.com/dmdevito/
  16. I agree with all of you who suggest programming to interface model. I don't think Annotation is used for this. The most important thing to me is the IDE auto generated methods when programming to interface where annotation gives me nothing; the code generation really speeds up my development a lot rather than annotation in this case.
  17. IDE-support[ Go to top ]

    Queue the IntelliJ users: "A decent IDE will give you support for this in no-time!" ;-) But that doesn't mean its the right solution..!
  18. Re: IDE-support[ Go to top ]

    Exactly. Also, forget IDE support - what about my compiler? My CI server? Are they going to catch violations in the contracts specified by annotations? Or am I going to have to write unit tests to check for this?
  19. Re: IDE-support[ Go to top ]

    The annotation checking can be implemented using an APT compiler extension. Fairly trivial work, and f.e. Eclipse thru builders and others IDE already support this standard way. Standard javac on the command line can also discover and chain APT compilers automatically. http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html What is unclear in this article is how web.xml will become optional (I do mean optional, not generated by APT), what will take precedence between XML mappings and annotation based mappings, etc.
  20. Re: IDE-support[ Go to top ]

    The annotation checking can be implemented using an APT compiler extension. Fairly trivial work, and f.e. Eclipse thru builders and others IDE already support this standard way. Standard javac on the command line can also discover and chain APT compilers automatically.
    http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html Yes writing an annotation processor can and will take care of the requirements of the annotations.


    What is unclear in this article is how web.xml will become optional (I do mean optional, not generated by APT), what will take precedence between XML mappings and annotation based mappings, etc.
    The rules are defined in the specification. Please review and provide feedback when it becomes available. - Rajiv
  21. Re: IDE-support[ Go to top ]

    The annotation checking can be implemented using an APT compiler extension. Fairly trivial work, and f.e. Eclipse thru builders and others IDE already support this standard way. Standard javac on the command line can also discover and chain APT compilers automatically.
    http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
    Yes writing an annotation processor can and will take care of the requirements of the annotations.


    What is unclear in this article is how web.xml will become optional (I do mean optional, not generated by APT), what will take precedence between XML mappings and annotation based mappings, etc.
    The rules are defined in the specification. Please review and provide feedback when it becomes available. - Rajiv
  22. Re: IDE-support[ Go to top ]

    The annotation checking can be implemented using an APT compiler extension. Fairly trivial work, and f.e. Eclipse thru builders and others IDE already support this standard way. Standard javac on the command line can also discover and chain APT compilers automatically.
    http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html

    Yes writing an annotation processor can and will take care of the requirements of the annotations.
    This response is so absolutely brain-dead clueless that it brings tears to my eyes. I DONT WANT TO WRITE AN ANNOTATION PROCESSER TO USE SERVLETS!! I HAVE WORK TO DO!! This is a lousy idea, and the fact that is not necessary should have been the first clue. It is incomprehensible to me why some groups in the Java world work so hard to make things more difficult by changing things that aren't broken. The servlet spec is one of the great success stories for JEE ... don't screw it up!
  23. Re: IDE-support[ Go to top ]

    Well, to be fair, my understanding of that statement was that the spec would include an annotation processor.
  24. Improvement???[ Go to top ]

    I do not see any improvement in using annotations that way. The only thing you will achieve is difficult to read code. It seems to me that the jsr guys are behaving like script kiddies insteadof solid java developers. It is one of the worst developments I have seen in a while. The author of the article points out some serious design flaws and points out that annotations should NOT be used everywhere. If this is the trend then .Net will be the better architecture soon:)
  25. +1 for the author's proposals. Annotations for their own sake will lead us all to other platforms.
  26. An interface with no methods is a kind of a annotation, they are useful to "annotate" the class as a hole, this approach is used for instance with java.util.Set. There is almost no difference between empty interfaces and annotations. Ok you can cast to the interface but this interface has no methods what is the gain? Ok the interface can be used with instanceof but the annotation can be detected too. One advantage of annotations is they can be "parametrized" this capability is missing in empty interfaces. The principal drawback is annotations are based on Java 1.5 (current servlet specification is Java 1.4 compatible), but there is no reason to be so conservative. Anyway I miss an annotation like @Servlet, this way we can annotate the class as a "servlet".
  27. Did you read the article? One of the things you have with interfaces (and not with annotations) is strong typing. Not just the IDE, but also your compiler will complain if you have typos, or wrong signatures. Why would you want to have a @Servlet annotation? What will it add over having 'instanceof HttpServlet'? Nothing I can think of... Not using annotations in places that don't make sense isn't being conservative, its just correct! I don't hate annotations, for example I love them in JPA. But use them carefully. This (old) proposition would have caused the Servlet to become less strongly typed and will add nothing, will only confuscate the future users... these kind of annotations I DO hate.
  28. I really like his Proposition 2, with the caveat that going in that direction encroaches upon the JAX-RS REST spec lightly. Arguably, the REST spec is a better spec for "Servlets" than the Servlet spec is, at least in light of how most folks do web programming today. Servlets are more raw infrastructure than spectacularly useful for serious web work today anyway. Have you ever been to, say, a park that has a concrete pathway that the designers and planners made to get from parking lot to the park center, yet, nearby you find a worn path in the grass that, regardless of the fact that the concrete path exists, is the path that everyone takes anyway? That's how I view the modern action frameworks that are built on top of the Servlet spec. While modern developers leverage the Servlet spec, nobody actually USES it. Not directly at least. In fact, today, few people seriously advocate using raw Servlets and instead point new users to one of the action frameworks, because the frameworks simply offer a better path than what comes already in the Servlet container. Proposition 2, in the paper, could easily modernize the Servlet spec to where perhaps the action framework isn't the first thing folks look for, as it solves one of the initial pain points of Servlet (simply mapping it in the web.xml). If they added a thread safe "Servlet per request" model on top of the "Servlet per application" model we have now, that's another quick change that really helps developers. Then the action frameworks basically end up offering their style of binding and validation. I think this could easily be done with annotations and configuration, and by default the "standard old school" Servlet will keep it's old behavior for compatibility.
  29. A better article was found on Java.net[ Go to top ]

    Check it out. This article seems more complete and through. http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3.html
  30. Good article! The point of my article wasn't to explain (in depth) every aspect of the Servlet 3 spec, because it has been done before (your link, or just read the ERD). Mostly I wanted to show the new annotations, show why the proposal was broken (IMHO), and suggest fixes.
  31. That is based on the old specification as well. - Rajiv
  32. Old information in this blog[ Go to top ]

    All, This is Rajiv Mordani - the specification lead for JSR 315. While the blog does reflect things that are in the early draft review of the specification available at the jcp.org website the information is outdated and the updated public review specification will be posted soon. In the mean time I have written a quick blog at http://weblogs.java.net/blog/mode/archive/2008/12/servlet_30_jsr_2.html. This is just a quick update. I will post more detailed blog in the coming days. - Rajiv
  33. Re: Old information in this blog[ Go to top ]

    Rajiv, Thanks for the quick update! At first glance the changes to the spec look great, I'm very curious how the new specification will turn out. I have already send a couple of emails to the JCP-address (before writing and posting this article) but didn't get any reply.... That is why I went ahead and submitted it, the attention seems to have worked ;)
  34. Re: Old information in this blog[ Go to top ]

    If you sent to the expert group mailing list it won't be delivered. Only expert group members can post to the alias. I haven't seen any mails from you to the feedback alias. Please be sure to use the jsr-315-comments at jcp dot org. - Rajiv
  35. Thanks to Rajiv for providing a quick update. Though, I am a bit unclear on the use of AsyncContext which Rajiv has mentioned in his article and will be grateful if someone provides information. http://weblogs.java.net/blog/mode/archive/2008/12/servlet_30_jsr_2.html It was a great article from Ron and provides a good insight into proposed changes.
  36. Hi Srini, Either Jan or I will post a followup blog explaining the async processing model. Look forward to it. - Rajiv
  37. Over use of annotation will kill Java[ Go to top ]

    Totally agree with the author who makes his point in a practitioner stance. The Java culture is changing. When annotation is introduced, I saw a lot of people eager to use it without thinking too much, some time just break the Java philosophy such as type safety, language purity. I believe the inventor of Java will feel disappointed on those culture changes. Another example I saw in java.net is: http://today.java.net/pub/a/today/2008/09/11/jsr-305-annotations.html. Which is supported by a lot of people. It's dangous for java.
  38. We seriously don't need this[ Go to top ]

    That whole POJO/annotations hype is leading away from stable OO design. All those priests teaching their disciples that programming against interfaces was the way to the holy grail were right indeed. Java EE is full of that paradigm - and that's perfect the way it is. Am I old-school? I don't think so... Separating implementation & configuration aka code & infrastructure aka Servlet & web.xml aka separation of concerns has proven to be successful. This JSR might solve a few particular "problems" (I'd rather call them cosmetic defect) for very few people, but that doesn't justify the whole paradigm-shift. Such JSRs are an indication that the Java world is running out of true innovations. my2cents, Marcel
  39. http://www.theserverside.com/tt/articles/article.tss?track=NL-461&ad=679286&l=Stripes15&asrc=EM_NLN_5242511&uid=2701990