OODMS? And you're talking about low market penetration for Seam in three years? Object databases have been around for 20+ years by now ;-)

And as I recall saying, annotations might not be the best thing but it's what the de-facto standard currently. If you have many things to describe about something, you are going to need a few more words than usual. Or annotations. Or foobars (or whatever the new tech will be). Actually, it's quite a nice example you got there:

@Produces @Alternative @CustomerDatabase

it reads almost lite english. If you need to describe that about a point in the code, how could you do it any simpler?

Gavin King wrote on Nov 06, 2009 02:54:


Nice idea in theory (that about multiple compatible JPA implementations)

Francisco, I'm getting increasingly annoyed with you posting the same pet issue on every single thread in every message board. The Hibernate team has many important issues to deal with like implementing JPA2 and fixing actually important bugs. The question of what exception type gets thrown when you have marked your attribute as not-null at the schema level, but not at the object level (which is more or less your own programming error) is just not one of them. So please give it a rest for f***s sake.

IMO is completly on topic, we are talking about the creation of an SPI ecosystem around JSR 299, and you can not really have compatibility without an open and public way of testing for that compatibility. I am also getting a little tired of you saying that bug is my programming error that bug is because Hibernate calls org.hibernate.engine.Nullability.checkNullability to verify something that according to your interpretetion of the the JPA spec should NOT be verified, you wrote it yourself:

Gavin King wrote:

Hibernate' behavior is correct. nullable=true is defined by the spec as a hint for schema generation.


http://java.sun.com/javaee/5/docs/api/javax/persistence/Column.html#nullable()


For object-level validation, use optional=false:


http://java.sun.com/javaee/5/docs/api/javax/persistence/Basic.html#optional()

But hibernate uses nullable for object-level validation not only as a hint for schema generation. And the spec says nothing about what to do if nullable and optional contradict each other, so each implementation deals with that situation different.

I feel concerned that you are going to follow the same approach when other implementations of the JSR 299 follow the spec as you think it is implemented in Weld, and not as it is actually implemented. I think  it is a valid concern to raise here: There should be an easy open way to test if all the implementors of a Spec are actually compatible, I would raise that issue at the JSR forum, but anyone can see that nobody answers post sent there.

Just answer this simple question: What part of the spec says that org.hibernate.engine.Nullability.checkNullability should exist and do what it does (use nullabe=true as object-level validation)?

The answer is simple:None. org.hibernate.engine.Nullability.checkNullability might have been a good idea, but right now, is only there to make Hibernate incompatible with the JPA spec.

I can understand that you feel annoyed by me, but imagine how I feel after the you simply rejected my very valid bug report and after that decided to ignore all my posts (posts I made to the Hibernate forum, not here) for the last 6 months?

Do you really think that helps me (or anyone) believe that standardization issues between JSR 299 implementations are going to be easy to fix?

Very clearly, you have a programming error. You have an attribute declared @Basic(optional=true) @Column(nullable=false). How is that possibly meaningful?! You have told Hibernate that you have an attribute which can be null, but which is going to be persisted to a column declared NOT NULL. How is that possibly going to work? You have an error. Please stop blaming Hibernate for behaving a little bit strangely when given a mapping that is completely wrong and nonsensical. Actually, in this case it would be better if Hibernate refused to start, since it has been given a broken mapping.

Francisco this is not a Hibernate forum and if you keep on about this stuff I will start deleting your posts. You are clearly way off topic. No, this has nothing at all to do with SPIs and portable extensions.

Now please can we talk about something that people other than you care about?

I just can not belive that even when I put it as a simple question you managed to ignore and misunderstand the issue... this is so sad.

Arbi, threats are a great way to win a discussion (who cares if you are right or you are wrong), keep doing it, hope you never have to be in my place.

Arbi Sookazian wrote on Nov 06, 2009 20:36:


it's the way GKing is and will be and what makes him unique.  you have to play by their rules.  it's their forum and they're in charge...

Yes, you are right, it is not worth the effort, I do not know what got in to me.

let's set aside personal issues and attitudes, etc. and continue plz...  we're all winners here ;)

so, @Produces @Alternative @CustomerDatabase can be morphed or concatenated into @ProducesAlternativeCustomerDatabase perhaps?  Why not just one annotation to make things simpler?  Unless we're concerned about fine-grained meta-data reusability...

You really think @ProducesAlternativeCustomerDatabase is a better idea? less @ is, IMO not such a great advantage and you would lose flexiblity to mix you annotations in new ways...

I don't want to see like 12 @ signs before my methods, you know?

Why? What is you problem with @? (You can always switch to .NET and use [ ] for you annotations... ;-)

Arbi Sookazian wrote on Nov 06, 2009 20:45:


Here is an example, (sorry it's Hibernate, but not trying to bash Hibernate at all, ok?):

@ManyToOne( fetch = FetchType.EAGER, cascade =   
   { javax.persistence.CascadeType.PERSIST, javax.persistence.CascadeType.MERGE } )  
 @JoinColumn( name = "PERSON_DETAIL", nullable = false )  
 @Where( clause = "ACTV_ID = 'T'" )  
 @Cascade( { CascadeType.SAVE_UPDATE, CascadeType.MERGE, CascadeType.DELETE } )  
 @Cache( usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE )  
 @EqualsMember  
 @NotNull  
 @Valid  
 @Message( "${msg.invalid.person.detail}" )  
 @XmlElement( name = "person-detail", required = true )  
 public PersonDetail getPersonDetail()  
 {  
     return personDetail;  
 } 

Arbi... An question about annotation hell with @NotNull, @JoinColumn(nullable = false)? Please don't torture me with such flamebait!

My tooling will of course color them nicely by category and allow me to fold/hide away those annotation categories I'm not interested in...

Arbi Sookazian wrote on Nov 06, 2009 00:35:


perhaps that is his real name (e.g. Marilyn Manson and Hollywood actors).  and does it really matter?

Yes, we feel it does. There is quite a body of research about how people will behave very differently when on in an anonymous forum (and in general behave in a way that is considered worse by most societies) - consider for example Anonymous Coward on TSS. One way to combat this is to require people to use a real name as it decreases the level of anonymity.

Right, the issue here is that we have a conflict between:

• Make the TCK perfect (which takes time)


• Actually finish JSR-299

(FYI for the people who luckily know less about JCP process than Gavin and I do, you can only fix existing tests in a TCK after the spec is final, you can't add tests).

So, to get around this, we plan two branches of JSR-299 TCK development after the spec is final:

• 1.0.x - bug fix only releases on the submitted TCKs. Implementors must pass the all these tests (likely about 800 covering 80% of the spec assertions) to be deemed compatile


• 1.1.x - bug fixes plus new tests. Implementors are strongly encouraged to pass this version of the TCK (we certainly will for Weld, and knowing the CanDI and OWB guys, I'm pretty sure they will be keen to do this too - after all, who wouldn't, as it ensures you have better implementation!). The aim for this TCK will be 99.9% coverage of assertions :-)