Skip to main content

No Regrets

Posted by editor on January 29, 2009 at 7:51 AM PST

Is using lots of static methods a form of functional programming, or just wrong?

After a long absence, our "(Not So) Stupid Questions" series returns with an entry that could be pretty controversial.

We often tease out these questions with some "first thoughts" to frame where the question is coming from and what the submitter has done to work through the problem by him- or herself. In this case, we were working with a pretty significant language barrier, and chose to leave it shorter and, perhaps, more wide open.

We have one application that uses Struts.

In the DAO, where we write the business logic, we made all the methods static.

By definition, statics are called by their class name, so in our Action and DAO classes, we just call these static methods.

Presumably, one quick answer is that this is just wrong, considering that the "O" in DAO is "object", and using all class methods literally means that you're not using the object, per se. But is this the only answer? After we've seen functional programming gain momentum in the last few years, along with screeds about rants about how Java wants you to make everything a noun, then is it at least possible that a verb-only approach might be appropriate in some contexts?

Or, going meta, does the fact that the question is even being asked suggest something wrong with our enterprise patterns? Are they not easy enough to follow? Do they not provide obvious value?

Please let us know what you think in the comments to this Feature Article, (Not So) Stupid Questions 21: All Statics . And if you've got a not-so-stupid question you'd like to see featured, send it to

In Java Today,
Real Invaders, a project, is a game where you physically move your phone to put the target on the spacecraft to fire. The game does not use the accelerometer; instead, it uses the camera for motion tracking. Real Invaders works on Nokia mobile phones that have Symbian OS series 60 and 240x320 screen resolution pixels, like the N95, N73, 6120 classic, 6110 navigator, etc.

More than a year on after release of version 1.1, EoD SQL has been released. EoD SQL is "a super light-weight Object <-> Relational mapping layer. Based originally on the java.sql features of Java 6 beta (features later removed), EoD SQL has grown enormously from where is began, but has stuck to it's core principal of 'Get out of my way and let me talk to my database'."

The Aquarium has posted details about this week's Webinar on Sailfin. "This week's GlassFish webinar is on Friday, Jan 30th, 9:30 am PT (note the different date and time). Binod PG and Sreeram Duvur will provide an overview of SailFin, the Open Source Communications Server in GlassFish that supports the converged web built on HTTP and SIP. The presentation will include background material on the SIP world."

In today's Weblogs, Eitan Suez
Why I do Open Source. "First Kirill blogged on "Why I do open source" and then invited Andres and Alex to do the same. So a chain reaction is in motion. Andres published his version, and tagged me and three others. So here's my entry,... "

Xuan Yun shows how to create Embedded Objects in Synth Look And Feel. "We can embed Java objects into Synth XML file, the embeded objects can be referred as properties."

Sadly, Marina Sum says Goodbye For a While. "I'm no longer with Sun: It was a wonderful ride. Will keep posting once in a while."

In today's Forums, kschaefe spells out the limitations and hazards of int constants in
Re: The SwingConstants Problem. "I guess my introduction was a little wonky. Let me reexplain. How about JTabbedPane.setTabPlacement(int)? It only takes SwingConstants TOP, BOTTOM, LEFT, and RIGHT. It throws an IllegalArgumentException if the value is not one of those constants, but the code compiles and without looking at the JavaDoc how do I know that any integer isn't valid. It's the standard problem of int-constants. It's easy to replace such constants with a single enum."

akarl16 weighs in against 6u10's "Quick Starter" in
Re: Java Quick Starter IO activity question. "I agree with the complaint here. I have turned JQS off on most of my systems now (Windows XP) due to the massive number of page faults that it causes. From the documentation I've read and what I've observed, Java is essentially launching itself constantly so that launching it in the future is faster. This makes me slightly angry. If Java is pulled out of RAM by the operating system then it probably was in the overall system's best interest to have it pulled out of RAM. I don't agree that Java runtimes are privileged enough that they should begin overriding what my operating system is working hard to accomplish."

Finally, Glen Mazza offers some ideas for SOAP logging in
Re: Is it possible to send parameters/variables to a Handler. "If you really want it SOAP call-specific, perhaps placing an implicit SOAP header for "logging" in the SOAP request message would be a good solution. You can have wsimport generate an extra parameter for you to place the logging value in."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Is using lots of static methods a form of functional programming, or just wrong?


There is absolutely nothing wrong with using static methods when you don't need the dynamic polymorphism provided by non-static methods. As for using static variables, that's a totally different issue. Now to address some previous posts: "Statics are bad in that they eat up memory, resource and tend not to be released so easily." This might be true for static variables, but static methods doesn't take up any more resources than non-static ones. "Using all static methods isn't functional programming, it's procedural programming." Eh? A static method that doesn't use static variables can definitely be seen as a function. "However, using all static methods in Java when writing multi-threaded systems (which all web applications, among them Struts applications, implicitly are) is going to lead to disaster." This is only true if you use static variables, but this holds regardless if the method is static or not. Static methods is just as safe/unsafe as non-static methods.

P.S. It might be a good idea to provide in those articles a link to an index of all prior such articles. As it is old content on this site can be notoriously hard to find.

Using all static methods isn't functional programming, it's procedural programming. While there's nothing wrong with procedural programming per se, doing so using an intrinsically object oriented language is at least a bit dodgy. Use the tools designed for the job, so if you want to do procedural programming use something like C, Pascal, or Fortran, not Java.

However, using all static methods in Java when writing multi-threaded systems (which all web applications, among them Struts applications, implicitly are) is going to lead to disaster. Data corruption due to threading issues will be commonplace, and if you think to avoid that by making everything synchronized you end up with a non-performant system that can only handle a single request at a time.

Actually, not turning on comments in the article was a mistake on my part; the template is defaulting to comments off because of problems with spammers. We've now turned comments on the article ON. And regardless of where you've posted, thanks for your feedback!

Smart move not putting the comment section in the (not so)stupid question article. :) So I will comment here instead. Is it wrong... you betcha! I'm not going to hold up some OOD statement of Object correctness, but rather from a standpoint of how the JavaVM works. Statics are bad in that they eat up memory, resource and tend not to be released so easily. So while it is "Easier" to program this, it is causing their systems to not perform as well as they could. When the GC() runs it can free up memory but loaded classes are going to have to be unloaded and that will take up more time than a simple memory release. Now moving on to OOD practices... If one goes back to the questioners statement that in the "DAO where we write the business logic".... excuse me?!? You are putting the business logic with the data access and likely the data container itself? Wouldn't you want your business logic in an application specific module or better yet a service? You may not want to have your sales tax calculation in the DAO for an inventory item, rather it would need to be in an object which was relevant to the state that the purchaser was from. You also would not want to put that sales tax logic in the purchaser DAO since they may be Tax Exempt. While writing all your code into one big file is "easier" we all know that is wrong. And while the questioner thinks this is "easier" to code than to have a service with BL, and DAO with data gathering logic, when it comes to debugging and maintenance you will find that a little bit of design will go a long way. So when your tax calculation goes weird on you, it will be obvious where to go to validate it, instead of having to look at each individual record that was involved and how each affected the calculation. -Shawn