Worth Repeating: Your Application is NOT Lightweight If...


News: Worth Repeating: Your Application is NOT Lightweight If...

  1. Here's a little light reading for a Monday morning. Reprinted from the blog of Adam Bien, here are a few signs that just might indicate that you're application isn't lightweight.

    Your Application Is *Not* Lightweight If:

    1. You already know what ThreadLocal is (and used that extensively)
    2. You see transaction management in the application code (an annotation, however is not perfect, but o.k.)
    3. You have to deal with EntityManagerFactory and EntityTransaction in your code
    4. Your XML-configuration doesn't fit on a single page any more
    5. Your solution cannot be handled without extensive tooling
    6. You spend some time for convincing other developers, that your solution is actually lightweight :-)
    7. You are in the process of replacing existing frameworks with your "lightweight" POJOs and hope the result will be easier, lighter and better maintainable
    8. You forgot the name and purpose of the layers
    9. The number of interfaces is equal or greater, than the number of classes, and you need naming conventions to deal with that
    10. The deployment size of your application archive (WAR) is greater, than the installation size of your "lightweight" server (like tomcat)

    Check out Adam Bien's blog. There's always some entertaining stuff there.

  2. Hello World[ Go to top ]

    I could sum up those criterias with


    0: Your application is not lightweight if it's anything more complicated than "hello world"

  3. Oh please, this is so petty.

    Disclaimer, I'm an EJB fan, and never really cared for Spring.

    That said, anyone who considers any of this stuff "lightweight" has been smoking the glossy literature.

    EJB is not lightweight. Spring is not lightweight. JPA/Hibernate is NOT lightweight.

    "Your solution cannot be handled without extensive tooling"? What do you think an EJB container IS? What do you think all of those Hibernate jars DO? They're not sitting idly by.

    Sticking an @Annotation in your code may seem "lightweight" but that little snippet is bringing along with it a whole world of black magic and dependency that you have little to no control over.

    If you think adding @Entity to a POJO gets you persistence "for free", you have another thing coming. You just unlocked Pandora's box and unleashed Sinister Forces marching unchecked through what was, up to this point, YOUR application. They should call it @Faust instead of @Entity, or @WebService, or @Session.

    No. "Lightweight". Ha! Yea, that's what all of those Jars, 100's of pages of documentation and specification, and extra MBs of RAM that my application are consuming. If I add more annotations, add more jars, and use more RAM, I guess it gets even Lighter-weight. How many gigs of resources, distribution size, and container size does it need to be before it's "Zeroweight"?


  4. Lightweight Bragging rights[ Go to top ]

    I think that's the point of article.  I can't tell you how many times I've heard people gloat how much lighter their Spring app is than my EE app only to find out their app + Spring is bigger than my app plus Glassfish.

    It seems a lot of people use the word "lightweight" to mean "not Java EE".  Makes it a nearly worhless description.

  5. Well stated.  I find that one of the hardest things to get people to believe understand is that dependencies are not free.

    This isn't to say that we should build everything from scratch but I think that if more people really understood the cost of dependencies they would be far more careful about introducing them.  One of the biggest problems is that dependencies can be strategically crippling.  The compounding costs of loss of control and choice will often far outweigh simple time savings.  Usually, these costs only become obvious long after it's too late to change course.

  6. So just not doing the above points will I make my code "lighweight"?

    Or what does "lighweight" mean?

    For some it might be the fact that you dont have to implement/extend any framework specific classes or use specific annotations in your code. For others something else...

  7. Not lighweight if you use Hibernate...

    coming from JDO/DataNucleus to use Hibernate once again on a project I forgot how truly transparent JDO persistence can be and how Hibernate persistence is simply not transparent at all...

    Oh, my reference to an object ... is it currently pointing to the object or the proxy for the object? Oh, wait make sure I call Hibernate.initialize() to make sure it's the object.... OMG how is that transparent persistence?

    I'll be earning a lot more money as a contractor on this job if they continue to use Hibernate because it's just not clean POJO development with transparent persistence like JDO is but hey, it's their decision - if they have the money to spare to pay for the extra 20% effort involved with catering to Hibernate's issues then who am I to complain? :)