Generally I am asking if this is a norm. The application architecture includes spring and the zk framework. I personally can't help but think this introduces a number of problems. I mean...this is a lot of non synchronized functionality. On top of that we are using an Apache project that, through my browsing of source, appears to use a singleton which has methods that are not thread safe. Changed in a newer version however we are not free to migrate the library at this time.

My real question is, is there a justifiable reason for using a large quantity of static methods in a JavaEE application? I was an ASP.NET dev before this and never encountered this. Instincts dictate this is bad architecture but I am unfamiliar with the stack. There are other warning signs such as a lack of conventional generic convention use. Is this the norm?

What is foreign in one platform may not be in another.

  • 1
    static final fields are thread safe due to strictly specified initialization procedure (see VM spec 2.17.5) - if you have only these, no need to worry. There is also a chance that framework guarantees that things are safely confined in one thread - if this is the case, framework specification explicitly states that - you need to check it before jumping to conclusions. Other than that the code stinks and I wouldn't wonder if there are data races
    – gnat
    May 15, 2012 at 5:08
  • 2
    (cont...) signs of good code in Java EE are same as in C#: understandable plain objects, consistent use of generics (or absence thereof - for pre-1.5 legacy code), DI/IOC in place of singletons, easy to understand synchronization. Anything other than that is under suspect
    – gnat
    May 15, 2012 at 5:44
  • Static methods are hard to test, so extensive use hint that the application lacks unit tests. Oct 14, 2015 at 9:03

3 Answers 3


I would say that just by reading your analysis, you're saying there are alot of static methods and singletons. Static methods shouldn't be an issue by themselves, but if they're being used to proxy calls to the singleton objects, I would work on making those either rock solid, or replacing them with a more sane object model.

Static methods are useful for purely functional purposes, and you'll find both the Scala and Clojure programming languages to use them alot, mostly because they don't need to worry about mutable state.

Reading from this blog post on Java Static/Class methods(I've highlighted a relevant bit):

Static methods use no instance variables of any object of the class they are defined in. If you define a method to be static, you will be given a rude message by the compiler if you try to access any instance variables. You can access static variables, but except for constants, this is unusual. Static methods typically take all they data from parameters and compute something from those parameters, with no reference to variables. This is typical of methods which do some kind of generic calculation. A good example of this are the many utility methods in the predefined Math class. (See Math and java.util.Random).

  • I should note that when I say Scala and Clojure, I'm referring to reading the implementation code, of which both languages still borrow heavily from Java to compile their implementations. May 15, 2012 at 3:42
  • 1
    My concern comes from the fact there are static variables in these implemented classes and generally the multi threaded nature of web applications. Am I wrong in this respect? Practically everything is static. Not just utilitarian functions. Being unfamiliar with Java web development I really don't know what is idiomatic.
    – Rig
    May 15, 2012 at 3:54
  • PS: Some of the thread safety concerns came from an outdated Apache jar we were using which uses a singleton object (initialization is synchronized) that doesn't have synchronization on any of the file access type methods in it. I do think you answered the core of my question though which was, is the heavy use of statics in this case common and whether it presents a problem. Our code doesn't seem to use singletons on its own. Just in this library.
    – Rig
    May 15, 2012 at 12:28

It's certainly not idiomatic in Java, C# or most any OO language to have a lot of static methods that make assumptions about the state of the universe (typically indicated by use of static variables). I've experienced the pain of untangling at least two large-scale applications and one integration test project that introduced static variables everywhere, including one that only allowed one user to be instantiated at any given moment, because the static User.getUser() method was the only way to get an active instance of the user class. That was very painful.

However, it was bad code. I've seen bad code just like this in C#, in Perl, and in C++. It's a crutch that a certain category of procedural programmers reach for because it feels kind of familiar. Global state is easy to understand, until enough code has been produced that it isn't.

There are a few things for which global state makes sense, but in an idiomatic Java application, these should be confined to not much more than a logging framework (so that you can call something like LogManager.getLogger("somename"), the global dependency bindings map that might be required by a dependency injection framework, and perhaps something that is fairly expensive to build, like an object-relational mapper's session factory.

If you're using Spring sensibly, dependency lookup is typically confined to a narrow part of the application. I've seen Spring used essentially to implement the Service Locator pattern, which essentially has each class constructor ask for its dependencies by calling out to Spring, but this is just asking for pain later and usually frustrates testability, since unit testing shouldn't need to rely on the dependency injection framework. Instead, the locus of Spring usages should be small: I usually have the controller factory in an MVC project build the dependencies needed. For services, there's also usually a reasonable place that you can hook in that's relatively narrow.

Considering that J2EE was sort of an architecture-astronaut version of object purity, I'd almost be more surprised to see lots of static (global) state in a J2EE app. However, knowing that a lot of junior engineers who don't quite know how to do loose coupling sensibly and senior engineers entrenched in procedural ways of solving problems are often thrown at a large-scale project, it's not actually that surprising to see a spaghetti and meatballs approach to a poorly understood problem domain when just the right combination of the wrong people was put on a project.

  • Thank you for your insight. I definitely didn't expect to see so much static functionality when it would, by my intuition, belong as an object to be instantiated. The way this particular code is written seems to bump against a lot of what I was taught hence the question.
    – Rig
    May 15, 2012 at 17:43

Statics should be used when you don't want to have varying behavior for different objects.

Statics should be used when data is not instance dependent and for all existing instances of static member you want to apply same state.

Statics should not be used at all If they are not actually required as they create dependencies and references to other classes and class loader in JVM and stay in memory for long time. So they are not considered for garbage collection once they are done with current work Instead they are de-referenced with their loading classes as they maintain a reference to static classes. Read more- http://efectivejava.blogspot.in/2013/08/when-to-use-static-members-in-java.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.