-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: JSR 305
PostPosted: Fri Mar 28, 2008 9:56 pm 
Newbie

Joined: Fri Mar 28, 2008 9:45 pm
Posts: 2
Location: Eugene, Oregon
Are you guys working at all with the JSR 305 (FindBugs-type annotations) expert group? The functional overlap is clear, though obviously the application is rather different.

Once interesting thing about JSR 305 in its current form is how it does everything through meta-annotations - that is, @Nonnull isn't just an annotation, it's a meta-annotation that you put on your own "not null" annotation. So theoretically the javax.validation.NotNull class could carry the @javax.annotation.Nonnull annotation, and now FindBugs would automatically check that no-one tries to assign null to that field or method parameter.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Mar 29, 2008 10:38 am 
Newbie

Joined: Tue Dec 04, 2007 2:48 pm
Posts: 6
IMHO, the functional overlap is only in declaration of constraints because the JSR 305 the check for "error" is done statically and, if dynamically, it will be "online".

THe JSR 303, the check for error will not be "online". Of course the 2 could work together if thats what the programmer wants, but I think it will be JSR 305 the will plug into the JSR 303.

ps.: sry I could find better word then "online" to express myself.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 30, 2008 7:38 am 
Newbie

Joined: Sun Mar 30, 2008 7:09 am
Posts: 3
Location: The Ether
Emmanuel can speak for the group, but in my opinion there is no functional overlap.

JSR-305 is about static analysis. Nothing created in 305 ever makes it into business semantics. JSR-303 is exactly the opposite. We are about binding declarative constraints on *objects*, i.e. data, whereas 305 is constraining *logic.*

Put another way, 305 is like extending the static semantics of the language with keywords (which we can't do practically due to lexicographical constraints). For example, C# has an "override" keyword, in Java this is @Override. Which checks for properly overridden method signature.

Also, though we provide a basic set of annotations out of the box, 303 is about a framework for domain-specific validation, rather than a library of all-purpose validation annotations (we simply can't do the latter).

_________________
Dhanji R. Prasanna
JSR-303 Expert Group member

Fee Fi Fo Fum, do you smell Dependency Injection?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 01, 2008 11:32 am 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
Bill Pugh and I wanted to start a discussion on the subject. We haven't done it so far.
I am not convinced declaration can be reused. But we wanted to explore reusability of the validation machinery (ie being able to reuse a 303 validation implementation in 305).
Overlapping is not as obvious as it looks at first sight but this need to be explored (note that 305 depends on Java 7 AFAIK and JSR 303 does not).

_________________
Emmanuel


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.