Those evil frameworks and their complexity


News: Those evil frameworks and their complexity

  1. Those evil frameworks and their complexity (6 messages)

    Frameworks like Hibernate and Spring are industry-standards. JSF, EJB and the likes are also standards and used in many applications. But there are always people that are against these frameworks.

    The usual arguments against using frameworks are:

    • it is very complex, we don’t need it
    • we can make our own framework that will be better for us
    • we doubt their quality and don’t think they can do the job
    • we don’t want to learn yet another framework, core java should be enough
    • we’ve never heard of those…what’s so good about them?

    The bad thing is you can’t argue with these people. And if they happen to be leads or architect – here’s another screwed project. No, don’t get me wrong – there are pretty valid cases not to use these frameworks. But they are not the common project out there. Let me discuss each of the above arguments...

    Read more at :

    Java Code Geeks: Those evil frameworks and their complexity

  2. Those complex frameworks are evil[ Go to top ]

    - Hibernate: an abstraction leak as a whole. To use it you need to know the inner workings, caching, annotations, configurations ... SQL and your RDBMS, of course.

    - Spring: squeezes in between your code and the Java plattform. Has a Spring solution for everything, esp. for what hasn't been a problem beforehand.

    - JSF: the framework that motivated others to look for lightweight alternatives: Wicket, Stripes, Tapestry, Click, ...

    It's a sign of maturity when those complexity generators come under criticism.

  3. Those complex frameworks are evil[ Go to top ]


    You must be kidding me!

    Have you really used Hibernate+Spring in a large project? They are awesome, and make the life easy.

    And for a really large project EXPERT people are needed. Peoples who know more that java.lang package! And a very large project in complex in its heart, but I believe these 2 reduce the whole complexity.

  4. +1 to Amir's -1

    Hibernate and Spring ARE the reason why JPA and a bunch of other "standards" exist nowadays, And you can't deny that JSF is (was?) a half baked ASP.NET, no wonder why every sane person goes with better alternatives, including Grails (with Hib+Spring at it's core).

    It's true you have to put some effort in learning some of the internals of these frameworks, but isn't that part of the job after all?  Just as learning new languages like Scala, Groovy, etc. It makes you a better programmer/engineer/arquitect I think.

  5. And you can't deny that JSF is (was?) a half baked ASP.NET, no wonder why every sane person goes with better alternatives, including Grails (with Hib+Spring at it's core).

    Very few sane people around there then, Since JSF is one of the most popular frameworks and continues to grow.

    And yes, I deny that JSF is or was a half baked ASP.NET. It's actually pretty darn good, but I wish you and the two other developers on this world that use Grails all the luck of the world (you're going to need it with something as Grails).

  6. Those complex frameworks are evil[ Go to top ]

    This comment... is actually ingenious. I *am* for frameworks, as constatntly rolling out your own solution is dumb, but what Byren says is 100% truth. I believe that the community is more and more realizing this too, thus the rise of lite-weight alternatives, like Play framework, Siena etc.

  7. Justin you are missing the most important thing regarding this subject: abstraction level.

    You are EVER using some kind of framework, be Java based, be C based, be any other language. Almost no one writes machine code these days.

    Abstraction is fine because it usually improves your productivity because you are adding already-cooked stuff. 

    But it has a price.

    The more abstraction the more inflexibility, less control and more risk of not successfully doing the thing you specifically need.

    The key of this topic is how much abstraction are you going to afford and in the same time get control of the technology and get aligned with your needs, your objectives, the desired performance etc. If your tool is of very high level or the kind of abstraction you don't need you end figthing AGAINST the framework trying to fit it into a concrete problem it wasn't designed, adding tons of hacks and spending hours and hours to solve a problem trivial in a lower level, ruining your productivity.