...and why don't you see this as a "complete lack of control over you commercial serialization solution".
Because it's not out of control. I prefer to stop problems at the source. The serialization framework is doing it's job perfectly, and Hibernate is causing interference. We have determined that adding logic regarding what gets de/serialized into the serialization tier would also be duplicative, thus not the ideal design. Why? Because our DAO logic was already
written to initialize exactly
what data is necessary to respond to the client, and we want to centralize the business logic. We don't need another repository of configuration data/code to maintain. We need the ability to ask Hibernate to just trust that we knew what we were doing when the data was assembled.
(Why assume the programmer is lazy or incompetent, and needs constant babysitting?)
If you don't want lazy lazy initialization exceptons then fetch the data
We don't want the data fetched. This would be the equivalent of loading the entire database into memory.
hook into your commercial solution and tell it to ignore associations which return false for Hibernate.isInitialized()
This would work if there were places to hook in...
It is much better that you control what you want to do in your specific situation than to make the ORM more complex and inconsistent.
Yes, that's why we want more annotations for relationships - to specify what we want.
Hibernate already has fetch eager, fetch lazy, fetch no-proxy, and fetch extra lazy. Fetch extra lazy has the right idea, but has not gone far enough. Adding fetch "unless detached" is a natural progression of these options - which are mutually exclusive I might add.
Choosing among mutually exclusive options is not more complex from our standpoint. It does add code to the framework - where it belongs. The name of the game is rapid development. Reusable code. Modular components which fit together. Multiple tiers designed to do what they do best...
There are many others frustrated with this problem. Many just keep the session open. All this does it allow more unneeded data to load, and for performace and scalability to take a serious hit.
The fact that objects have relationships in the database is a concept to be capitalized on with object oriented software. However - sometimes you need the related data, sometimes you don't. Merely inspecting the object's relationship placeholder in another tier for the presence of data should not be prohibited. All I'm asking for is control over when to retrieve it. It's not an unreasonable request.
The serialization tier is prepared for a null relationship. It's ready for an empty Set. But iterator.hasNext() needs to retun false. These are reasonable ways to automatically detect the need to serialize a collection with no prior knowledge of the object. But Hibernate will not let it access the empty set without throwing an exception. Hibernate is just "getting in the way" in my opinion.
There is a very serious assumption made in the framework - that there is never a valid reason to access an uninitialized collection in any way.
I have no doubt you understand what it takes to lobby and cause an enhancement to happen in a commercial package. It's next to impossible.
Open source collaborative development is about becoming liberated from idealistic vendor-promoted concepts which in the field do not accommodate real-world problems, or rather create more of them. It's about making enhancements to our tools when other given limitations become brick-walls.
When our desired solution is within our reach, we will work towards it. We believe that Hibernate is overbearing with regards to it's strict mandate of forcing lazy initialization on objects which are out-of-session.