Skip to main content

[jsr338-experts] Ambiguity of Annotations (was Re: JPQL: Sorting on optional references)

  • From: Werner Keil <werner.keil@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Ambiguity of Annotations (was Re: JPQL: Sorting on optional references)
  • Date: Tue, 28 Aug 2012 17:17:09 +0200

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 @NotNullannotation 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:

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

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"



[jsr338-experts] Ambiguity of Annotations (was Re: JPQL: Sorting on optional references)

Werner Keil 08/28/2012
 
 
Close
loading
Please Confirm
Close