Static methods on EJBs ?

[exquisitus]

I'm writing an engineering library in a Java package. The package is
very simple. There is no constructor (since I do not need to do any
global initialisations etc at startup). All the methods in the
functionsa re declared as static public (defining the API of the library).

It is possible that I will write an JB wrapper around this library to
creat an EJB bean - in the near future. I am wondering if declaring my
methods as static may cause problems when it comes to turning the
library into an EJB - in particular, I am worried about re-entrancy
problems (the library is currently NOT thread safe). Is this a warranted
worry - or am I worried about nothing?.

A technical explanation or link to a technical explanation (even a brief
one) to accompany your response will be very much appreciated.


MTIA

 

[Tilman Bohn]

[The aspects of the OP I'll address aren't EJB-specific, so I'm setting
F'up2 cljp.]

I'm writing an engineering library in a Java package. The package is
very simple. There is no constructor

Yes, there is. Even if you didn't write one.

(since I do not need to do any
global initialisations etc at startup). All the methods in the
functionsa re declared as static public (defining the API of the library).

Unless you keep no state in your class, this static approach is almost
certainly inappropriate.

It is possible that I will write an JB wrapper around this library to
creat an EJB bean - in the near future. I am wondering if declaring my
methods as static may cause problems when it comes to turning the
library into an EJB - in particular, I am worried about re-entrancy
problems (the library is currently NOT thread safe). Is this a warranted
worry - or am I worried about nothing?.

If you say your class isn't thread-safe, that would seem to indicate
you do keep some state. In that case, yes, you should worry. If you
don't keep state, there is obviously no state to corrupt, and therefore
no need to worry.

Writing stateful classes in a purely static way is in many ways
analogous to global variables, and is generally just as wrong, IMO. Why
don't you want to have separate instances of your class? Let me widen
the scope of that question a bit: Having read some of your other posts,
I cannot help but wonder why you are so determined at circumventing
object-orientation in an object-oriented language. Can you explain your
motives in this regard a little bit?

 

[exquisitus]

[The aspects of the OP I'll address aren't EJB-specific, so I'm setting
F'up2 cljp.]

In message <[email protected]>,
exquisitus wrote on Sun, 27 Feb 2005 15:20:33 +0000 (UTC):

I'm writing an engineering library in a Java package. The package is
very simple. There is no constructor

Yes, there is. Even if you didn't write one.

(since I do not need to do any
global initialisations etc at startup). All the methods in the
functionsa re declared as static public (defining the API of the library).

Unless you keep no state in your class, this static approach is almost
certainly inappropriate.

It is possible that I will write an JB wrapper around this library to
creat an EJB bean - in the near future. I am wondering if declaring my
methods as static may cause problems when it comes to turning the
library into an EJB - in particular, I am worried about re-entrancy
problems (the library is currently NOT thread safe). Is this a warranted
worry - or am I worried about nothing?.

If you say your class isn't thread-safe, that would seem to indicate
you do keep some state. In that case, yes, you should worry. If you
don't keep state, there is obviously no state to corrupt, and therefore
no need to worry.

Writing stateful classes in a purely static way is in many ways
analogous to global variables, and is generally just as wrong, IMO. Why
don't you want to have separate instances of your class? Let me widen
the scope of that question a bit: Having read some of your other posts,
I cannot help but wonder why you are so determined at circumventing
object-orientation in an object-oriented language. Can you explain your
motives in this regard a little bit?

Hi Tilman,

Jeez, you Java guys are a bit *touchy* - aren't you?. I can't help the
fact that I am from a C/C++ background and I have only recently started
taking a serious look at Java (I have ignored Java in the past - because
it was simply too slow for the number crunching stuff that I normally
work on). I am trying hard to understand why things that are so
straightforward in C/C++ are either absent or (appear to be)
'workarounds' - case in point, enumerations, template classes, variable
length arguments and pointers (even safe pointers) - but ofcourse I
can't mention the 'p' word here can I ?

Seriously, Java has some good things (a lot of good things) going for it
and thats why I want to get up to speed with it and write some code. I
believe the best way to learn a language is diving in and getting your
hands dirty with some actual code - and that means, sometimes asking
"silly" questions. If I ask a question, its because I have struggled
with it for sometime, done a google search, not come with anything
useful and I genuinely would like to know what the problem is - it is
not to start a flame war of "my language is better than yours" or any of
that crap.

You mention that I am trying to write in a non-OO way. Well I dont see
it that way. What was the point of pointing out that I *have* a
constructor (everyone knows there is a default constructor when you
don't provide one). There was no need to waffle and state the obvious.
What I am doing is quite simple (at least it should be). I ahave a C++
library that I am converting into Java, and would like to convert the
library into an EJB at a later stage. I feel that this exercise will
teach me pretty much most of what *I* need to know about Java - at least
for the time being.

The question I am asking here is quite straightforward. I have a simple
library - I have implemented this as a singleton pattern so that there
is only one instance of this 'number crunching engine'. All methods in
the exposed API are static. Since I haven't read the entire tomme about
EJBs I just wanted to know if I needed to do anything special to the
library before wrapping it up as an EJB. It is just a collection of
engineering functions - no state is being saved. All I am asking is that
do I need to do anything to the code before turning it into an EJB - I
would have thought that was a fairly straightforward unprovocative
question to ask.

 

[Tilman Bohn]

In message <[email protected]>,
exquisitus wrote on Mon, 28 Feb 2005 01:15:40 +0000 (UTC):

[...]

Hi Tilman,

Jeez, you Java guys are a bit *touchy* - aren't you?.

Not really.

I can't help the
fact that I am from a C/C++ background and I have only recently started
taking a serious look at Java (I have ignored Java in the past - because
it was simply too slow for the number crunching stuff that I normally
work on).

Depending on the exact objective, it might still be, or it might not.
What I can almost guarantee you, however, is that you will not get
optimal performance by hand-tuning all manner of little details from the
get-go, especially when your tuning is based on intuitions about
prospective performance impacts that are informed by your experience
with C and C++. Java is a different language and platform.

[Some trollage snipped]

Seriously, Java has some good things (a lot of good things) going for it
and thats why I want to get up to speed with it and write some code. I
believe the best way to learn a language is diving in and getting your
hands dirty with some actual code

No doubt.

- and that means, sometimes asking "silly" questions.

There is absolutely no problem with that. The problem is when the
question is asked in a way that already implies your dissatisfaction
with the answer, unless the answer happens to be `same as in C++'.

If I ask a question, its because I have struggled
with it for sometime, done a google search, not come with anything
useful and I genuinely would like to know what the problem is - it is
not to start a flame war of "my language is better than yours" or any of
that crap.

Then you should try to avoid formulations which imply that you think
only the C++ way is the right solution.

You mention that I am trying to write in a non-OO way. Well I dont see
it that way.

If avoiding objects isn't non-OO, what is?

What was the point of pointing out that I *have* a
constructor (everyone knows there is a default constructor when you
don't provide one).

This is not true. Not `everyone' knows this, for any reasonable
definition of `everyone' in this context. Many beginners who come here
aren't aware of that. Please realize that the only way others can judge
your background and your level of competency is from what you write.
Since you appeared to be a beginner in Java (as you have since stated
yourself), it is not completely beyond reason to point out this factual
error to you. If you feel offended by that, it would seem it is you who
is being a tad touchy.

There was no need to waffle and state the obvious.

There is no need to denounce sincere efforts to help.

What I am doing is quite simple (at least it should be). I ahave a C++
library that I am converting into Java, and would like to convert the
library into an EJB at a later stage. I feel that this exercise will
teach me pretty much most of what *I* need to know about Java - at least
for the time being.
Possible.

The question I am asking here is quite straightforward. I have a simple
library - I have implemented this as a singleton pattern so that there
is only one instance of this 'number crunching engine'. All methods in
the exposed API are static.

Maybe you'll complain about me stating the obvious again, but the
latter is something almost, but not quite, completely unlike a
singleton.

Since I haven't read the entire tomme about
EJBs I just wanted to know if I needed to do anything special to the
library before wrapping it up as an EJB. It is just a collection of
engineering functions - no state is being saved.

If you don't carry state, there shouldn't be a problem in that
respect. As to having to do anything special, the worst that can happen
is that you have to wrap the thing in an EJB instead of turning it into
one proper.

All I am asking is that
do I need to do anything to the code before turning it into an EJB - I
would have thought that was a fairly straightforward unprovocative
question to ask.

And I thought I gave you a fairly straightforward and unprovocative
answer. I also took the liberty of commenting on some other issues along
the way because I tried to be helpful.

 

[Oscar kind]

The question I am asking here is quite straightforward. I have a simple
library - I have implemented this as a singleton pattern so that there
is only one instance of this 'number crunching engine'. All methods in
the exposed API are static. Since I haven't read the entire tomme about
EJBs I just wanted to know if I needed to do anything special to the
library before wrapping it up as an EJB. It is just a collection of
engineering functions - no state is being saved. All I am asking is that
do I need to do anything to the code before turning it into an EJB - I
would have thought that was a fairly straightforward unprovocative
question to ask.

This is not correct: a singleton pattern has _one_ instance (when used).
A class with only static methods has _none_; at least none to call the
methods on, as the methods are called on the class.

And that is where conversion to EJB's or better yet, a session bean, goes
wrong: such beans always instantiate an object; either local or remote
through stubs.

So step one is to correctly implement the singleton pattern (i.e. remove
the "static" keyword from all methods but "getInstance").

Step two is to make the library so that it doesn't depend on being a
singleton. If your library holds no state, this is trivial.

Step three is to get a skeleton for a session bean (probably a stateless
one), and put the methods of your library in there.

 

[exquisitus]

This is not correct: a singleton pattern has _one_ instance (when used).
A class with only static methods has _none_; at least none to call the
methods on, as the methods are called on the class.

And that is where conversion to EJB's or better yet, a session bean, goes
wrong: such beans always instantiate an object; either local or remote
through stubs.

So step one is to correctly implement the singleton pattern (i.e. remove
the "static" keyword from all methods but "getInstance").

Step two is to make the library so that it doesn't depend on being a
singleton. If your library holds no state, this is trivial.

Step three is to get a skeleton for a session bean (probably a stateless
one), and put the methods of your library in there.

Hi Oscar,

Thanks for your detailed response. I understand the concept of a
singleton patern restricting the number of instances to one. However, I
do not understand your statement : "A class with only static methods has
_none_; at least none to call the methods on, as the methods are called
on the class.". I would be grateful if you could elaborate further.

This is how I understand the three steps you outlined above:

1). Implement the singleton pattern - remove 'static' access modifier
from all methods except "getInstance (This I understand).

2). Implement he library so that it dosen't depend on being a singleton
- I'm not storing any state information in the functions, but I 'm not
sure if this is what you mean - please elaborate further.

3). Here, I must admit, I am out of my league. Some code will be very
much appreciated.


I will use a very simple code exmple to see if I am understanding you
correctly. Assuming I have a simple class with two functions (I want to
turn into a library/package) as ff:

package com.myhome.statsfuncs

Class FooEngine {
public int add(int x, int y) { return (x+y)} ;
public int sub(int x, int y) { return (x-y)} ;
}


Step 1 will require me to change the code as ff:

package com.myhome.statsfuncs

public class FooEngine {
public final static FooEngine INSTANCE = new Singleton();
private FooEngine() {
// Prevents instantiation.
}
public int add(int x, int y) { return (x+y)} ;
public int sub(int x, int y) { return (x-y)} ;
}

Step2: Not sure what to here
Step3: Clueless - some code will be very much appreciated


Although my Singleton pattern although fast and thread safe, I am not
sure if a seperate instance will be created on every distinct VM on
which the code is running (say servlets using an EJB wrapper around the
FooEngine object). Any hep or further elucidation will be much appreciated.

MTIA

 

[Oscar kind]

Oscar kind wrote:

Thanks for your detailed response. I understand the concept of a
singleton patern restricting the number of instances to one. However, I
do not understand your statement : "A class with only static methods has
_none_; at least none to call the methods on, as the methods are called
on the class.". I would be grateful if you could elaborate further.

If you call a static method, it's just some code inside a namespace. There
is no object instance the code belongs to. That's why the keyword "this"
cannot be used in a static context. This contrary to a non-static method,
where the "this" keyword can be used.

This is how I understand the three steps you outlined above:

1). Implement the singleton pattern - remove 'static' access modifier
from all methods except "getInstance (This I understand).
Yes.


2). Implement he library so that it dosen't depend on being a singleton
- I'm not storing any state information in the functions, but I 'm not
sure if this is what you mean - please elaborate further.

Not having state just makes it easier. The only thing really needed is
that a universal state is not required. Without any state being kept, this
is already finished.

3). Here, I must admit, I am out of my league. Some code will be very
much appreciated.

And I cannot be much help: I've no experience setting this up. I'd look
for a tutorial; assuming it's about as difficult as setting up EJB's, it's
easy enough with an example to copy.


[...]

Although my Singleton pattern although fast and thread safe, I am not
sure if a seperate instance will be created on every distinct VM on
which the code is running (say servlets using an EJB wrapper around the
FooEngine object). Any hep or further elucidation will be much appreciated.

A separate instance implementing the remote interface will be instantiated
for every VM (and possibly more than once if multiple classloaders are
used). A stateless session bean is instantiated only once I believe, but
AFAIK there is no guarantee of that. This is the reason behind step two:
you cannot enforce a singleton, unless maybe (!) if you use the facade
pattern for the session bean.