Why does a client need ClientJar file? Please help.

[Sujay Kamble]

As stated in HFE (Page 51), the client needs the Client Jar file (generated by the container) which contains the Remote and Home interafces and also the Home and Remote(i.e HomeObject and EJBObject) stubs!!!
1. But why does the client need the 2 stubs during compilation???
(HFE pg 57.....AdviceAppClient.jar for compliling client)
2. Aren't the 2 interfaces enough???
3. If the Home stub is already present in Client Jar , why to do a lookup for the HomeObject stub???
4. If the EJBObject stub is already present in Client Jar then why is it stated everywhere (HFE Pg 179, 193, etc) that the HomeObject on server returns the EJBObject stub???
I used to think that these 2 stubs are downloaded dynamically on the client machine at runtime and the only thing the client needs for compilation are the 2 interfaces.

[Anthony Watson]

1 & 2) The client needs the two stubs because the two interfaces by themselves do nothing. Interfaces serve no purpose without implementations (the stub classes).
3 & 4) The stub classes are just classes. They are not instances of classes. Classes are useless without instances. You do the lookup for the EJBHome and call its create method for the EJBObject so that you can get an instance. When you do the lookup for the EJBHome, you get back an Object. This will do nothing for you, so you must cast (and or narrow) it to your home interface type. The home interface obviously has no details in it about how to contact the server, so this is why you need the stub class that is in the client jar. Only when you perform your cast on the EJBHome do you have something the client can use, an instance of a class that not only implements your EJBHome interface, but also has the capacity to communicate with the server. 4) It is actually the EJBObject stub CLASS that is in the client jar. You still need to call create on the EJBHome to get an INSTANCE that can be converted to a stub INSTANCE.

[Sujay Kamble]

So, there is an EJB deployed on Weblogic server and there are 1000 clients who are using this EJB. Each one of this client will have a Client Jar file generated by Weblogic and each of this client was compiled with this Weblogic's Client Jar file.
Tommorrow if this same EJB is deployed in Websphere, a new Client Jar file generated by Websphere(which will have different stub classes files bcos the name of the stub classes itself can be different) will have to be sent to all these 1000 clients and all the clients need to be recompiled (since the stub class files are needed at compile time).
So every time the EJB container changes, all clients need to be recompiled with new Client jar file having new stub classes.
Oh no....I hate EJB bcos clients depend on the server. Write once Deploy anywhere and recompile all ur clients with new Stub class files.
But why can't the stub class files be downloaded dynamically at runtime as stated in Ed Roman EJB1.0 (not the new EdRoman for EJB2.0) in the chapter on Java RMI(section ownloadable implementations)? If that were the case the client would only require the 2 Interface class files for compilation and won't depend on any server.