EJB and static methods

Discussions

EJB design: EJB and static methods

  1. EJB and static methods (12 messages)

    I realize this is probably bad design anyway, but is it possible to declare a static method in an EJB class?
    I am thinking the answer is no, but have not found concrete confirmation to this theory yet.

    Threaded Messages (12)

  2. EJB and static methods[ Go to top ]

    In theory, static methods are valid. You can do this safely provided that your static method does manipulate non-final static fields (which are forbidden by the spec).

    In practice, it is poor design. You are just going to confuse people.
  3. Theoretical question[ Go to top ]

    Thanks Paul,

    My question (academic as it might be) leads me to wonder, which concrete class would be used when such a static method is invoked on an EJB? The actual bean class or the proxy class generated by the app server to represnt the bean?
  4. Theoretical question[ Go to top ]

    I see no theoretical or practical reson why EJB classes should not contain static methods. In fact, if you have a method that doesn't need to operate in the context of a specific instance and you don't think you would ever have to override it, I consider it good desing to make it static. For instance, if you have a method "sqare" that returns the square of an integer, I think it is advisable to make it static. This avoids creating unnecessary dependencies between the method and the instance data, and can also help performance.

    Static method calls are resolved at compile time. Even if the proxy class declared a method with the same name, your code would still use your static method. The runtime type of a reference (including the "this" reference) does not affect calls to static methods. This is how things work in Java in general, and EJB is no exception. Static methods cannot be overriden, only hidden.

    Gal
  5. Theoretical question[ Go to top ]

    I believe you can have a static implementation in a EJB and this is not a bad practise too, after all EJB is also a java class.But invoking thread on these static methods are bad practise.I have used static methods in EJB and it works fine...
  6. Theoretical question[ Go to top ]

    Which class will be used to invoke the method does not really matter much, and depends on how the method is invoked. Whether you used EJBclass.method() or Stub.method(), the same static method will be called.

    Note that the server itself won't be able to invoke your static method, since the static method can't appear in any of your interfaces (remote or local). Also, your code won't have access to the server specific stub. So odds are very good that the way your method will be invoked is EJBclass.method().

    Why this is bad design: Several other people posted here saying they see no good reason why you can't put static methods on your EJB class, so I thought I should clarify my reasons why you should not do this.

    1) There is no benefit to putting a static method on your EJBclass. The static method cannot access any EJB instance variables, context, or EJB-related operations, so putting it on your EJBclass gains you nothing.

    2) If you want to have static helper methods, you can just as easily put them into another class, say StaticUtilities, which you bundle in your EJB jar. This is a much better alternative.

    3) Static methods in the EJB class itself run counter to the usual practice for EJB development, and will confuse other developers when they look at your code.

    So, if you want to avoid other developers scratching their heads saying "What the heck are these static methods doing in this EJB class and what are they suppose to be doing?", you should put your static utility methods in a helper class instead.
  7. Theoretical question[ Go to top ]

    Which class will be used to invoke the method does not really matter much, and depends on how the method is invoked. Whether you used EJBclass.method() or Stub.method(), the same static method will be called.


    This is incorrect. If the method is hidden by the Stub class then a call to Stubn.method() will not call the same static method as a call to EJBclass.method().
    However, like I mentioned above, A call to this.method() in EJBclass will always resolve to a call to EJBclass.method, regardless of whether or not "this" represents an instance of EJBclass or Stub at runtime. Static method calls are not resolved at runtime.

    >
    > Note that the server itself won't be able to invoke your static method, since the static method can't appear in any of your interfaces (remote or local). Also, your code won't have access to the server specific stub. So odds are very good that the way your method will be invoked is EJBclass.method().

    There is no meaning to the term "the way your method will be invoked". Static methods (and methods in general) are not replicated in each subclass. If a method is declared in EJBclass and not in Stub, then there is no "way" to invoke it "as" Stub.method (you can write Stub.method, but it resolves to EJBclass.method at compile time). Even if a method by the same name is declared in stub it won't matter, as I explained above.

    >
    > Why this is bad design: Several other people posted here saying they see no good reason why you can't put static methods on your EJB class, so I thought I should clarify my reasons why you should not do this.
    >
    > 1) There is no benefit to putting a static method on your EJBclass. The static method cannot access any EJB instance variables, context, or EJB-related operations, so putting it on your EJBclass gains you nothing.

    You can't access instance variables. Thats the point of static methods. You make a method static when it's behavior does not depend on a specific instance.
    It is not true that such methods can't access the EJB context or perform EJB-related operations. The transaction and security context of the caller is automatically used by the static method, and it can perform operations using these contexts just like any other method. It can't access context which is specific to one bean instance: again, that's the point of making it static.

    >
    > 2) If you want to have static helper methods, you can just as easily put them into another class, say StaticUtilities, which you bundle in your EJB jar. This is a much better alternative.

    Of course you can. Again, the same applies to every Java class. And yet people do use static methods in Java classes. Does it mean every Java class with static methods (except ones named StaticUtilities) are badly designed? Is there a particular reason why moving the method to a utility class is always better?
    Static methods are often implementation specific. In such cases they are made private or atleast non-public. Moving those to a utility class is not a good alternative. Even if the methods are public, when they are specific to one class it is good design to put them in that class.

    >
    > 3) Static methods in the EJB class itself run counter to the usual practice for EJB development, and will confuse other developers when they look at your code.

    This is just chasing your own tail. You are not giving any objective reason, just the fact that "they are bad because people don't use them, and people don't use them because they are bad". I don't think static methods in EJB are confusing when they are used for what they are supposed to be used for: methods that inherently do not require access to the instance state. In such cases I think they even make the code clearer, by explicitly telling the reader of the code which methods operate independently of the bean instance.
    Of course some methods don't fit this model: for instance one common pitfall is making a static method that requires access to configuration data. This data is accessed through EJBContext and is generally instance-specific (the bean can be deployed multiple time with different configurations). Static methods should really implement functionality that does not depend on the context of any specific instance.

    >
    > So, if you want to avoid other developers scratching their heads saying "What the heck are these static methods doing in this EJB class and what are they suppose to be doing?", you should put your static utility methods in a helper class instead.

    I have never found myself scratching my head when I saw a static method in an EJB. I can't talk about other people, but to me it seems perfectly natural.

    Gal
  8. response[ Go to top ]

    I am agree with Gal. I can't see any problems using static methods in EJBs in case if they are purely idempotent.

    Alex
  9. Theoretical question[ Go to top ]

    First off, what is "good design" is not always written in stone, and opinions may differ. So if you disagree with me, I have no problems with that. :)

    As I see it, in the discussion at hand, there are three options for where you can put your logic.

    1) In an instance method of the EJB class.
    2) In a static method of the EJB class.
    3) In a static method of a different utility class.

    Logic specific to a particular EJB: Logic specific to a particular EJB should probably be put into an instance method, even if that logic does not (at the moment) use instance variables. There is no advantage that I see to putting EJB-specific logic in a static method. It certainly won't improve performance.

    Logic not specific to a particular EJB: Logic that is not specific to a particular EJB should not be in that class. It should be in a different class, such as a utility class. That method in the other class could be either a static or instance method, as appropriate.

    Following common conventions: As a rule, I always try to follow the common conventions when developing code, provided that there is no disadvantage to that convention. For example, when I write C# code, I capitilize method names, even though as a Java developer it makes my skin crawl. I used to use hungarion notation when I wrote VB code, even though I thought it was stupid. I did these things because (a) those were the conventions in the language I was working with and (b) other than style, there was no reason not to follow the convention.

    I believe that using static methods in the EJB class runs counter to the common style conventions of EJB. I have not seen any examples in EJB tutorials or books that make use of static methods in the EJB class itself. Since I can't see any advantage to violating the convention, I would recommend following it.
  10. Theoretical question[ Go to top ]

    First off, what is "good design" is not always written in stone, and opinions may differ. So if you disagree with me, I have no problems with that. :)


    Well said :)

    >
    > As I see it, in the discussion at hand, there are three options for where you can put your logic.
    >
    > 1) In an instance method of the EJB class.
    > 2) In a static method of the EJB class.
    > 3) In a static method of a different utility class.
    >
    > Logic specific to a particular EJB: Logic specific to a particular EJB should probably be put into an instance method, even if that logic does not (at the moment) use instance variables. There is no advantage that I see to putting EJB-specific logic in a static method. It certainly won't improve performance.

    I disagree. Take for instance an EJB that does some numerical work. It is very common to require some utilities such as "average(float[] vals)", or even highly specific values such as "f(float x, float y, int degree)" where f is a value defined in a numerical recipe book in the cubic spline section. Moving f to a general utility class is very messy (unless you have a special utility class for cubic splines, which is ok, but often an overkill). Other numerical resipes define "f" with other meanings. If your bean class handles cubic splines, I definately think it's better to put f in your class than in a general utility class.
    As for whether or not f should be static, it is, as allways, a matter of taste. I prefer static methods in such cases for three reasons:
    1. Documentation: declaring f static documents the fact that it is a generic piece of code that does not depend on instance values.
    2. Performance: declaring a method static does help with inlining. In numerical work this is crucial. HotSpot VMs can inline instance methods but not as effectively, in my expirience.
    3. Flexibility of use: declaring f as static allows you to use it in static contexts, or in contexts where you don't have an instance of the bean. For example if you decide you want to pre-load a table of frequently used f values at startup, you can do it from a static context.

    I don't accept the "it may not depend on an instance now, but it might depend on it later" argument. The exact same argument could be used to explain why each instance of some class X must keep a reference to some instance of any class Y, "because even if X doesn't depend on Y now, it might depend on it later". It is the job of a software engineer to analyze, understand and then minimize the dependencies between pieces of code. If a certain function, by it's definition and according to your analysis, is inherently independent of an instance, then it is reasonable to make it static.

    None of these reasons are extremely important. If you wouldn't use a static method in a regular class, don't use it in an EJB either. But if you would use a static method in a regular class, I claim there is nothing wrong with using it in EJB as well.

    >
    > Logic not specific to a particular EJB: Logic that is not specific to a particular EJB should not be in that class. It should be in a different class, such as a utility class. That method in the other class could be either a static or instance method, as appropriate.

    I agree, but this has nothing to do with EJB. Replace "EJB" with "Java class" and it is still correct. See my previous paragraph.

    >
    > Following common conventions: As a rule, I always try to follow the common conventions when developing code, provided that there is no disadvantage to that convention. For example, when I write C# code, I capitilize method names, even though as a Java developer it makes my skin crawl. I used to use hungarion notation when I wrote VB code, even though I thought it was stupid. I did these things because (a) those were the conventions in the language I was working with and (b) other than style, there was no reason not to follow the convention.
    >
    > I believe that using static methods in the EJB class runs counter to the common style conventions of EJB. I have not seen any examples in EJB tutorials or books that make use of static methods in the EJB class itself. Since I can't see any advantage to violating the convention, I would recommend following it.

    I don't see using static methods in EJB as running counter to common conventions. I don't think EJB coding coventions has anything to do with language features such as static methods.
    I have never seen an EJB tutorial or book make use of the java.util.Stack class, strictfp modifier, or even anonymous inner classes, as far as I can remember. Does that make them "unconventional"? I think people are reading too much into the EJB spec, mainly because many novices are taught that there are a lot of restrictions and they are not sure exactly what is allowed and what isn't. The original poster of this thread thought that static methods are not even allowed in EJB regardless of conventions.
    The EJB spec only limits very specific areas of the language, and for very specific and clear reasons. The EJB spec is not a seperate language. It does not merit it's own set of stylistic conventions, apart from those relating to EJB-specific artifacts. Inner classes, strictfp, and static methods can and should be used in EJB in exactly the same manner as in every Java environment.

    Happy Hannukah/Xmas...
    Gal
  11. Theoretical question[ Go to top ]

    OK, I think we are going to have to "agree to disagree" on this one. :)

    In my opinion, static methods in EJBs run counter to the common EJB coding style, but since there is no "EJB Style Guide", this is definitely just my opinion.

    I have to admit that the work I do rarely involves complex mathematical functions, and JIT inlining is a good argument that I had not thought of.

    I actually spend a lot of time teaching raw newbies how to use J2EE, and as a result I tend to have a lot of "rules" that are aimed at steering beginners away from pitfalls.

    For example, I tell J2EE beginners to "never put an instance variable in a servlet". Of course, the real answer is "you can use an instance variable as long as you properly synchronize access to it", but that answer requires a degree of sophistication that most beginners don't have. I often tell beginners a white lie to steer them away from potential problems and avoid a 20-minute explanation of something that would only confuse them.

    I would put "static methods in EJB class" into this category, but you make some good arguments in favor of using this technique if you are sufficiently experienced. Since I can't think of any good counter-arguments (other than the lame "style" one), I concede the point to you.
  12. Theoretical question[ Go to top ]

    OK, I think we are going to have to "agree to disagree" on this one. :)

    >
    > In my opinion, static methods in EJBs run counter to the common EJB coding style, but since there is no "EJB Style Guide", this is definitely just my opinion.

    Agreed. Every programmer has his/her own style.

    >
    > I have to admit that the work I do rarely involves complex mathematical functions, and JIT inlining is a good argument that I had not thought of.
    >
    > I actually spend a lot of time teaching raw newbies how to use J2EE, and as a result I tend to have a lot of "rules" that are aimed at steering beginners away from pitfalls.
    >
    > For example, I tell J2EE beginners to "never put an instance variable in a servlet". Of course, the real answer is "you can use an instance variable as long as you properly synchronize access to it", but that answer requires a degree of sophistication that most beginners don't have. I often tell beginners a white lie to steer them away from potential problems and avoid a 20-minute explanation of something that would only confuse them.

    When I talk to newbies I rarely sugar-coat this stuff for them. Then again, I'm not much of a teacher, so your approach is probably more effective.

    >
    > I would put "static methods in EJB class" into this category, but you make some good arguments in favor of using this technique if you are sufficiently experienced. Since I can't think of any good counter-arguments (other than the lame "style" one), I concede the point to you.

    I don't think static methods per se are that hard to get right. But I agree that if you're new to EJB it's probably easier to stay away from statics altogether until you get a solid grip, rather than make distinctions between static methods, read-only fields, read/write fields, lazy-loaded fields that look like read/write but can actually be considered read-only, etc.

    Gal
  13. EJB and static methods[ Go to top ]

    The ejb in many ways is just any other class. Also just like any other clas if it makes sense to declare a static method in an ejb then it is perfectly acceptable.

    steve - http://www.jamonapi.com - a performance tuning and scalability testing API.
    http://www.fdsapi.com - The easiest way to generate dynamic text including XML and HTML