Which choice are you referring to ? Runtime Enhancing vs Compiling or
using AOP to solve the lazy loading problem ?

Regarding lazy loading, I prefer to handle it in a manner where the
developer knows it should reload/refresh an entity  in each app.
transaction. Dont know about your solution, so I cant comment.

Regarding bytecode enhancing vs. post-compiling, both have drawbacks.
With bytecode enhancing you'll have problems with generated classes
if you use instanceof alot, classloading problems, and sometimes buggy
implementations in libraries. With postcompilation, debugging wont be
easy because of the extra code inserted between your code. OTOH,
performance is better with compiletime weaving. Read Adrians comment
on this : dev.eclipse.org/.../msg07094.html

Unfortunately Sun hasn't provided a good  solution to intercept method
calls in java. Maybe someday we all have a unique solution  for this
problem !

Thanks for your direct  answer, that was almost what I was looking for, is there any more official documents or links that I can refer to, if so, I'd be grateful you or other people in this group help me to find it.

Based on what you explained, I assume you have a fat client  project and you are trying to use lazy loading on the client side. There are some ORMs that have this feature. And I remember that Mr. Gavin King once addressed this issue on a thread in hibernate forum and insisted that this is not a good  design and he will never consider this to be implemented in Hibernate. I am sure you can find the discussion in Hibernate forum.

But apart from what he said, I believe that this is not a good design. Why?

Because You can justify your fetching  strategy and take away all of these complications.
Of course you can use JDK dynamic proxy, javassist or cglib to do this .Technically you are on the right track and there is no doubt about it. You can use an introduction advice using any AOP framework to do this but this is beyond the scope of a project that needs lazyloading on its client side. This is what must be done inside a framework.
And it cannot be used widely because in order to use it, a developer that just wants to load an object from database must be familiar with Aspect Oriented Patterns and restrictions, JDBC, Object Relational Mapping techniques along with Caching and this is beyond the abilities of a normal developer to be used extensively. And a framework is to facilitate problems along with hiding the complexities. This is complexity itself.
My answer is no. Never go there. Learn how to improve your fetching strategy instead...

Based on what I explained I had been talking about a 3-tier  EJB application, not a part of client/server application  that refers to the persist layer or an ORM. Could you please tell me how to learn to fetch  a detail in a lazy way in client  side of a 3-tier application which there is no effect of an ORM like hibernate in it.

It seems to me like you have the "Session In View" problem which is not just relevant to Hibernate. It happens where people use lazyloading. If my assumption is correct, you get the lazyLoadingException when you load the detail. Is my assumption correct?

You could use something like hibernate if lazy loading is all you need. In this special case you could also look into extra lazy loading options for collections.

I don't know what is your target goal, there are a lot of critical items can make a solution good  or bad.
Is this a theoretical question or not ? If it is not do u make a framework or something else ? did u consider performance aspects of desired technologies or not ? r u sure about loading a collection (maybe a large collection) just to get size  of it ? don't u need to use something like extra-lazy in hibernate ( if you use hibernate as an ORM) !!!!

however i can just say you should apply proxy pattern ( even you use AOP techniques, you are applying proxy pattern indirectly)
and maybe this link can be helpful for you (to make your mind better ): http://www.hibernate.org/377.html (Remote Lazy Loading)

I forgot to introduce H3T project ( http://h3t.sourceforge.net/ )

"H3T will intercept your attempts to access uninitialized lazy elements and load them from the server for you. This will happen as seamlessly as if it were being done by Hibernate on the server."

I became so confused ; if your app did not related with greater than about 10 or some more or less , why U choosed so complicated patterns ?! my main idea is not about minus or plus ur entities count ,but it is about change ur design pattern .

With respect to other friends and their answers , I think u choose hardest way to solve this problem in the world in all time . changing bytecode after it generate , cause so many future problem if U don't work on tiny app . I'm not very professional in this way but , by this reason I always took simplest way . I realize this problem in MVC design pattern , if U drop UR entities in Model project , not only is not a problem but also is a regular way to create DBMS apps . so I don't know which IDE u use to ceate this app , but i can suggest to U if U
use Oracle DB or any DB with JDBC:ODBC Bridge connection , try oracle JDeveloper .
It's very fast,Helpful and reliable spc with MVC and EJB3 .

if it's not helpful sorry to waste your time . I just wanna help you

If you dont have an answer, dont answer ! Whats it with you all
coming up saying instead use this , use that, ignoring the first
question and adding to the frustration !

You can google "Post-compile weaving Vs Load-time weaving" and find a
lot of content on this subject.

I guess you are speakin about the problem usually arise when you want to keep your objects attached in your persistence layer,
when you are moving your object from middle tier to web tier, when the object moves from your persistence layer, the lazy loding don't work any more, is this your problem?

I strongly recommend anyone facing such problems to redesign their api and confirm it to SDO (Service Data Objects) semantics. Just follow the model SDO lays on the ground for designing such remote services which return DTO objects. H3T or any such mechanism is imho a workaround, a bad idea and will result in hard to maintain code and chatty aplications and hence bad performance.

As i told before , it is so important why someone choose this idea for retrieving object graph by the lazy association in the client-tier? Is it for researching or learning goals or not ? or just to create a phone book project and not more ?

We should be careful about its side-effects if we can't manage it well :
More round-trips [network and database] ( massive n+1 requests problems )
More marshaling and serialization latency
Data aliasing problems in the client-side
Loss of referential integrity in the client-side object graph
OutOfMemoryException
Less control
More restrictions
It can be an ideal conceptual solution  but it's not practical in action.



For some application  ranges (mission-critical OLTP systems) and scales it is not practical which you apply a transparent generic data loading/persisting proxy pattern for the lazy-associations of all entities, at least you need pagination as a first-class need and sometimes filtered collections (e.g snapshot of historical data) or detached on-the-fly objects without database transparent update and it seems these activities are more context-oriented.

I have just applied this pattern in the logic-layer (not the client-tier) which encapsulated into a service as a default transparent mechanism to decrease line of code and automated management to use the second level entity  cache, but it couldn't satisfied me because our services depends on data access helper technology  aspects (hibernate transparent tasks), however it has some important benefits for us and this a possible trade-off.

I believe, the transparent entity loading/persisting proxy pattern can be helpful for some cases and it can be poison for other cases or it is better to say whenever you use an ORM framework and Pojo model you should be careful, if you can't handle it well consequently you will loose the performance.

In the last project which we have developed ( integrated core banking services based on ERP concepts with more than 200 business entities and 300 tables ) i have reviewed all of mappings more than 5 times depends on usage to ensure everything is in the best way to get a better TPS.

Finally, i prefer to use passive business entities ( DTO ) in the client  side and i recommend you follow this way as a best practice if you want to control risks and you are not interested to fail your real project.

I am not still sure if the original poster problem was only lazy loading, but if it was:
it is nice point
database access is very slow, minimizing it has great effect on performance
so optimizing queries and relations to make sure lazy loading will not happen is best way,
but if in case some one needs lazy loading, seam framework offers a very sophisticated handling of lazy loading with hibernate or other JPA implementations.