«« Next » « Previous
«« Next » « Previous

Link Details

Announcement

iPhone DZone: Fresh Links On Your iPhone by matt at Sat Jul 05 14:09:51 EDT 2008

Reading DZone on your iPhone just got a little bit easier. Visit http://dzone.com/iphone from your iPhone to try out our beta iPhone support. You can view stories, filter by tags, and login. We'd appreciate your feedback at feedback@dzone.com.

The more, the merrier! Login and vote now.
Link 80819 thumbnail

By bloid
via bc-squared.blogspot.com
Published: May 14 2008 / 10:34

I have to say that if Java picks up JSR-308 (which I found out about from here), then you can consider me the first one to jump off the Java train. Seriously...do we really need this in the Java language?
  • 17
  • 3
  • 1495
  • 668

Comments

Add your comment
User 209464 avatar

willcode4beer replied ago:

0 votes Vote down Vote up Reply

excellent post

User 191349 avatar

raveman replied ago:

-1 votes Vote down Vote up Reply

i disagree, i think author should understand that people use java because of jee. @NotNull annotation would rule and remove a lot of useless code and errors (some people dont check method params and weird things can happen). plus you dont have to use annotations in java.

User 282119 avatar

Rob Signorelli replied ago:

0 votes Vote down Vote up Reply

In a world where you never have to work with anyone's source code but your own, the "you don't have to use annotations" idea is passable. But that's not the case. The fear is inheriting a garbled unreadable mess from someone else where you've got almost as much annotations to sift through as you do code to decipher. And for what? So you didn't have to do a null check in your method... just doesn't seem worth it.

User 152955 avatar

Gregg Bolinger replied ago:

-1 votes Vote down Vote up Reply

The biggest problem I see with 308 is its border line Validation (which is another JSR proposal whose number eludes me at the moment). I agree that annotations are over used but I find them useful if used correctly. At some point enough is enough.

@NonNull
@ManyToMany(
@JoinColumn
)
@LetsAddAnotherOneFromSomeOtherAPI
@HowAboutOneMore

User 152955 avatar

Gregg Bolinger replied ago:

0 votes Vote down Vote up Reply

BTW, I am not jumping ship just because of this so I don't agree that anyone should. They are easy enough to ignore. A quick Search and Replace?

Find @NonNull ReplaceWith ""

HEHE

User 272422 avatar

htowninsomniac replied ago:

0 votes Vote down Vote up Reply

I strongly disagree with this post. Not only is it mainly a "me too" post from "When Should You Jump? JSR 308. That's When.", it lacks substance. And sentences like "First we got Generics. We all know how that went. While it's passably better than what was originally there, it's still not worth a damn." seriously make me wonder how anyone could have missed the incredible benefits that generics have brought us. The implementation with erasure wasn't good, but it IS better than what was originally there, and it IS very much worth the while. Maybe I'm just not a good programmer, but I really like the static guarantees that generics give me. I need this hand-holding, and I believe so do most programmers.

Annotations and annotation processors can provide us with similar static guarantees for other issues, like non-null values, mutability, problems with equality and identity. One of the best things about annotations is that programmers, like the authors of the two blog posts, can completely ignore them if they don't want them. It's hard to use Java by now without using generics; that's not true for annotations.

Again, the implementation of annotations isn't perfect, just like the implementation of generics isn't, but the possible benefits of the more complicated syntax will by far outweigh the costs.

Please see the post on my blog for a more detailed response:
http://www.concurrentaffair.org/index.php/2008/05/14/jsr-308-animosity/

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.