Dear all,
Please allow me to untangle that from the point Oliver raised. Potentially
relevant to the overall EE list, too, let's see, what Linda says...?
Looking at the "nullable" attribute some annotations, while the actual
query may not be changed, you can sure contradict the *nullable = true* by
adding a *_at_NotNull*annotation from Bean Validation to it. The two are
legitimate together:
http://stackoverflow.com/questions/2725111/hibernate-onetoone-notnull
Java 7 and EE7 most likely give you a Runtime Exception, maybe some IDE
warning if it provides JPA support, but the compiler itself is not going to
do much about it.
JSR 308, so far scheduled for Java 8 aims to change that:
http://types.cs.washington.edu/jsr308/
Unfortunately, both the Spec Leads of 308 deny any responsibility or
ownership of checker annotations, nor have the architects at Oracle so far
take precautions to avoid a big mess like this
@Entity
class Person {
@OneToOne(nullable = true) @NotNull @NonNull @Nullable(true) Address
address;
}
BeanValidation as of now
Checker Annotations based on JSR 308 as of now (from Java 8)
Given a combination of Java EE 6/7 and JSR 308 this would be perfectly
fine. Most likely the two checkers would cause a compiler error already,
but one alone, let's say @Nullable(true) instead of a sensible integration
with all existing stuff will increase the big mess around these annotations
already present
http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
I probably forgot @Nonnull as of JSR 305 which at the moment polutes the
JDK already, but has no effect. At the very least, instead of having people
stuff in more annotations of all different kinds, either @Nonnull should be
killed with Java 8 and replaced with something else, or it should be used.
Most likely the conflict with BeanValidation (which is primarily used by
JPA) would be unavoidable then.
Sorry to hijack the thread, I hope, at least Linda keeps an eye on that or
plans to do something about it, so that we can avoid annotation chaos we
inherited in other areas, e.g. @Inject vs. other legacy approaches, etc.?
Thoughts, suggestions?
Thanks,
--
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* Eclipse Day Poland: September 13 2012, Krakow, Poland. Werner Keil,
Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Eclipse
STEM, UOMo and Hudson"
* Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera.
Werner Keil, JCP Executive Committee, JSR-321 EG Member will present
"Trusted Computing API for Java™"
* Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil,
Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E
class Continuous Delivery with Hudson, Maven and Mylyn"
* JavaOne: September 30-October 4 2012, San Francisco, USA. Werner Keil, JCP
Executive Committee will represent "Eclipse UOMo, STEM, and JSRs involved
in, e.g. 331 or JCP.next"