HF EJB Book - Session Bean Class Constructor Clarification required

[Peter Vennel]

As per EJB specs 7.10.2 page 95,
"The class must have a public constructor that takes no parameters. The Container uses this constructor to create instances of the session bean class."
But the example in HFEJB pg 183, 'AdviceBean' I did not see any such constructor. Is this a printing error or am I missing something??
Thanks.
Peter
[ January 02, 2004: Message edited by: Peter Vennel ]

[Mikalai Zaikin]

I don't have HF EJB book in front of me right now, but this question relates to Java syntax, and this is not EJB trick.
<offtopic>
Java compiler provides [SURPRISE !!!] default no args constructor for class without any constructor.
This is required for constructing java objects, because when you call somebody's constructor, it invokes constructors of all java class parents. And in case a programmer forgot define any constructor at all, this could be a big pain. That's why compiler inserts default constructor. To protect programmer from boring inserting of empty constructors:
public SomeClass {
...
SomeClass() { // this will add compiler by default
super();
}
}
cheers !
</offtopic>

[Peter Vennel]

Thanks Mikalai.
What you said is right. But as a bean provider are you not supposed to write that constructor in your code (as per the specs) and not depend on the system creating default no args constructor.

[Mikalai Zaikin]

I think, it does not matter whether default constructor is provided by java compiler, or bean provider. It almost always will be provided by compiler, becuse you can not do much during constructing bean object (see bean's life cycle).
cheers !

[Roger Chung-Wee]

But as a bean provider are you not supposed to write that constructor in your code (as per the specs) and not depend on the system creating default no args constructor.

I disagree. I think that the programmer should always explicitly declare the no-arg constructor. At least, it probably indicates that a moment's thought went into doing this ...

[Nick Bauman]

From my old C++ days, you should always write a no-arg constructor of your own because the compiler-provided constructor may provide "special" behavior that you are unintentially relying on which might go away when you do one day write your own constructor.
Not sure this means the same thing in Java, since I don't write Java compilers, but it seems on-target because the black-box of a container is relying on something you've nailed down at compile-time.

[Kathy Sierra]

Howdy -- we *recommend* that you allow the default constructor, to help guarantee that you put NO behavior in the constructor. But, there are many reasons why you might in fact *write* the constructor into your bean class:
1) Your development tool/IDE insists on putting one in for you
2) Your personal preference/style is to explicitly create the no-arg constructor.
3) Your company style guide demands that you always explicitly create a constructor.
There is absolutely NO technical difference between creating an explicit no-arg (no code) constructor and allowing the default constructor to be put in to your bean class.
We recommend that programmers do not put in a constructor, because they are so often tempted to put initialization code into the constructor which is virtually *never* the place that code needs to be. You should always put your bean's initialization code in either the setSessionContext (or setEntityContext) method, or in the appropriate ejbCreate or ejbPostCreate method, depending on what you're trying to achieve.
Remember, during a constructor, the object does not yet have its "beanness", so a lot of things won't work and aren't available. Sure, you could set *some* of your instance variables, but those can be set later. So we think of the constructor as just "the thing the container uses to insantiate your bean as an OBJECT", but that you don't care about its objectness--you care about its beanness, and for THAT, you have to wait until the object is given access to its bean capabilities (like being able to get a reference to its own EJBObject reference, or call a method on something it got from JNDI, etc.).
cheers,
Kathy

[Peter Vennel]

Thanks all, especially Kathy for the detailed insight.
I just wanted to make sure that if a bean class is presented in the exhibit without no args constructor (considering there are no other constructor), we can safetly treat that a valid piece of code, given that there are no other error in the code. Sometimes, we may not know what SUN expects you to answer.