|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 42
Messages: 42
Messages: 42
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Pondering About JSR-315, the New Servlet 3.0 Specification
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
|
|
|
Message #280501
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What?!
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.
|
|
|
Message #280502
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-135, the New Servlet 3.0 Specification
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...
<HeavySarcasm>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!</HeavySarcasm>
|
|
|
Message #280516
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
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...
|
|
|
Message #280518
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
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)?
|
|
|
Message #280526
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What?!
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. :)
|
|
|
Message #280531
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why?
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.
|
|
|
Message #280532
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
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/
|
|
|
Message #280533
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
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.
|
|
|
Message #280534
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IDE-support
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..!
|
|
|
Message #280545
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: IDE-support
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?
|
|
|
Message #280552
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
+1 for the author's proposals. Annotations for their own sake will lead us all to other platforms.
|
|
|
Message #280564
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: IDE-support
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.
|
|
|
Message #280566
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
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".
|
|
|
Message #280567
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
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.
|
|
|
Message #280576
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What?!
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:
@Target({METHOD="void doGet(HttpServletRequest, HttpServletResponse res"}, METHOD-MUL="1")public @interface GET {}
That way, the proposed Servlet 3.0 annotations would be quite useful indeed.
|
|
|
Message #280581
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Servlet Spec
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?
|
|
|
Message #280584
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What?!
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.
|
|
|
Message #280586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Old information in this blog
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
|
|
|
Message #280592
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-315, the New Servlet 3.0 Specification
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.
|
|
|
Message #280593
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Old information in this blog
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 ;)
|
|
|
Message #280594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A better article was found on Java.net
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.
|
|
|
Message #280601
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
does aNyone care about readibility and maintainibility
@Target(<font color="navy">{</font>METHOD=<font color="red">"void doGet(HttpServletRequest, HttpServletResponse res"</font><font color="navy">}</font>, METHOD-MUL=<font color="red">"1"</font>)<font color="navy">public</font> @<font color="navy">interface</font> GET <font color="navy">{</font><font color="navy">}</font>
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 ...
|
|
|
Message #280602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Over use of annotation will kill Java
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.
|
|
|
Message #280614
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Just leave it alone and think about other missing features
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
|
|
|
Message #280620
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A better article was found on Java.net
That is based on the old specification as well.
- Rajiv
|
|
|
Message #280621
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Old information in this blog
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@jcp.org.
- Rajiv
|
|
|
Message #280623
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: HttpServlet interface still mandatory
Hi Srini,
Either Jan or I will post a followup blog explaining the async processing model. Look forward to it.
- Rajiv
|
|
|
Message #280624
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: IDE-support
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
</blockcquote>
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
|
|
|
Message #280625
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: IDE-support
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
|
|
|
Message #280654
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: IDE-support
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!
|
|
|
Message #280660
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: IDE-support
Well, to be fair, my understanding of that statement was that the spec would include an annotation processor.
|
|
|
Message #280678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Improvement???
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:)
|
|
|
Message #281256
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We seriously don't need this
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
|
|
|
Message #323758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
To users
Yeah beyond question very
cooperative for the editors it was pleasant to read about it! If you need to get a great job firstofall you need resume writer. Study and don't forget - if you have to work and study at the same time, there areexperts who are ready to guidance you with your resume when you under time pressure and looking for a great job.
|
|
|
Message #328538
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pondering About JSR-135, the New Servlet 3.0 Specification
This smashing facts connecting with Re: Pondering About JSR-135, the New Servlet 3.0 Specification could be shown at dissertation or in the thesis service to buy papers online from paper writing service.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
