Val's Blog
Lots of stuff for Web 2.0 freaks and Javaholics
Feeds RSS | Atom | RDF
 
 
Albert Einstein: "Intellectuals solve problems: geniuses prevent them."
[ Login ]

May 2004
SunMonTueWedThuFriSat
       1 
 2  3  4  5  6  7  8 
 9  10  11  12  13  14  15 
 16  17  18  19  20  21  22 
 23  24  25  26  27  28  29 
 30  31      
Apr  |  Today  |  Jun
XML Feeds   Subscribe with Bloglines

Javaranch Sheriff   My LinkedIn Profile
Drop me a line or two   Bloglines Blogroll
JavaRSS   Referers
How cool are you?   My Reviews

Next trips...
SpringOne 2008 (Jun 11-12, 08)
Ajax Exp. 2008 (Sep 29-Oct 1, 08)
Top 10 entries (#hits)
(As of Nov 30, 2007)


Top 10 entries (#hits/day)
Come Back (5.032)
(As of Nov 30, 2007)
Recent Blog Entries
Recent Blog Comments
Re: Review of "Marketing Management 12th"
i know marketing management by kotler is good book but the problem is that the management part of this book is totally missing as fare as i know managemet is complete different subject and it should not be mixed i am student of MBA i was looking at ass...

Re: Review of "Pro Spring"
Using simple POJOs + factories without Spring for "echo" and "counter" would be a lot more easier. No need to write those XML files... So, in this case using Spring makes me write a lot more code... (OK, you can generate everything with the help of And...

pls urgent
Hi I am trying to generate the word doc but i m not understanding wats happening any one pls figure it out /* * WordAPI.java * * Created on May 30, 2006, 10:50 AM * * To change this template, choose Tools | Template Manager * and open the te...
Archives (# entries)
Links
Other Blogs
Other Blogs

Reviewing
Reading
Locations of visitors to this page
What they once said...
 

While the advantages of annotating the code (JSR 175 - Metadata Facility for Java) are somewhat clear to me, I have been wondering what the drawbacks could be. I don't deny that being able to specify auxiliary information for classes, interfaces, fields and methods is a good thing. What I question is the means we will supposedly use to achieve this, namely, we will be putting the whole stuff directly within the code. If not used with care, annotations could (and most certainly will) massively contribute to code pollution as legitimately pointed out in James Strachan's web log this morning.

James also mentions that future IDEs should be made more clever and handle most of these boring details for us. For the most geekish of us, I can also imagine a functionality where we can define the granularity of the details we want to see in the code and then use some sort of slider control to zoom in/out the code details. Yesterday, the Eclipse community announced that code folding has been added to their IDE. Great!! I see this as a first step towards removing visual clutter in a selective and temporary way. Although, much more will have to be done in order to allow developers to use their eye power more efficiently.

Actually, the problematic is quite simple: we want to get rid of the many different documents that describe some aspects (not necessarly meant in the AOP sense) of the same concepts and put everything together at one central place, namely in the code. That way, it seems to be less likely that we forget something when we have to do some changes. While this is questionable, I don't doubt in the expressive power of annotations. What I fear is that this expressiveness could be used (inadvertantly) in a way that ends up not being beneficial to developers, thus defeating one of the primary goals it way initially intended to attain.

This pretty much goes in the same direction as mentioned in my previous blog, namely that current tools will have to be considerably improved to successfully address problems such as this one in the future.


Without reading this, I posted about the the same thing today. I agree. I am a little scared baggage this will bring.
I had pretty much the same apprehension when I read about the feature in the Tiger beta docs. Seems to me just another means to add things to a codefile that shouldn't be in there but either in the documentation or in a separate class. Much as Bruce Eckel's adding unit tests inside Javadoc blocks which he then generates source from instead of building them as separate classes...


Add a comment

Title
Body
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Math Quiz 9 + 9 = (Helps stop blog spam)
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).

TrackBack to http://radio.javaranch.com/val/addTrackBack.action?entry=1084533540000

 
About this Blog