Before such discussions tend to go nowhere, getting the basics right will help everyone understand your colleague�s point of view.
What you are suggesting is that while migrating Entity Beans (EJB 2.x) to JPA Entities (EJB 3.x), you will create helper classes to ape Entity Bean�s Home interface which you think will leave you & the application with incredible performance gains as against following the best practice of encapsulating Entity Home interface functionality within Stateless Session Beans (SLSB).
To that, I can only say - let me be the last one to remind you that Session Beans in EJB 3.0 are light-weight POJOs. As light as POJOs but only smarter! Hence I don�t buy your argument that usage of SLSB 3.x will make your application �heavy�.
To quantify my argument, have a look at this myth-shattering performance benchmark comparison between EJB 3x. Vs POJO(non EJB):-
http://www.adam-bien.com/roller/abien/entry/is_it_worth_using_pojos By the way if performance is the only criteria, I am still wondering why do you want to create one helper class each for every Entity Bean Home Interface when you could easily avoid this memory baggage by having your application code rewritten to work directly with the entity manager API?
But ofcourse, now the trade-offs between loose-coupling Vs performance will strike you!
Additionally on the issue of memory overhead, you need to be reminded that App Servers are smart in maintaining a pool & don�t create one separate SLSB instance for every client but in the case of helper class you are on your own to guzzle.
Not that you should care less, but I feel focusing on how to save little memory footprint is certainly not of any interest to the clients who have already spent huge sums for license of App Server & related infra coz after all we are talking about memory which costs hardly $20 for 1GB on amazon.com
Coming back to core issue, I hope your colleague must have mentioned about this free tool to automate the conversion of Entity Beans 2.x to JPA Entities thereby saving substantial efforts & cost so that you can enjoy a vacation to Hawaii or Chennai (as the case maybe). Have a look:-
http://www.oracle.com/technology/pub/articles/vohra_ejb.html Finally, some goodies of putting up SLSB as Entity Home Interface is that it can be looked up from JNDI just as the entity home was previously and can use a similar interface in order to minimize application code changes. Also, @PersistenceContext injection doesn�t work in dumb helper classes besides having no support for declarative transactions, security & other container services available to EJBs. Even from Testability point of view, with SLSBs doubling up as Home for JPA entities, you will be able to break entity service completely away from the application code and unit test it (including distributed & clustered env). It will also be possible to inject stubs or mocks at appropriate places and do limited integration testing.
Chill !
[ June 08, 2008: Message edited by: Prashant Tejura ]